I was tired of connecting my own API to Claude, I wrote the general solution (open source)
热度趋势
趋势数据积累中
百分比基于当前可用热度信号，而非评论数或独立用户人数。
一位开发者因厌倦了手动将API连接到Claude Desktop而创建了一个开源的通用解决方案。该开发者发现，现有方法要求为每个端点进行大量的API定义、参数验证和错误管理，导致每次API更改都会产生大量的维护工作。现在，他们正在寻求反馈和真实的API使用场景，以指导其解决方案的进一步开发。
I have been using Claude Desktop for a while, I wanted to connect the API in my own project to the assistant. As I researched, the same phrase appeared everywhere: "type an MCP server first." In other words, if you have 40 endpoints, you will write the definition of those tools manually, parameter verification, error management and so on. It took me a day, and on top of that, it would need maintenance again with every API change. I got angry.
I said I already have an OpenAPI document, all the information is there, why am I writing it a second time? Finally, I wrote the general solution, I named it mcpify.
What does it do: you say mcpify serve openapi.json, every endpoint in the document turns into a MCP tool. You add a single line to the config of Claude Desktop or Cursor, it's done. It does not generate code, it reads the document at the time of serve; If the API changes, the tools are also updated when you restart it.
Parts that I think work:
- If you give --read-only, it only opens the GET tips, the assistant can't accidentally delete anything
- You only show a certain group with --tag, when you show 200 vehicles at once, the model's token goes fast anyway
- Reads the API key from the environment variable, you don't write it to the command line or config file
Let me also tell you what's missing: If the API doesn't have an OpenAPI document, you need to write it down first, that part is what I haven't solved yet.
Look if you want: https://github.com/furkan708/mcpify
I'm open to criticism, especially "you should have done it like this" type feedback adds something to me. There's something I'm curious about: which API would you connect first? If I see real scenarios, I will continue to develop from there.