Critical Review of Model Context Protocol
There is quite a buzz around the announcement of MCP. YouTube/twitter are flooded with tutorials and demonstrations. It is a useful attempt towards much needed standardization but some decisions seems to have been made in a hurry or may be by Claude!!!It ignores all the existing apis and protocols that would need to be rewritten with at least a layer before being usable. The details of the architecture seem to be different only in terms of using json-rpc . It ignores established vocabulary or does not provide sufficient explanation of what a certain thing means.
Mechanism to discover the servers or get server specifications have been ignored. Security aspect is left for later. The focus is on local and the servers are routines called by the clients. However, not many local applications can live without working with APIs. The concept of transport is introduced to cover for the deficiency with a qualification that protocol is transport agnostic. The purpose or definition of transport is not provided. Neither does it say where it fits in.
The following will elaborate the points made above.
Servers :
Servers provide the fundamental building blocks for adding context to language models via MCP. These primitives (prompts, resources, tools) enable rich interactions between clients, servers, and language models :Resources :
Resources allow servers to share data that provides context to language models, such as files, database schemas, or application-specific information.Considering popular usage, it is difficult to see the need to separate tools and resources as described in MCP. Resources are data providers of some form and tools are functions being called by the LLM.
Is weather service a tool or a resource? Is there a difference? Is there a need to differentiate?
Claude’s response to
“In LLM parlance what is a tool?”
'In the context of Large Language Models (LLMs), a 'tool' typically refers to a specific function, API, or capability that can be dynamically called or invoked by the LLM to extend its capabilities beyond its base knowledge and generation abilities.'
And'Common Tool Types Calculation tools (mathematical operations) Search tools (retrieving information from a database) ...... API integration tools'
Defining tools and resources separately seems redundant. Large number of API calls are about some sort of data requests. Any data service can be defined as a tool. E.g. Data provided by file service can easily be defined as a tool which fetches the list of files from the machine or a cloud service like drive or Dropbox. A database schema can be exposed through a tool that exposes the schema and so on.
Such resources are expected to be discoverable through a list API which may provide a direct list of resources or a template URI Ifrom which they can be fetched. This is problematic for resources accessible through Graphql or a complex data object being sent over post.
If resources are something to be used by the application, it may decide not to expose the tools to the LLM. It probably is not for the server to decide.
Prompts :
Usefulness of prompts template given by server may be limited considering that they may be different for different LLM. Servers are supposed to be data source and prompts do not really fit into the process. If servers are written as part of specific application then that may make sense. Same server and its data may be used for multiple purposes making prompts less relevant.Prompts are best handled by the application to suit its purpose. Servers can be a source of
Pagination :
Pagination in MCP uses an opaque cursor-based approach, instead of numbered pages.It does not offer the client a way to move to a random page. Why not should the client be able to jump to a page if needed? It would be wrong to assume the way paging works for any server.
Logging :
A minor redundancy here is the server specifying the logger. Unless the log is to be processed by server, this is a choice that the application should make and not something to the dictated by server. If server is specific about such logging, it would simply log using a certain logger instead of sending it back to the application.
Frequently Asked Questions (FAQs)
The Model Context Protocol (MCP) is an open standard that defines how AI models connect to external tools, data sources, and services using a consistent, JSON‑RPC–based protocol. It aims to replace custom integrations with standardized, interoperable connections.
MCP tries to simplify how AI applications access live data, tools, and workflows by providing a single way to discover capabilities, request context, and call tools. This reduces integration boilerplate, improves observability, and can lower hallucinations by grounding models in real data.
Traditional APIs focus on one system exposing endpoints, leaving each AI integration bespoke. MCP standardizes how AI “hosts,” clients, and servers discover resources, prompts, and tools, and manage context across interactions using a shared protocol layer.
MCP defines hosts (AI apps), clients (connectors inside the host), and servers (services providing data and tools). Servers can expose resources, prompts, and tools, while clients can handle sampling, roots, and elicitation to enable more agentic workflows.
Criticisms include unclear vocabulary, an incomplete approach to discovery, and deferring many security details. Some reviews also note that it feels tuned to specific product internals and may be hard to align with existing APIs and protocols without extra layers.
MCP supports controlled contextual access and role-based patterns in principle, but many implementation details around authorization, transport, and exposure boundaries are left to implementers. This flexibility creates both power and complexity for real-world deployments.
MCP is most relevant if you are building multi-tool, multi-data-source AI agents and want a standardized way to plug in services across different providers. Teams heavily invested in LLM tooling and orchestration may benefit from its interoperability and governance features.
MCP is evolving quickly, and some specifications and ecosystem tooling are still maturing. Many teams will experiment in pilots or specific domains first, rather than fully replacing all existing integration patterns.