Your coding agent builds and runs a backend through it: PostgreSQL, REST APIs, auth, storage, realtime and functions in a Backenly project. Reads are open, schema changes are checked and verified, and anything destructive waits for you.
claude mcp add --transport http backenly https://backenly.com/api/mcp --header "x-api-key: <scoped-key>"The key comes from your project’s Connect page, under Agents, and you can revoke it there. That page prints each block below with your project id and key filled in.
Claude Code
Nothing to install. Run it in a terminal before you start the conversation: an MCP host reads its servers when a session starts.
claude mcp add --transport http backenly https://backenly.com/api/mcp --header "x-api-key: <scoped-key>"Claude Code
No key. Run /mcp, pick backenly and choose Authenticate. You approve the connection on backenly.com and choose the project there; read-only is an option on that screen.
claude mcp add --transport http backenly https://backenly.com/api/mcpClaude Code
The @backenly/mcp-server npm package (Node.js 20 or later). It serves the same tools, instructions and results as the remote endpoint.
claude mcp add backenly -- npx -y @backenly/mcp-server --project <id> --key <scoped-key>Codex
For the remote endpoint, Codex takes the key only through ~/.codex/config.toml: a [mcp_servers.backenly] table with the url and http_headers.
codex mcp add backenly -- npx -y @backenly/mcp-server --project <id> --key <scoped-key>Cursor
The user config, not the project’s, so the key is never committed beside the app.
{
"mcpServers": {
"backenly": {
"url": "https://backenly.com/api/mcp",
"headers": { "x-api-key": "<scoped-key>" }
}
}
}Cline
The remote entry must set "type": "streamableHttp", or Cline falls back to SSE and the endpoint answers 405.
{
"mcpServers": {
"backenly": {
"type": "streamableHttp",
"url": "https://backenly.com/api/mcp",
"headers": { "x-api-key": "<scoped-key>" }
}
}
}Registered a server mid-conversation? Its tools appear in the next one. Until then, every tool is callable from the shell with the same key and the same rules: npx -y @backenly/cli@latest call read_backend_state.
A read-only key or sign-in keeps the read tools and narrows each section tool to its read actions.
| What it is for | Tools | What they do |
|---|---|---|
| Read what exists | read_backend_state, get_table_schema, run_query, generate_types, fetch_docs, check_approval | The backend’s state, section by section; one table in full, with what its constraints reject; read-only SQL as the project’s SELECT-only role; TypeScript types, a typed client or OpenAPI from the live catalog. |
| Change the schema | apply_migration, set_rls, branch | SQL in, checked typed actions out, applied as one governed change. Row-level security as exact SQL predicates, installed as written and read back. Preview branches that merge back once a person approves. |
| Write rows | db_insert, db_update, db_delete | Row writes for seeding and repair. An update or a delete needs a non-empty filter. |
| Run each part of the backend | auth, storage, functions, realtime, integrations, monitoring, autonomy, webhooks, deploy, connect | One tool per console section, each with an action: sign-in providers and users, buckets and files, server functions and schedules, live updates, provider keys, metrics and logs, the maintenance loop, signed webhooks, deploys, and keys and connections. |
| Ask in plain language | backend_chat | Backenly’s own engine plans a change from a description. It is the one tool that draws AI credits; the typed tools above never do. |
Dropping or emptying a table, dropping a column and discarding a branch go through backend_chat, which parks them the same way. apply_migration refuses DROP statements outright and says so.
remove_oauth_provider, block_user, remove_smtpdelete_file, delete_bucketdelete, delete_scheduledisabledisconnectdeletedeploy, rollback, revert_changerevoke_api_key, delete_env, disconnect_frontendThe response carries an approval object with its id. Nothing in the backend changes.
It waits on the project’s Autonomy page under “Waiting on you”, with its impact: how many live rows, and whether the data is recoverable.
Approve or reject it there. The agent’s key can request and poll; it cannot approve.
Verbatim, with no model re-reading it. The agent polls check_approval until it reports executed, rejected, expired, failed or partial.
Every key and sign-in is bound to one project, so a leaked credential reaches that project and nothing else. connect { action: "whoami" } says which one. Projects are created in the dashboard.
It operates the PostgreSQL schema Backenly runs for the project. It is not a client for a database Backenly does not manage, though you can read that schema directly with a connection string.
MCP keys are issued in the dashboard, and read-only is chosen there. The runtime API your app calls refuses an MCP key (MCP_KEY_IN_APP), and a service-role key is never issued to an agent.
Anything else, ask the people who built it.
No. The server operates a Backenly project, on Backenly Cloud or your own self-hosted Backenly, and each project has its own PostgreSQL schema that Backenly manages. You can still reach that database directly, with a read-only connection string on demand or a read-write one a person arms, and export it with pg_dump. It is not a general MCP client for a database Backenly does not run.
Any MCP host that speaks stdio or Streamable HTTP. The setup is documented for Claude Code, Cursor, Codex, Cline and Antigravity, and the Connect page in your project prints the exact block for each with the key filled in.
Not on its own. apply_migration refuses DROP statements with DESTRUCTIVE_REFUSED and points at backend_chat, which parks the request for approval. Dropping or emptying a table, dropping a column, deleting files, revoking keys and the other actions listed above all wait for a person. Ordinary row inserts, updates and deletes run as normal.
Yes. Every change, whether your agent, Backenly or you made it, is one entry in the project’s History, which covers the schema, auth, storage, functions, webhooks, environment variables, keys, integrations and allowed origins. Restore one change, or everything back to a point; each restore is checked before it runs and verified after. Data your app wrote is never rewound, a restore that would affect it waits for your approval, and a secret or a revoked key never comes back. An agent can ask for a restore, but only a person approves it.
Yes. A read-only key or connection sees 16 tools: the read tools, and each section tool narrowed to its read actions. A write called anyway is refused with READ_ONLY_KEY before it runs. A person chooses read-only when the key is issued, and an agent cannot upgrade its own key.
Only backend_chat, which runs Backenly’s own engine. The typed tools your agent calls directly, including apply_migration, are not metered as AI.
Yes. Point the stdio package at your instance with --endpoint, or add your instance’s /api/mcp as the remote URL. Keys and projects come from your own dashboard.
One free project, no credit card. The endpoint is https://backenly.com/api/mcp.