// the find
cortex-docs/cortex
Cortex - Generates interactive API documentation, typed SDKs, and MCP servers from OpenAPI, AsyncAPI, GraphQL, gRPC, OpenRPC, and Markdown.
Cortex takes OpenAPI, AsyncAPI, GraphQL, gRPC, and OpenRPC specs plus Markdown and generates SDKs in 11 languages, static HTML docs, and an MCP server from one config file. It's aimed at API teams who currently run separate tools for docs, client generation, and AI-agent context and want one pipeline instead of three.
The e2e suite actually compiles and runs generated SDKs in every target language (there's a test-rust, test-go, test-c, etc., each with real build scripts) plus a separate publish e2e against mock registries like Verdaccio and Conan — most codegen projects don't verify their own output this thoroughly. Merging multiple spec sources into one SDK with explicit rejection of ambiguous duplicate operation/type names shows they've hit that edge case in practice, not just documented the happy path. The MCP server generation goes beyond a bare server: it embeds specs, SDK guides, and project docs as resources so an agent actually has context, not just callable endpoints.
custom_head_html is injected into every doc page with no sanitization — the README says as much outright, which is fine for a single maintainer's config but a real risk if config ever comes from a PR branch or multi-tenant source. gRPC support is second-class in the MCP output specifically: the generated server exposes .proto files as static resources but can't call gRPC methods, so 'MCP server from gRPC' is weaker than the same claim for REST or GraphQL. The CLI ships as one npm tarball bundling core, codegen, mcp-gen, and docs-ui as internal workspaces rather than independent packages, so you can't pull in just the SDK generator without the rest. With 11 languages times 5 protocols times an Eta template layer, template drift across that matrix is the kind of maintenance burden that doesn't show up until someone reports a bug in, say, the Kotlin gRPC client specifically.