Critical Review of Model Context Protocol
There is quite a buzz around the announcement of MCP. YouTube and X (formerly Twitter) are flooded with tutorials and demonstrations. It is a useful attempt toward much-needed standardization, but some decisions seem to have been made in a hurry, or perhaps by Claude!It ignores 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.
Mechanisms to discover servers or retrieve server specifications have been ignored. The security aspect has been 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 compensate for this deficiency with the qualification that the 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 on 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 provide data in some form, while tools are functions invoked by the LLM.
Is a 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. A large number of API calls are about some sort of data request. Any data service can be defined as a tool. For example, data provided by a file service can easily be defined as a tool that fetches the list of files from a machine or from cloud services such as Google 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 from which they can be fetched. This is problematic for resources accessible through GraphQL or where complex data objects are sent using POST requests.
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 :
The usefulness of prompt templates provided by the server may be limited considering that they may be different for different LLM. Servers are supposed to be data sources and prompts do not really fit into the process. If servers are written as part of a specific application then that may make sense. The 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 data only.Pagination :
Pagination in MCP uses an opaque cursor-based approach, instead of numbered pages.It does not offer the client a way to move directly to an arbitrary page. Why should the client not be able to jump directly to a page? 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 the server, this is a choice that the application should make and not something to be dictated by the server. If the 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.