Skip to main content
The MCP server builds its tool catalog by introspecting the OpenAPI spec of every downstream Anyreach service and flattening each operation into a callable tool. This page explains exactly which operations are covered, how fresh the catalog is, and the hard limits you will hit. For how the catalog is exposed and searched, see Tools and discovery. For the bigger picture, see the MCP overview.

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>.
ServiceCoveredTool prefix
Core (/core)Yescore_
Workflow (/workflow)Yesworkflow_
Knowledge base (/knowledge-base)Yesknowledge_base_
Campaign (/campaign)Yescampaign_
AdminYesadmin_
Within each service, the catalog includes every operation whose HTTP method is 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

LimitBehavior
Non-JSON request bodiesOperations 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 uploadsAs a consequence of the above, endpoints that take file uploads — such as uploading knowledge-base documents — are not callable via MCP yet.
Duplicate operation namesIf two services produce the same tool name, only the first is kept; the duplicate is dropped from the catalog.
Non-JSON methodsOperations using HTTP methods other than GET, POST, PUT, PATCH, or DELETE are not catalogued.
Request headersHeader parameters defined on an operation are ignored. Auth headers are managed centrally by the proxy; other header inputs are not passed through.
You cannot upload files through MCP. The request body for an upload endpoint is multipart, which the catalog flags as unsupported, so the tool call returns 400 before any request reaches the downstream service. Upload documents through the API or the dashboard instead.

Catalog freshness (TTL)

The catalog is built once on first use and then cached. It refreshes on a time-to-live, controlled by MCP_CATALOG_TTL and defaulting to 600 seconds (about 10 minutes).
first call ──> build catalog (blocking) ──> serve

                  within TTL ────────────────┘  serve from cache

                  past TTL ───> serve stale cache + refresh in background
Two consequences follow:
  • 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.
If introspection of all services fails while a catalog already exists, the previous catalog is kept rather than emptied, so tool calls do not start failing.

Timeouts

Two timeouts apply, both configurable via environment variables:
StageDefaultVariable
Introspection — fetching each service’s /openapi.json10 secondsMCP_INTROSPECT_TIMEOUT
Proxy — forwarding a tool call to the downstream service30 secondsMCP_PROXY_TIMEOUT
If introspection of a single service times out or fails, that service is simply absent from the catalog (the others still load). If a proxied call cannot reach its downstream service, the tool returns a 502.

Next steps

MCP overview

How the MCP server fits into the platform.

Tools and discovery

Browse and search the catalog from your client.