A full API specification is far too large to put in a model's context, and the split here matches how a person uses documentation: skim the index, then open the one entry you need. Supporting GraphQL, OpenAPI and gRPC behind the same two tools means an assistant working across a mixed estate does not need a different mental model per protocol.
An MCP server that turns API specifications into something a model can look things up in. You list your sources — local files or remote endpoints — in one environment variable, and the server fetches, processes and caches them, refreshing periodically. Two tools then expose the result: a catalogue of methods, and the full request, response and error shape for one of them.
- `api_docs` — every available API method across the configured sources, each with its name, its type (a GET or POST for REST, a query or mutation for GraphQL) and a short description, optionally narrowed to one `sourceName`
- `api_search` — the full definition for one method by `resourceName`, returning its request structure, response structure and error shape
- GraphQL from `graphql` or `gql` files or JSON introspection results, local or remote — a remote endpoint can carry an Authorization header
- OpenAPI and Swagger from `yaml`, `yml` or `json` schemas, local or remote
- gRPC from `proto` files or via reflection against a running endpoint
- An in-memory cache with a TTL and periodic refresh, so schemas stay current without a fetch on every call
Nothing beyond access to your own schemas; remote sources that need authentication take their credentials in the source definition's `headers`. Sources are configured through `API_SOURCES`, a JSON array of file or URL entries each naming a `name` and a `type` of `gql`, `api` or `grpc`. The package is `api-docs-mcp` (1.0.24 in package.json); the documented client entry runs `npx api-docs-mcp` over stdio with `API_SOURCES` in the `env` block. Building from a clone uses `pnpm install` and `pnpm build`.
One command — npx api-docs-mcp