Deconstructing AI Agent Architecture: MCP Is More Than an API Wrapper — Skills over MCP Deserves Your Attention

Nearly 90% of MCP Servers Are Just REST API Wrappers

A survey of official MCP servers revealed an uncomfortable finding: nearly 90% of them are simply thin wrappers around REST APIs. In other words, most developers are only scratching the surface of what the MCP protocol can do, while the parts that truly empower AI Agents are being largely overlooked.

This piece, based on content from the YouTube channel Technomi HQ, systematically breaks down what an AI Agent is actually made of, what role each component plays, and spotlights an easy-to-miss new feature — Skills over MCP. Understanding this architecture is the critical step from "getting it to run" to "using it well."

Brain, Body, Hands, and Experience: The Four Core Components of an Agent

To understand an Agent, picture it as a diagram. At the center is the LLM — the brain. It reads, reasons, and decides what to do next. But a brain alone can only produce text; it can't click a button, run code, or open a file.

So we give it hands — that's MCP (Model Context Protocol), a standardized way to connect tools and data. We give it experience — that's Skills, pre-packaged instructions on how to do something well. And we give it a body to hold everything together — that's the harness, the runtime framework.

The harness is the software surrounding the model — something like Claude Code, or an Agent application you build yourself. It runs the core loop: Think, Act, Observe — repeating until the task is done. When the model requests a tool call, the harness actually executes it and feeds the result back to the model. It also manages memory and sets up guardrails — for example, asking for your approval before executing any risky operation.

MCP's Three Primitives: Who Holds Control Is the Key

Let's zoom in on the "hands" component. When using MCP, your application runs a client that talks to MCP servers — which could be GitHub, a database, or an internal company API. Each server can expose three things: Tools, Resources, and Prompts.

The difference between them comes down to who holds control.

Tools: The Model Decides When to Call Them

Tools are functions the model decides to invoke in order to execute actions or query information. If you ask an Agent to file a bug, it will call create issue on its own. Tools can change the state of the real world, which is exactly why they should come with guardrails — like asking you before running.

Resources: Context Controlled by the Application

Resources are context, and the application is in control. A file, a database schema, a design document — each has its own address (like a URL). They're context to be read, not actions to be executed, so the application can precisely attach only what's needed at a given moment.

Prompts: Templates Initiated by the User

Prompts are templates the user selects, typically surfaced as slash commands. Type /review PR, and you get a pre-built, battle-tested prompt with your pull request details automatically filled in.

Here's a common mistake: many servers turn everything into a Tool — fetching a schema is a tool, reading a doc is a tool, every workflow spawns more tools. The model ends up choosing from dozens of tools, and every tool description burns tokens.

So just ask yourself one question: Who should own the control? If the model decides when to use it, make it a Tool. If the application or user attaches it as context, make it a Resource. If a person initiates the workflow, make it a Prompts.

---

MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic in late 2024. It provides a unified standard for AI models to connect with external tools and data — analogous to USB-C in the hardware world. Before MCP, every AI application had to build custom integrations for each data source or tool, making maintenance extremely costly. MCP defines a standardized client-server communication protocol, allowing any MCP-compatible application to reuse the same pool of servers. Servers can run locally (communicating via stdio) or be deployed remotely (via HTTP+SSE). This architecture decouples "model capabilities" from "tool ecosystems" — in theory, a single MCP server can be called by Claude, GPT, or any other Agent framework that supports the protocol.

---

Skills: Packaging "How-To Experience" with Progressive Disclosure

Now for the "experience" component. A Skill is essentially a folder containing a skill.md file that records steps, tips, and even scripts for handling a particular type of task.

The clever part is progressive disclosure. An Agent normally only sees a one-line description of each Skill. Only when a task genuinely requires it does the full instruction set get loaded — and deeper supporting files are only loaded when truly needed. This means you can have a hundred Skills installed, with only their brief descriptions occupying context at any given time.

---

Progressive Disclosure is a principle originating in UI design: present information in layers on demand, so users only access deeper details when they need them, avoiding cognitive overload from too much information at once. In the context of LLMs, this principle maps directly to the physical constraints of the context window — the number of tokens a model can process per inference is finite, and anything placed in context has a cost. The progressive disclosure design in Skills is built on exactly this: compressing the skill catalog to a one-liner per skill makes the marginal cost of installing many Skills near zero; only when the model determines a task is relevant to a particular Skill does it trigger loading the full instructions. This echoes the on-demand retrieval philosophy of RAG (Retrieval-Augmented Generation), with the key difference that Skills operate at the granularity of "a complete set of operational guidelines" rather than fragmented document chunks.

---

Skills over MCP: Delivering the "Manual" Alongside the Product

There has long been a gap here. MCP servers deliver tools but not instructions — an Agent can see create issue but has no idea how your team likes issues written. And Skills used to live only in local folders, copied by hand and gradually going stale.

Skills over MCP is designed to close this gap. It corresponds to proposal SCP-2640, finalized in September 2026. Now, a server can deliver its Skills over the same connection it uses to deliver tools.

Interestingly, Skills is not a brand-new primitive — it rides on top of Resources. Every file inside a Skill is a Resource, with a URI starting with skill://. Your application calls skills/list and shows the model only names and descriptions; the model only loads a full Skill when the task matches, and your application can require you to approve it first. This way, the server delivers the manual alongside the product — and keeps it updated whenever the server updates.

As for current adoption: support is just beginning. At the time of recording, MCP Inspector and FastAgent have early support, and OpenAI's plugins can import a server's skills as a snapshot. Most mainstream Agent applications have yet to follow. That's precisely why now is a good time to get ahead of it.

---

SCP (Skills over Context Protocol), proposal number 2640, is an extension specification for the MCP protocol finalized through community discussion on the timeline described above. The design choice to "ride on top of Resources" is deliberate: Resources already come with URI-based addressing, on-demand loading, and application-layer access control infrastructure. By reusing this machinery, Skills avoids introducing new transport-layer complexity into the protocol, while allowing existing MCP clients to gain support with only incremental implementation of a handful of interfaces like skills/list. The skill:// URI scheme distinguishes Skills from ordinary file resources at the namespace level, making it easy for clients to identify and handle them differently — for example, listing available skills separately in the UI rather than mixing them into the general resource list.

---

The Complete Picture: All Three Primitives Matter

Putting it all together: the LLM is the brain, the harness is the body, MCP gives it hands — Tools called by the model, Resources providing context, Prompts initiated by you — and Skills provide the experience of getting things done, now deliverable by servers as Resources.

The core takeaway is straightforward: stop stuffing everything into Tools. Build servers that use all three primitives well, and pay special attention to Resources — the primitive most servers skip over, and the very foundation on which Skills over MCP is built. Do that, and your Agent will be genuinely ready for what comes next.