MCP servers
Which MCP address to give an agent. One server per suite for every app you are in, one per app for a narrow integration, Code Mode, and the Studio's own server.
gtable speaks the Model Context Protocol over Streamable HTTP, with OAuth sign-in. An agent connected to it acts as the person who approved it, with that person’s permissions. The fastest way to connect one is Set up your agent; this page explains the addresses.
The addresses
| Address | What it reaches | Use it for |
|---|---|---|
https://{suite}.gtable.app/mcp | every app of the suite you are in, as far as you ticked them at sign-in | the default: Claude, ChatGPT, Cursor, a person’s own agent |
https://{suite}.gtable.app/{app}/mcp | one app | an integration that must touch that app and nothing else |
https://{suite}.gtable.app/mcp/code | Code Mode, on the first app of the connection | an agent that writes code rather than calling tools one by one |
https://{suite}.gtable.app/{app}/mcp/code | Code Mode, on one app | the same, pointed at a chosen app |
https://studio.gtable.app/mcp | the Studio: organisations, suites, apps, schema, rules, people | a builder’s agent that designs apps |
https://studio.gtable.app/mcp/code | Code Mode on the Builder API | the same, as code |
A suite on its own domain serves the same paths there.
Why one server per suite
A suite is one address with several apps under it. One server for all of them means one entry in a person’s client, and adding an app to the suite does not make anybody reconfigure. Three things make that work:
apps_listreturns the apps this connection can open, with the id to pass back. An agent can ask “the CRM or the support desk?” rather than guess.appIdon every app tool. It is optional when the connection reaches exactly one app, and required beyond that. Leaving it out is answered with a sentence that names your apps.tableIdis a closed list of the tables you can read, across the apps of the connection. A model cannot even name a table it may not read.
The suite server does not attach every table’s record shape to its tool descriptions, which
would resend every app’s schema on every turn of a conversation. An agent calls schema_get on
the app it cares about. The per-app server keeps the shapes in its tools, where they cost
nothing.
What the agent is told is what you may see
The tool list is generated for each connection from the same masked schema the API uses. A table you cannot read is not listed: not refused when called, absent. A field you cannot read is not in any tool’s input or output. Tools outside the connection’s scopes are not offered.
When you approve a connection to a suite, you choose which of its apps it may reach. An agent connected to the suite but ticked only for one app sees nothing of the others, and membership is checked again on every call, so the list can only narrow.
The Studio’s server
https://studio.gtable.app/mcp is the builder plane: create an app, add tables and fields,
write permission rules, ask what a person would see with rules_simulate, manage the
directory. It is bound to the one organisation chosen on the consent screen. It also serves
skills_list and skills_get, the manual an agent reads before building: how permissions are
shaped, how to check what a schema change would break, how page code is edited.
This documentation has one too
These docs have their own MCP server at https://gtable.app/docs/mcp, with search,
fetch and list_pages over the public pages. It needs no sign-in and reaches no data.