MCP (Model Context Protocol)

The same gate as the web app

There is no second data path. A tool call goes in-process through the same handling as an HTTP request: the hostname resolves the organisation, row-level security is bound, and the key's permissions are resolved. A call that is not allowed surfaces the API's own 401 or 403 envelope as a tool error. The incoming key is never forwarded to any external service; the proxy only ever calls the API in-process.

OAuth mints a key, not a second kind of access

Clients that want a connector rather than a pasted secret, Claude and ChatGPT first among them, get a full OAuth 2.1 flow: self-registration, authorization code with PKCE, refresh, revocation and discovery. What that flow hands back is an ordinary API key belonging to the person who consented, so every rule that governs a personal key governs this too. And the authorization server signs nobody in: consent runs on the session the web app already holds, with your password and two-factor verification or with your organisation's SSO. An anonymous call to /mcp gets a 401 with the invitation to do OAuth, so a client discovers the server by being refused and a stranger cannot see which modules you run.

Read-first is a choice at mint time

The tool surface includes writes, because the whole API is in it. What a client may actually do lives in its key's permissions, and the screen starts on read only. A personal key and an OAuth connection are additionally capped by their owner's live permissions on every request, so demoting someone narrows their connections with them. Choose everything I may do or read only at consent and that is stored as a rule rather than as today's list: a module that arrives later is included by itself, without a chat client having to ask for consent again, and never wider than the person. Choose myself stays a fixed list, and the screen says so. A service-account key carries exactly the scopes you granted it.

• Scopes come from the same permission catalogue as roles, including the own/any variant such as time.entry.read:own
• The API's deny-by-default rule answers every call, an AI's included
• Only enabled modules contribute routes, so the tool surface tracks what you actually run

An address per job

The full surface is some 620 tools. A coding assistant reads that list once; a chat client puts every tool in the model's context on every turn, and ChatGPT allows 5,000 tokens for all tools together. So the same server also answers on narrower addresses. A module section is derived from that module's routes, so whatever arrives tomorrow is in it tomorrow; a bundle names modules and never individual tools; and the compact fourteen is the only hand-picked list, because an outside ceiling forces it. A narrower list is not a smaller permission: what a key may do is decided when it is minted.

• /mcp/compact: fourteen read-only tools, the right choice for ChatGPT
• /mcp/agent: clients, contacts, projects, tasks, hours and contact moments
• /mcp/infra: domains, websites, hosting, Cloudflare, OXXA, uptime and WordPress
• /mcp/finance: invoices, subscriptions and payments
• /mcp/growth: Google Ads, Analytics, Search Console, Tag Manager, marketing and reporting
• /mcp/<module>: one module, for example /mcp/google-analytics, /mcp/google-search-console or /mcp/wordpress
• An address that points at nothing is refused with the list of what does exist

Transport and pace

Streamable HTTP, stateless, with JSON responses: every JSON-RPC POST stands alone, so it works behind any load balancer and from plain curl. Each key is limited to 600 requests per minute, generous for automation and a firm ceiling under a leaked key. The Laatst gebruikt (Last used) column deliberately lags: it is updated out of band, so a tool call never waits on it.