> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anyreach.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Coverage and limits

> What the MCP server can reach and what it cannot.

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](/mcp/tools-and-discovery). For the bigger picture, see the [MCP overview](/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>`.

| 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_`          |

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.

<Note>
  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.
</Note>

## 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.                                                     |

<Warning>
  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.
</Warning>

## 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:

| 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`      |

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

<CardGroup cols={2}>
  <Card title="MCP overview" icon="plug" href="/mcp/overview">
    How the MCP server fits into the platform.
  </Card>

  <Card title="Tools and discovery" icon="magnifying-glass" href="/mcp/tools-and-discovery">
    Browse and search the catalog from your client.
  </Card>
</CardGroup>