Why not just publish your API docs and let the client's bot chain together what calls need to be made.
You could even repurpose the MCP so you only ever produce the API documentation as EVERY response. No LLM necessary.
Comments
jwally•56m ago
Probably covers most use cases and is a lot cheaper and safer.
Antolius•31m ago
Having a dedicated spec makes it easier for MCP client apps to implement some nice features out of the LLM loop (e.g. OAuth flow or elicitation ), some handy user facing features (e.g. prompts and resource), and some more advanced use-cases (like server sent notifications).
But yeah, a lot of it (including tools) maps well to HTTP semantics. In fact, at work we implement our features as HTTP APIs, and we’ve built a framework that exposes them as MCP servers.
legalwarrior•34m ago
Whats an mcp ? Mcp connectors Iv heard of
al_borland•1m ago
From my limited understanding, it’s basically an API, rewritten for us by AI agents. So the humans can consume your REST API, while the agents will use the MCP to effectively do the same thing.
vpk11•32m ago
I use CLI tools for Git, Atlassian (ACLI), and Metabase, plus custom SigNoz shell scripts to drive API calls instead of an MCP server. This setup works very well at the moment for me.
owebmaster•28m ago
Is anyone forcing you to use MCP? You don't need it. If you can't see the benefit of it, don't use it.
jwally•22m ago
It's why I asked the question. Maybe I missed something.
owebmaster•6m ago
MCP is an API. The biggest difference is that it defines some primitives that AI clients know how to implement beforehand so every MCP server works similarly, otherwise each API implements its own way to list the tools available, change/react to changes, authorization, session management, etc. MCP *is* an API.
AznHisoka•16m ago
What’s the harm in being curious and seeing what you might be missing?
owebmaster•10m ago
There's no harm in being curious but why frame it like the thing you don't know how to use is not useful? That's harmful.
jwally•56m ago
Antolius•31m ago
But yeah, a lot of it (including tools) maps well to HTTP semantics. In fact, at work we implement our features as HTTP APIs, and we’ve built a framework that exposes them as MCP servers.