Cursor’s agent reaches Backenly through one block in mcp.json. It then builds and runs a Backenly project: tables, auth, storage and functions, with anything destructive held for you.
Nothing to install. Cursor infers the transport from the url, so the block needs no type field.
{
"mcpServers": {
"backenly": {
"url": "https://backenly.com/api/mcp",
"headers": { "x-api-key": "<scoped-key>" }
}
}
}Runs the @backenly/mcp-server package through npx, on Node.js 20 or later. On a self-hosted Backenly, the args end with --endpoint and your instance’s address.
{
"mcpServers": {
"backenly": {
"command": "npx",
"args": [
"-y", "@backenly/mcp-server",
"--project", "<id>",
"--key", "<scoped-key>"
]
}
}
}Save the file, then reload the Cursor window. Your project’s Connect page, under Agents, prints both blocks with the project id and key filled in.
Where the block goes. Your user config sits outside every repository, so the key is never committed beside the app.
Committed with the repository, next to the code the agent writes. An agent building a frontend once shipped its own MCP key in the bundle. The runtime API now refuses one with MCP_KEY_IN_APP; a key kept out of the repository never gets that far.
Run npx @backenly/mcp-server init once. It checks the key and saves it to ~/.backenly/mcp.json, readable only by you. The local block then carries no key, so it can sit in a file you commit.
{
"mcpServers": {
"backenly": {
"command": "npx",
"args": ["-y", "@backenly/mcp-server"]
}
}
}One command writes .cursor/rules/backenly.mdc, marked alwaysApply: true. Its body is backenly.com/skill.md, the guide Backenly writes for agents: which tool to use for what, the error codes to branch on, and which key an app needs.
npx -y @backenly/cli@latest install-skill --agent cursorCursor reads mcp.json when a session starts. Until the Backenly tools appear, the agent can run every one of them from the terminal, with the same key and the same approval rules.
npx -y @backenly/cli@latest link --project <id> --key <scoped-key>
npx -y @backenly/cli@latest call read_backend_state
npx -y @backenly/cli@latest chat "add a likes counter to posts"link keeps the key in .backenly/config.json and, if the repository has a .gitignore, adds .backenly/ to it.
Anything else, ask the people who built it.
Not in Cursor, which infers the transport from the url. Cline takes the same block but needs "type": "streamableHttp" in its remote entry; without it, Cline falls back to SSE and the endpoint answers 405.
Yes. Choose read-only when you create the key on the Connect page. A read-only key sees 16 tools instead of 23, and a write called anyway is refused with READ_ONLY_KEY before it runs. The agent cannot upgrade its own key.
One key reaches one project, so a leaked key exposes that project and nothing else. The connect tool’s whoami action tells the agent which project and key it is acting as. Projects are created in the dashboard, not by the agent.
No. The MCP server operates a Backenly project, hosted on Backenly Cloud or on your own Backenly install, with a PostgreSQL schema that Backenly manages. You can still reach that database directly with a connection string from the Connect page, and export it with pg_dump.
Anything destructive or irreversible. apply_migration refuses DROP statements. Dropping or emptying a table, deleting files or functions, deploying, rolling back and revoking keys are parked on the project’s Autonomy page until a person approves them. The agent can request and poll with check_approval; it cannot approve.
Yes, from the project’s History: restore that one change, or everything back to a point. History covers the schema, auth, storage, functions, webhooks, environment variables, keys and integrations, and each restore is checked before it runs. Data your app wrote since is never rewound, and a restore that would affect it waits for your approval. The agent can ask for a restore, but only you can approve one.
One free project, no credit card. The Connect page prints your mcp.json block.