The standalone Arbol MCP server is designed as a stateless wrapper around the public REST API.
It does not read Arbol’s database, mirror organization state, or own a second permission model. The API remains the authorization and business-logic boundary.
At build time, the MCP repository reads the public OpenAPI contract and generates tools from published operations. The generated definition preserves:
- the OpenAPI
operationId and description;
- path, query, and JSON body schemas;
- the production server and HTTP method;
- required API permissions; and
- read-only, idempotent, or destructive hints where the contract supports them.
A small number of model-oriented tools can optimize common workflows by composing published API operations. Those tools still call the API and do not receive direct database access.
Delegated authority
The MCP endpoint verifies a token issued for the MCP audience. It then uses OAuth on-behalf-of exchange to obtain a short-lived API token for the downstream API audience. See MCP OAuth.
Rollout status
Treat the MCP integration as unavailable until Arbol confirms all of the following: the standalone Worker is deployed, OAuth discovery and dynamic client registration are live, on-behalf-of exchange is enabled, the Composio toolkit is synchronized, and an end-to-end tool call succeeds.