Asro
In the rapidly evolving landscape of artificial intelligence integration, the Model Context Protocol (MCP) has emerged as a focal point for developers seeking to bridge the gap between Large Language Models (LLMs) and external data sources. While the current industry discourse is almost exclusively obsessed with "tooling"—the number of functions a server can expose to an agent—a quieter, more profound shift is occurring beneath the surface.
Industry observers and API architects are beginning to realize that the true innovation of MCP does not lie in its ability to execute remote functions. Rather, it lies in two often-overlooked primitives: Prompts and Resources. These components represent a fundamental rethink of how we package interface design, and they carry implications that extend far beyond the niche of AI agents, promising to revolutionize the way we build traditional REST and GraphQL architectures.
The Anatomy of the MCP Revolution
To understand why prompts and resources are so critical, one must first look at how the MCP ecosystem has been framed since its inception. Most marketing and developer documentation emphasize "tools"—the ability for an agent to perform an action, such as "fetch weather" or "update database." This has led to a "scorekeeping" mentality, where developers boast about the sheer volume of tools their servers expose.
However, this focus is inherently limiting. MCP is not merely a tool-execution layer; it is an interface specification. By formalizing "Prompts" (pre-written, parameterized, and curated queries) and "Resources" (contextual, co-located documentation and data), MCP has stumbled upon a solution to a decades-old problem in API design: the disconnect between an interface’s technical capabilities and its usability.
Chronology: From Documentation Silos to Integrated Intelligence
The Era of Static Documentation
For the past two decades, the standard for API interaction has been the separation of concerns. Developers would build an API (REST or GraphQL) and then "outsource" the understanding of that API to external portals. Documentation lived on Wikis, static sites, or separate PDFs. If an API changed, the documentation would drift, leading to the infamous "stale documentation" problem that has plagued software engineering since the advent of the web.
The Rise of Agentic AI
With the emergence of LLMs, the necessity for machine-readable interfaces became paramount. Initially, developers simply wrapped existing REST endpoints in agentic tools. This allowed models to "call" functions but did not inherently provide the model with the intent behind those functions or the contextual data required to use them correctly.
The MCP Paradigm Shift
With the introduction of the Model Context Protocol, the architecture shifted. MCP servers were designed to act as a bridge. While the industry fixated on the "Tool" primitive, early adopters began to realize that the "Prompt" and "Resource" primitives allowed developers to bundle "the right questions" and "the necessary context" directly with the service. This transformed the API from a passive set of endpoints into an active, self-describing ecosystem.
Supporting Data: Why "Good Questions" Matter
The value of the MCP prompt primitive is not just theoretical; it is a measurable efficiency gain. When a developer provides an API consumer (whether a human or an agent) with a raw list of two hundred operations, the cognitive load is immense. The developer is essentially saying, "Here are the tools; good luck figuring out how to combine them effectively."
Collapsing the Gap
By contrast, an MCP prompt acts as a "blessed" query. It is a curated, parameterized template that captures the "expert knowledge" of the system architect. Data from early implementations across platforms like APIs.io suggests that:
- Onboarding Speed: Users—and agents—reach "useful output" significantly faster when provided with curated prompts rather than raw endpoint lists.
- Precision: By narrowing the scope to the fifteen "questions actually worth asking," developers reduce hallucination rates in AI agents, as the agent is guided toward high-value, high-precision operations.
- Formalization: What was previously considered "best practice" in API evangelism has now been formalized into a protocol requirement, ensuring that the best way to ask for data is baked into the service itself.
The Resource Primitive: Co-location as a Design Philosophy
If prompts are the "good questions," resources are the "contextual backbone." In traditional API development, a developer attempting to use an endpoint might have to jump between three different tabs: the API reference, the schema definition, and a "getting started" guide that may or may not be up to date.
MCP changes this by making the resource—the documentation, the schema, or the reference data—a first-class citizen that "rides along" with the capability.
The End of the "Stale Portal"
By binding the reference material directly to the operation, MCP solves the synchronization problem. When an agent requests a capability, it simultaneously receives the context required to use that capability successfully. This co-location ensures that the "how-to" material is never more than one hop away from the "what-it-does" logic. It is a quiet, structural win that effectively renders the traditional, siloed documentation portal obsolete for machine-to-machine interactions.
Official Perspectives and Industry Implications
While some critics have dismissed MCP as "last-mile plumbing" or highlighted its current gaps in authorization and authentication, the consensus among API architects is shifting toward the portability of these ideas.
"The plumbing is disposable," noted one lead developer in the API space. "The protocol itself may evolve or be replaced, but the lesson that capability, curated queries, and context belong together is a design principle that will endure."
Implications for REST and GraphQL
The most significant implication of the MCP model is that these ideas are not locked behind the protocol. They are, in fact, "stolen" ideas that should be imported back into the broader API ecosystem:
- For REST: Developers should move beyond simple OpenAPI specifications. They should ship "blessed" parameterized example queries—essentially prompts—as part of the API distribution.
- For GraphQL: Reference context should be bound to operations rather than banished to an external repository. By embedding context directly into the schema or metadata of the API, developers can mirror the "co-location" benefits of MCP without needing to implement the full protocol.
The Future: A Call to Action for Developers
The current obsession with MCP tooling is a classic case of industry tunnel vision. We are counting the hammers, but we are ignoring the blueprint. If you are building an MCP server, your focus should shift toward the sophistication of your prompts and the richness of your resources. This is where your consumers will derive the most value.
However, if you are a developer working with "plain old" REST or GraphQL, the mandate is even clearer: steal these ideas.
- Curate your interface: Stop shipping raw endpoints. Ship the "good questions" that represent the most valuable paths through your system.
- Bind your context: Stop maintaining external, stale wikis. Find ways to attach documentation and reference data directly to your endpoints so that the "how" is always paired with the "what."
Ultimately, the Model Context Protocol has provided us with a diagnostic tool for modern API design. It has shown us that the most significant problems in software integration were never about the lack of transport layers—they were about the lack of intent and context. By bringing the "good questions" and the "necessary data" into the interface itself, we can build a future where APIs are not just functional, but inherently intelligent. The tools may get the headlines today, but the prompts and resources will define the architecture of tomorrow.
Asep Darmawan
