Cortex

嘿 Product Hunt 👋

我是 Nick，我做 Cortex，是因为在 AI 时代当工程师，意味着你的 API 越来越需要服务两类完全不同的用户：开发者和 AI 智能体。

但要同时支持这两类，往往就得把同样的活干两遍。你给开发者做文档和 SDK，然后又给智能体单独做 MCP 工具和上下文。

如今这些部分通常是分开维护的。它们会逐渐不同步，造成重复工作，还让 AI 智能体只能靠不完整或过时的上下文去理解你的 API。

Cortex 让你的 API 契约成为唯一事实来源。

把你的 OpenAPI、AsyncAPI、GraphQL、gRPC 或 OpenRPC specs，再加上 Markdown 交给它，Cortex 就能生成：
📚 给开发者的交互式文档
⌨️ 覆盖 11 种语言的类型化 SDK
🤖 带类型化工具和有据可依 API 上下文的 MCP 服务器

全部开源，MIT 许可。你可以自定义模板，把 SDK 发布到任何地方，生成的文档也可以自己托管。

思路很简单：把 API 只定义一次，然后给每个开发者和每个智能体提供真正用得上它所需的接口。

欢迎来看开源 repo：https://github.com/cortex-docs/c...

我很想听听正在做 API、SDK、开发者工具和智能体集成的团队反馈。

你觉得怎样才能让 Cortex 在你的工作流里更有用？

我们跑着一个小型 MCP 服务器，有 28 个工具，最耗时的部分不是类型，而是描述。

我们其中两条写的是“在 prospecting 前先 fetch，以跳过重复项”和“存为 DRAFT，而不是已发送”。这两条都不在任何 schema 里。第一条是顺序规则，第二条是为了让智能体别告诉你它已经发送了某个其实只是在排队的东西。

spec 会给你每次调用的形态，却完全不会说两个相似 endpoint 里哪个才是对的。对 SDK 来说这没问题，开发者会去看页面。对智能体来说，那一个字符串就是整个决策的依据。

所以生成 MCP 服务器时，tool description 里该放什么？spec 里的 summary 字段，还是别的什么？

SDK 生成是你们自己做的，还是用的 OpenAPI 那套？OpenAPI 生成出来的 C# 代码又乱又臃肿。

有时候我会先从文档开始，但写着写着就分心去重写 API 调用了。如果 Cortex 能从 specs 自动生成集成代码，也许能让我在还没全部写完之前不至于跑偏。不过我总是会跳过通读完整 spec，所以谁知道呢。

很喜欢 Cortex 把 AI 智能体和开发者都当成同一份 spec 的一等消费者，把唯一事实来源生成成 SDK、文档和 MCP 服务器，而不是重复做同样的工作。

我很想看看，当团队需要 API 规范未定义的行为时，它是怎么处理自定义代码的。