why is "MCP" implemented as server exposing a set of endpoints, rather than as some JSON schema for defining tool descriptions and allowing these JSON files to be accessed over http? what is the purpose/benefit of the middleman server?
why is "MCP" implemented as server exposing a set of endpoints, rather than as some JSON schema for defining tool descriptions and allowing these JSON files to be accessed over http? what is the purpose/benefit of the middleman server?
You are expected to have multiple MCP servers, it's fine for a server to provide just a single tool. The idea is that different providers wrap their tools in an MCP server, and your agent talks to several of these servers.
MCP provides additional concrete details as to what the HTTP calls should look like, which avoids having too many arbitrary differences between different tools
the issue is that the MCP couples two things: tool discovery (an LLM friendly description of what tools are available and how to invoke them), and tool implementation. but "implementation" both takes effort, and doesn't need new standards. so why not focus only on discovery?
Imagine you need to connect to hundreds of tools in a single agent. MCP's goal is to drastically reduce the effort of this goal.
Most of MCP is about discovery and basic principles for tool implementation. MCP's value is that all tools are exposed in a very similar manner. This was not standardized before.
yes, but this can be achieved also if i provide a json schema for describing tools and point to files containing such descriptions, with the implementations being done externally to the protocol. what's the benefit of coupling in the implementation?
The implementation is not coupled. What is standardized is how to connect to the implemenation.
If you take what you described and add support for stdio transport and resources/prompts, you’ve basically just reinvented MCP. It’s not too complicated.
I had the same question. My guess is it’s done this way because MCP aims to cover more than API calls, eg providing docs for RAG from a DB that genuinely gets updated often
can you elaborate on these "more than API calls"? what else does it provide?
“Resources” modelcontextprotocol.io/docs/concept...