The decision that matters here is chunking by endpoint instead of by document: a match comes back with its full parameter list rather than a fragment, which is what lets a model construct a correct call on the first attempt. Authentication stays yours — the request tool takes headers, and the README's own project prompt tells the model to add the bearer token itself.
An MCP server for API specifications too large to hand a model directly. It indexes one endpoint per chunk with a MiniLM embedding model, keeps the index in memory with FAISS, and answers a natural-language query with the full documentation for the matching endpoints — then executes the request you build from it.
- Endpoint schemas matched by intent and returned whole — path, method, parameters and response format — `{prefix}_api_request_schema`
- HTTP requests executed against the API with method, URL, headers, query parameters and body, returning status code, headers and body — `{prefix}_make_request`
- One instance per API: the tool namespace comes from `MCP_API_PREFIX`, so several specs can be served side by side without name collisions
- A sentence prepended to every tool description via `GLOBAL_TOOL_PROMPT` — how you tell the model which API this instance covers
- A base URL taken from the spec automatically, or overridden with `API_REQUEST_BASE_URL` when you point at staging
No account and no key of its own: the spec URL goes in `OPENAPI_JSON_DOCS_URL` and any API credentials travel as headers on the request tool. `MCP_API_PREFIX` defaults to `any_openapi`. Runs from the Docker image `buryhuang/mcp-server-any-openapi:latest` on linux/amd64 and linux/arm64. The README also gives a pip line for `mcp-server-any-openapi`, the pyproject name at 0.1.0, which PyPI does not have. Outside the Docker image the embedding model is fetched on first launch, which the README puts at roughly 15s of cold start. linux/arm/v7 is not supported.
Run a container — pull the image and point your client at it