Coverage
The catalog is assembled from five services. Each service’s/openapi.json is fetched, and every operation is turned into one MCP tool named <service>_<operation>.
| Service | Covered | Tool prefix |
|---|---|---|
Core (/core) | Yes | core_ |
Workflow (/workflow) | Yes | workflow_ |
Knowledge base (/knowledge-base) | Yes | knowledge_base_ |
Campaign (/campaign) | Yes | campaign_ |
| Admin | Yes | admin_ |
GET, POST, PUT, PATCH, or DELETE. Other methods are skipped.
For every covered operation, the server composes a single JSON Schema from the operation’s path parameters, query parameters, and JSON request body, so the operation is callable through MCP with one structured argument object.
The MCP server reaches downstream services with the same credentials you present to the API. A user PAT (
pat_) still requires X-Anyreach-Org, and an org API key (ak_) carries its org implicitly — the proxy forwards Authorization: Bearer <token> and, when present, the X-Anyreach-Org header on every call. MCP does not widen what your token can do.What is not covered
| Limit | Behavior |
|---|---|
| Non-JSON request bodies | Operations whose request body is multipart, binary, or any non-application/json content type are catalogued but marked unsupported. Calling one returns 400 with a message naming the content type. |
| File uploads | As a consequence of the above, endpoints that take file uploads — such as uploading knowledge-base documents — are not callable via MCP yet. |
| Duplicate operation names | If two services produce the same tool name, only the first is kept; the duplicate is dropped from the catalog. |
| Non-JSON methods | Operations using HTTP methods other than GET, POST, PUT, PATCH, or DELETE are not catalogued. |
| Request headers | Header parameters defined on an operation are ignored. Auth headers are managed centrally by the proxy; other header inputs are not passed through. |
Catalog freshness (TTL)
The catalog is built once on first use and then cached. It refreshes on a time-to-live, controlled byMCP_CATALOG_TTL and defaulting to 600 seconds (about 10 minutes).
- A newly added or changed endpoint may take up to the TTL to appear in the catalog. There is no manual cache-bust through MCP.
- When the cache is stale, the server keeps serving the existing catalog and refreshes in the background, so calls are not blocked while the rebuild runs.
Timeouts
Two timeouts apply, both configurable via environment variables:| Stage | Default | Variable |
|---|---|---|
Introspection — fetching each service’s /openapi.json | 10 seconds | MCP_INTROSPECT_TIMEOUT |
| Proxy — forwarding a tool call to the downstream service | 30 seconds | MCP_PROXY_TIMEOUT |
502.
Next steps
MCP overview
How the MCP server fits into the platform.
Tools and discovery
Browse and search the catalog from your client.

