Cortex - Turn API specs into docs, SDKs, and MCP servers
by•
Cortex is an open source API knowledge layer that turns OpenAPI, AsyncAPI, GraphQL, gRPC, and OpenRPC specs into interactive documentation, typed SDKs in 11 languages, and MCP servers for AI agents.
Replies
I would be interested to see how it custom code when teams need behavior beyond what the API spec defines.
Macaly
docs + sdks + mcp from one spec, thats a usefull combo. open source too, nice 🙌
11 languages? my team can barely maintain two... definitely giving this a shot over the weekend!
Cortex
@alira_salu Haha, I totally get it! Take your time, and let me know what you think after you've had a chance to play around with it or need assistance with setup.
we have a mix of graphql and REST endpoints in one project. can cortex bundle both into a single mcp server or do we split them?
Cortex
@sandy_leventh great question :) ! Yes, you can definitely combine them within a single project using unlimited GraphQL and REST sources to generate one single MCP server for all of them.
@nick_csu Super helpful to know, thanks for clarifying Definitely makes combining mixed architecture endpoints much smoother.
The docs preview looks super clean. genuinely impressive work on unifying asyncapi and openapi into one workflow.
Cortex
@uttam_kumar31 Haha, thanks! :) Yes, managing multiple separate docs was a major frustration when I was building API docs for clients, so I really wanted to create a tool that can support a single source of truth.
Love that Cortex treats AI agents and developers as first class consumers of the same spec, generating one source of truth into SDKs, docs, and MCP servers instead of duplicating the work.
Cortex
@ilko_kacharov Thanks! Agree, it's much better when the spec serves both humans and AI agents without needing constant duplication.
Second Brain for AI
sometimes I start with the docs but then get distracted rewriting API calls. if Cortex auto-generates integration code from specs, might save me from wandering off before everything's written up. but I always skip reading the full spec first, so who knows.
we run a small mcp server, 28 tools, and the part that took longest was not the types. it was the descriptions.
two of ours read "fetch before prospecting to skip duplicates" and "stored as DRAFT, not sent". neither of those is in any schema. the first is an ordering rule, the second is there so the agent doesnt tell you it sent something that is only queued.
a spec gives you the shape of every call and nothing about which of two similar endpoints is the right one. for the sdk thats fine, the developer reads the page. for the agent that one string is the whole basis of the decision.
so when you generate the mcp server, what goes into the tool description? the summary field from the spec, or something else?