Why agents struggle with hosted backends
An agent is only as good as the feedback loop it can close. It does not need help writing code. It needs to see what its code did, and correct itself.
Against a hosted backend it is writing blind. The database is remote. The schema lives behind a dashboard. It cannot run the migration and see the result, and it cannot call the API it just generated. It emits code, you deploy, you find out.
Setting it up
The MCP server ships inside the CLI. There is nothing extra to install.
Claude Code, one line, from your project folder:
Anything else, print the config in the shape that client wants:
| Client | File | Note |
|---|---|---|
| Claude Code | .mcp.json | Committed with the repo, so the team gets it |
| Codex | ~/.codex/config.toml | TOML, not JSON |
| Cursor | .cursor/mcp.json | Restart Cursor after adding |
| VS Code agent mode | .vscode/mcp.json | Root key is servers, not mcpServers |
| Claude Desktop | claude_desktop_config.json | Fully quit and reopen the app |
The 14 tools
Read: project_info, schema_read, rows_list. Verify: access_audit, api_request. Auth: auth_enable, auth_create_user. Change: schema_add_model, schema_add_field, schema_set_access, schema_drop_model, db_sync, sql_query, data_export.
It speaks standard MCP over stdio at protocol 2024-11-05, so any compliant client works, not only the five above.
What to ask it
- "Read my schema and tell me if anything here is unsafe to deploy."
- "Add a bookings table where a customer can only ever see their own rows."
- "Create two test users, log in as the second one, and prove they cannot read the first one's bookings."
That last one is the interesting case. The agent creates the second user, calls your real API with their real token, and shows you the empty array. It is not claiming the isolation works. It is demonstrating it.