The backend/AI & agents
The backend an agent
can't screw up.
Give an agent real tools over your data — read, write, migrate, deploy — through an MCP server it connects to in one config block.
Then take the safety on trust out of it. What the agent may touch is a scoped key, and what the database will return is row-level security. Two gates, neither of them a prompt.
Model Context Protocol
Your project, as tools an assistant can call
@rebasepro/mcp speaks the Model Context Protocol, so anything that speaks MCP can drive your backend: query and edit data, push schema changes, open a database branch, trigger a cron job, tail the dev server.
Your collection definitions and the generated Drizzle schema are exposed as MCPresources too, so the assistant reads your actual data model rather than guessing at it from the code it happens to have open.
There is nothing to build and no adapter to write. It is one block in a config file.
// .cursor/mcp.json — or Claude Desktop, Windsurf, Copilot…
{
"mcpServers": {
"rebase": {
"command": "npx",
"args": ["@rebasepro/mcp"],
"env": {
"REBASE_BASE_URL": "https://api.example.com",
"REBASE_API_TOKEN": "rk_live_…"
}
}
}
}The tool surface
40 tools, and these are their real names
Not a category diagram — the actual list the server registers. An agent that can call these can build and operate an application without a human in the request path.
- list_documents
- get_document
- create_document
- update_document
- delete_document
- list_users
- create_user
- update_user
- delete_user
- list_roles
- rebase_auth_reset_password
- rebase_schema_generate
- rebase_schema_introspect
- rebase_db_push
- rebase_db_generate
- rebase_db_migrate
- rebase_generate_sdk
- rebase_doctor
- rebase_db_branch_create
- rebase_db_branch_list
- rebase_db_branch_info
- rebase_db_branch_delete
- storage_list_objects
- storage_get_metadata
- storage_delete_object
- cron_list_jobs
- cron_get_job
- cron_trigger_job
- cron_get_job_logs
- cron_toggle_job
- invoke_function
- rebase_dev_start
- rebase_dev_logs
- rebase_dev_stop
- rebase_project_list
- rebase_project_current
- rebase_project_switch
- rebase_project_add
- rebase_project_remove
- rebase_project_status
Least-privilege agents
Authorization the agent cannot forget
Everyone in this category will tell you their agent integration is safe. The question worth asking is what enforces it — because if the answer is the tool layer, then a bug in the tool layer is a breach. Here the tool layer is the first of two gates, and the second one is the database.
Revoke a permission below and watch the same four calls come back refused.
The key you hand the agent. Revoke something and watch the session below.
permissions
admin flag
Without it the key carries the service role, and Postgres grants that role nothing unless a policy names it.
200 20 rows · id, title, price, stock
200 1 row updated · orders/8f21
403 permission_denied
Refused twice: the key has no such permission, and no delete policy on orders names "service", so 0 rows match.
403 permission_denied
Refused twice: the key has no such permission, and the users table is covered by default_admin, which the service role is not.
The two gates are independent, which is the part worth sitting with: grant orders:delete above and the call still deletes nothing, because a key permission is not a policy. No prompt, jailbreak or bug in the tool layer widens what the database will return.
A key, not a god-mode credential
Permissions are declared per collection and per operation, and there are three operations rather than the usual two — delete is separable from write, which is the one you actually want to withhold from an agent.
admin is a separate flag. Without it the key carries only the service role, and Postgres grants that role nothing at all unless one of your policies names it.
Keys are SHA-256 hashed at rest, rate-limited per key, expiring, and revocable.
How the policies are generated// The key behind that token. Three operations, not two —
// and `admin` is a separate flag, off by default.
{
"name": "support-agent",
"permissions": [
{ "collection": "products", "operations": ["read"] },
{ "collection": "orders", "operations": ["read", "write"] }
],
"admin": false,
"expires_at": "2026-10-01"
}Agent infrastructure
Everything an agent needs to operate
Vector search, scoped keys, streaming functions, realtime and scheduled tasks — the operational surface agents build on, in one window instead of a wall of cards.
MCP is a standard, so the list of things that can drive your backend is not ours to control — it is whatever speaks it.
Point an agent at it
Scaffold a project, add the config block, and hand your assistant a key that can read one collection. It is a faster way to find out whether any of this is true than reading the rest of this page.
