MCP formalizes AI tool discovery with a structured protocol handshake

The Model Context Protocol (MCP) uses a JSON-RPC handshake and capability negotiation for dynamic tool discovery, offering a robust standard for complex, multi-provider agent systems beyond simple function calling.

The Answer Up Front

For teams building complex AI agent platforms, especially those integrating numerous, dynamic, or third-party tools, the Model Context Protocol offers a necessary layer of architectural rigor. Developers building applications with a small, static set of internal functions should skip this. OpenAI's built-in function calling is more than sufficient and carries less overhead for simple use cases. MCP is a formal protocol, not a simple feature. It trades the immediate simplicity of a static tool list for the long-term robustness of a negotiated, discoverable tool ecosystem, making it a bet on a future of interoperable AI agents.

Methodology

This v0 review analyzes the Model Context Protocol (MCP) as described in a technical deep-dive published by Robert Pelloni on July 13, 2026. The source material provides a detailed walkthrough of the protocol's tool discovery mechanism, including JSON-RPC examples for the handshake and tool enumeration phases. The protocol version referenced in the examples is "2024-11-05".

This analysis is based entirely on the claims, code snippets, and protocol design presented in the source article. It does not include independent performance benchmarks, a hands-on evaluation of any official SDKs, or data on real-world adoption rates. Our assessment focuses on the protocol's architecture and its potential implications compared to existing methods for providing tools to language models. This review will be updated if we conduct independent testing or when new information on MCP's adoption becomes available.

What It Does

A structured handshake for capabilities

Unlike simpler tool-calling mechanisms that present a static list of functions, MCP begins with a formal negotiation. The client (an AI agent or IDE) sends an initialize request via JSON-RPC 2.0. This request contains a capabilities object declaring what the client supports, such as supportsToolDiscovery: true or a maxToolCount to limit the response size. The server responds with its own capabilities. This two-way handshake ensures both client and server agree on the rules of engagement, such as protocol version and supported features, before any tool information is exchanged. This prevents runtime errors that might occur if a client cannot handle a server's large or dynamic toolset.

Paginated and filtered tool enumeration

After the handshake, the client can request a list of available tools using a tools/list call. The protocol is designed for scale. For servers exposing hundreds of tools, the response is paginated using a cursor system. The server returns a partial list of tools along with a nextCursor token, which the client uses to fetch the next page. This prevents overwhelming the client with a single massive payload. The source also claims the protocol supports server-side filtering, allowing a client to request only tools matching a specific category or tag. This is a critical feature for resource-constrained agents that only need a subset of a server's full capabilities.

Schema-driven tool definitions

Each tool advertised by the server is defined by a name, a human-readable description, and an inputSchema. This schema is a standard JSON Schema object that specifies the tool's parameters, their types, and which are required. For example, a query_database tool would have its tableName and limit parameters strictly defined. This structured definition allows the language model to correctly formulate tool-use requests and enables the client to validate arguments before execution. While using JSON Schema is common, MCP formalizes its delivery within a discoverable, negotiated protocol.

What's Interesting / What's Not

The most interesting aspect of MCP is its explicit nature as a protocol, not just an API specification. The initial handshake for capability negotiation is a significant departure from the fire-and-forget model of providing a tool list in a single prompt. It treats the agent-tool relationship as a durable, stateful session. This suggests a design philosophy geared towards a future of interoperable agents and tool providers, analogous to how the Language Server Protocol (LSP) standardized communication between code editors and language-specific services.

The design also shows a pragmatic focus on real-world constraints. Pagination and filtering are not afterthoughts; they are core to the discovery process. This acknowledges that enterprise-grade tool servers can be massive and that agents may operate on devices with limited memory and processing power. It is a solution designed for production complexity.

What's less novel is the use of JSON Schema for tool definitions. This has become the de facto industry standard, largely established by OpenAI's function calling. MCP's contribution is not the schema itself, but the robust, discoverable framework built around it. The primary missing piece from the source article is context on governance and adoption. Is MCP an open standard? Who maintains it? Are there reference implementations? Without this information, it remains a compelling technical specification with an unclear path to becoming a widely adopted standard.

Pricing

MCP is a protocol specification, not a commercial product. There is no pricing associated with using the protocol itself. (As of July 2026).

Verdict

MCP is an architectural choice for builders of agentic platforms, not for developers building single-purpose applications. If your goal is to create an ecosystem where multiple, independently developed agents can dynamically discover and use tools from various providers, MCP's formal, negotiated approach provides essential guardrails. It solves for interoperability and scale from the outset. However, for a developer adding a handful of internal API calls to a chatbot using a single LLM provider, implementing an MCP client and server is unnecessary overhead. The right choice depends entirely on the scope of the system being built.

What We'd Test Next

For a v1 review, we would need to evaluate a real-world implementation. First, we would benchmark the latency of the MCP handshake and a multi-page tool enumeration against a simple REST endpoint that returns a flat JSON list of tools. Second, we would assess the developer experience of the

The investor read

MCP is an infrastructure play, not a product. Its success metric is adoption, not ARR. The investment thesis is not in MCP itself, but in companies that successfully build an ecosystem around it, either by providing best-in-class developer tools for MCP or by becoming the dominant tool hub that speaks it. The model here is Red Hat for Linux or HashiCorp for infrastructure-as-code. MCP's primary risk is platform capture. If a major AI provider like OpenAI or Google releases a proprietary but 'good enough' tool discovery protocol that gets bundled with their models, a more formal, open standard like MCP could be relegated to a niche. An investable company in this space would need to demonstrate a clear path to becoming the de facto standard through strong partnerships and superior developer experience.