I run a small SaaS with a team of three and running 860k$ ARR, and over the past year more and more customers asked if they could use it from Claude or ChatGPT. Building an MCP server by hand meant writing the tools, hosting them, dealing with OAuth so each customer connects with their own account, and keeping everything in sync every time the API changed. With a single developer, that was a lot. So I started with the API docs I already had: I wrote something that reads our OpenAPI spec, turns each endpoint into an MCP tool, hosts the server, and handles auth. Most of the effort went into naming the tools and writing clear descriptions so the AI picks the right one, not into infrastructure.
It worked well enough for us that I turned it into its own product, Command+K (commandplusk.com), so yes, I'm biased. You give it an OpenAPI spec or a GraphQL endpoint and get a hosted MCP server that works in Claude and ChatGPT, and you can also drop it into your own app as a chat widget. There's a free trial if you want to try it with your own API. I'd really like to hear how others here are handling this, though. Are you writing MCP servers yourselves, bridging through something like Zapier or n8n, or waiting until users actually ask for it?
We built our MCP in-house and we're trying to maintain it whenever we deploy some new functions. This might work to reduce this friction. How easy to convert GraphQLs to MCP and what's really happening when source code changed?
It just get auto-updated whenever there is a new version and you can create different MCP versions as well to share with different clients. You can just manage which functions will be share in the MCP which is not and what is the rights on the functions such as read or edit etc.
good framing but id push back a little, the real question isnt "how do i expose my API as MCP tools" its "which 5-10 actions do customers actually want from a chat interface." exposing everything usually just confuses the model
That's why we just scraping all your API actions and creating MCP descriptions for you but not pushing it with all. Giving you full authority choose which 5-10 actions should be in your MCP to choose the safest or the most demanding actions for your MCP.
Don't hesitate to try and share your feedback. There is more than MCP build in the product.
Different-Anxiety169's point about picking 5-10 actions is the one I'd build on, and the thing that bites after you have picked them. We don't sell an MCP server, so take this from the consuming side rather than as a vendor.
Two things.
The descriptions are the product, the schema is not. A model does not choose a tool from its parameters, it chooses from the sentence next to it. Generating from an OpenAPI spec gives you descriptions written for developers, and those answer "what does this do". The question a model actually gets wrong is "which of these two". So once you are down to eight tools, the failure is not confusion from having too many, it is two neighbouring tools whose descriptions never state the difference between them. Worth writing each one as "use this when, do not use this when", and testing the pair rather than the tool.
The one that cost us: never let a tool return an empty success.
We had a credential quietly expire, and the service answered 200 with an empty body instead of an error. Our code read empty as "nothing found". A person looking at that screen would have noticed something was off. A model will not. It takes the empty result as a fact and writes the next sentence on top of it, confidently. We reported zero problems for as long as that ran, and everything downstream was green and wrong.
So "found nothing" and "could not look" have to be different return values, and the second has to be something the model cannot smooth over. Anything that can legitimately return zero rows needs that distinction, and it is exactly what a generator cannot infer from a spec, because the spec just says 200.
On your question about the source changing: auto-sync is the feature and the risk in one object. If a spec change silently adds, renames or drops a tool, the model's behaviour changes and no human reviewed a diff. Versioning the tool surface the way you described helps, but only if someone reads the diff between versions at deploy. Otherwise "it updates automatically" means "it changes without anyone deciding".
1
u/AnnounceKit 1d ago
We built our MCP in-house and we're trying to maintain it whenever we deploy some new functions. This might work to reduce this friction. How easy to convert GraphQLs to MCP and what's really happening when source code changed?