Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
Launched this week
Cortex
Turn API specs into docs, SDKs, and MCP servers
666 followers
Turn API specs into docs, SDKs, and MCP servers
666 followers
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.
@nick_csu the idea of interactive API docs sounds sweet, for me, the way i'd use this is via mcp, being a SWE myself, and i find this solution useful personally, gonna try it out, thanks!
Cortex
@therayess Thanks! I'm glad you think the MCP approach is useful. Let me know how you find it when you try it out!
11 languages? my team can barely maintain two definitely giving this a shot over the weekend!
Cortex
@joseph_collins2 haha :). Hope you find it helpful for your workflow once tested.
@nick_csu yeh sure
Cortex
@hamza_afzal_butt Thanks so much, Hamza!
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 🙌
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.
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?