Cool. The main thing I like about MCP is the authentication story, particularly the standardisation around OAuth.
Because of that, I think it is often worth wrapping an API in an MCP server. I actually had to do this recently.
I have been working on an open-source project called crmkit.ai. I was not planning to add MCP support because the project already works in a very agent-native way, where the agent reads the `setup.md` file at the root of the server and then uses `curl`.
That works well for normal agents. It kind of works in claude.ai, although you need to allowlist the domain. It does not work on chatgpt.com because the sandbox does not allow arbitrary outbound web requests. It should work fine in Codex, Claude Code, etc. because those run locally.
For ChatGPT, I was forced to write an MCP server. But because this is supposed to be an agent-first CRM, I thought that instead of exposing hundreds of small tools and polluting the context, why not expose a single tool called `request`, where the LLM writes the actual HTTP request?
That should work, right?
It does not. ChatGPT effectively forces you to unwrap the entire API into lots of small tools, because each one may need to be authorised separately.
Anyway, I ended up doing it, but needless to say, the design feels wrong. It would have been much better if the MCP server could expose a single `request` tool and keep the context tight.
The single-tool concept does work. We use crmkit internally with fully autonomous agents, and I even use it personally as a productivity tool.
The moral of the story is that MCP has great authentication but I rather not use it if I can. If I need to use it I would prefer to expose a single tool that write the raw request even-though it feels like a hack and it does not work across all chat systems.
I hope this anecdote helps.