Skip to main content
The Xano Engine serves an MCP server for coding agents. Through it, an agent can:
  • look at the deployed backend: objects, table schemas, rows and run history;
  • seed and edit rows;
  • run functions, tasks, triggers, endpoints and tests by hand, getting back each result and its logs.
It never changes a primitive. Tables, endpoints, functions and every other object change in xano/ and reach the Engine with npm run xano:deploy.

​
Claude Code and Cursor

xanosdk init connects both. It writes one server, xano-local, to .mcp.json (Claude Code) and .cursor/mcp.json (Cursor):
Cursor’s entry adds "--project", "${workspaceFolder}", because Cursor does not promise to start the server inside the project. Running init in an existing project adds xano-local beside the servers a config already declares. The server is a bridge that xanosdk local mcp --stdio runs. Nothing has to be started or installed by hand:
  • The agent launches it. It uses the project’s own @xano/sdk when installed, and fetches it when not (a fresh clone opened before npm install).
  • The config holds no URL and no token. A restarted Engine can come back on a new port and always mints a new bearer, so the bridge looks both up when it needs them.
  • It connects before your first deploy. With no Engine running it lists no tools. Once you deploy to the Engine, it tells the agent its tools changed.
  • A call is never sent twice. One cut off after it reached the Engine is reported as unknown.
Claude Code asks once before it starts a project’s server. If your Cursor version does not pick up the tool change, refresh the xano-local server in Cursor’s MCP settings after your first deploy.

​
See the connection details

xanosdk local mcp prints the Engine’s URL, its MCP endpoint, the command the config launches, and each agent’s config line. It never prints the bearer.
--json prints the same details as one document. An Engine too old to serve MCP says so, and xanosdk local update moves the project to one that does.

​
Tools

The Engine serves the tool list, so its exact names follow the Engine version you pin. They cover the jobs above: reading objects, schemas, rows and run history; writing rows; and running a function, task, trigger, endpoint or test. Ask your agent to list them, or send tools/list through the bridge.

​
Codex and other agents

For an agent init does not configure, add the same command to its MCP config by hand. Pass --project with the project’s path when the agent may start the server outside the project. For Codex, in ~/.codex/config.toml:
The bridge reaches the Engine of the project at --project, or of the directory it starts in when the flag is left off. To reach another Engine, name it: xanosdk local mcp <name> --stdio, with a name from xanosdk local list.

​
Next