Skills, MCP Servers, and the Missing Layer in AI Agents
If you're building AI agents, you've probably used skills and MCP servers. Skills shape how the agent thinks. MCP servers give it tools to call. Together, they cover a lot of ground.
But there's a category of problems they can't solve — not because they're poorly designed, but because they operate at the wrong layer.
What skills do well
A skill is a markdown file with prompt instructions. Load a skill, and the agent gains knowledge and behavioral guidelines. Think of it as handing someone a reference manual before they start work.
# Code Review Skill
When reviewing code, always check for:
- SQL injection vulnerabilities
- Unvalidated user input
- Missing error handling
Skills are excellent for shaping agent behavior: coding standards, review checklists, domain knowledge, workflow guidelines. They're easy to write, easy to share, and they work across agents without any infrastructure.
But skills operate entirely in the context window. There's no code running, no external connections, no state. The agent reads the instructions and tries to follow them — there's no enforcement. A skill that says "never output API keys" relies on the LLM to comply. If the model hallucinates or ignores the instruction, nothing catches it.
What MCP servers do well
The Model Context Protocol gives agents access to external tools and data. An MCP server runs locally and exposes tools the agent can invoke — database queries, file operations, API calls.
{
"name": "query_database",
"description": "Run a SQL query against the project database",
"parameters": {
"query": { "type": "string" }
}
}
MCP servers are powerful for giving agents real capabilities. The agent decides when to use a tool, calls it, and gets back a result. LlamaIndex's comparison puts it well: skills tell the agent how to approach work, MCP servers give it the tools to execute.
But MCP servers are reactive — the agent calls them. They can't intercept a request before it reaches the LLM. They can't transform a response before the user sees it. They can't enforce a policy that the agent doesn't voluntarily follow. And as MarkTechPost notes, MCP servers can't teach the agent how to use them effectively — they expose a tool, but can't guide when or how to call it.
The missing layer: agent middleware
There's a category of problems that neither skills nor MCP can solve:
- Enforced guardrails. Not "please don't output credentials" (a skill) — but actually scanning every LLM response and redacting secrets before the user sees them, regardless of what the model does.
- Conditional behavior by context. A plugin that activates only for certain channels (web chat gets a formal tone, Telegram gets a casual one) or certain users (admin gets full access, free tier gets limited tools).
- Request transformation. Injecting customer context from a CRM into every LLM call automatically, not relying on the agent to remember to look it up.
- Pipeline gating. Blocking a tool call based on the user's role, or routing to a different subagent based on conversation classification — decisions made outside the LLM, in deterministic code.
- Observability. Logging every LLM call, every tool use, every response to an audit system — not as a tool the agent might call, but as infrastructure that always runs.
These are middleware problems. They require code sitting in the pipeline, intercepting and processing requests and responses as they flow between the user and the LLM.
LangChain has middleware hooks (before_model, after_model, modify_model_request). Microsoft's Agent Framework has AgentMiddleware, FunctionMiddleware, and ChatMiddleware. The concept is proven — but it's always been code buried inside a framework, not something you configure and deploy independently.
What this looks like in practice
On agentplatform, middleware runs as plugins — hosted services that hook into the LLM call lifecycle. Here's a concrete example of what they enable that skills and MCP can't:
Every step in this flow is a plugin. The channel determines which context gets injected. The user's role determines which tools are available. The response gets scanned and logged regardless of what the LLM decided to do. None of this relies on the LLM following instructions — it's enforced by code in the pipeline.
A skill could suggest checking the user's role. An MCP server could provide a role-checking tool. But neither can prevent the LLM from ignoring the check and giving a free-tier user admin access anyway. Middleware can.
Where each layer belongs
| Skills | MCP Servers | Middleware (plugins) | |
|---|---|---|---|
| What it is | Prompt instructions | External tool server | Pipeline interceptor |
| Where it runs | In the context window | On the developer's machine | In the request/response pipeline |
| Control model | Advisory — LLM tries to follow | Reactive — LLM decides to call | Enforced — runs regardless of LLM |
| Can intercept requests | No | No | Yes |
| Can transform responses | No | No | Yes |
| Can gate by context | No (LLM may ignore) | No | Yes (channel, user, role, etc.) |
| State | None | Per-session | Server-side, persistent |
They're not competing layers — they're complementary. A well-built agent uses skills for behavioral guidance, MCP servers for interactive tools, and middleware for pipeline-level control and enforcement.
The gap we're filling
The middleware layer exists conceptually in LangChain and Microsoft's framework, but it's always been code you write inside a specific framework. It's never been something you configure declaratively, deploy to a hosted platform, and share across projects.
That's what we're building with agentplatform. Middleware as hosted plugins. Configured in HCL. Deployed in seconds. Each plugin hooks into the lifecycle — pre_call, post_response, tool_call, guard — and runs as a hosted service you never have to manage.
Join the early access list if you're building agents and want control over the full pipeline.
Read more: Why I'm Building agentplatform — the full story behind the platform.