Beyond "MCP vs Skills": Composing for Scalable Agent Architecture

The debate framing MCP and Skills as competitors misses the point. As Kurtis Van Gent argued recently, they solve different problems: MCP tackles the N×M integration problem, Skills address context saturation. True. But the real opportunity is composing them into a unified architecture.

At Skilder, we've built exactly this: Skills that compose MCP tools into coherent capabilities, organized by business context, and exposed through a single MCP server with progressive disclosure built into the protocol.

Two Problems, One Architecture

The N×M Integration Problem. You have N agents (Claude Code, Cursor, your custom SDK) and M data sources (GitHub, Slack, Postgres). Without standardization, every agent-tool pair needs a custom connector. MCP collapses this to N+M with a universal protocol.

The Context Saturation Problem. Your agent has access to 80 tools. Each tool schema consumes tokens. Load them all upfront and you burn 30,000 tokens before the user says hello. Worse, models perform worse when forced to reason over irrelevant options. Google's ADK team calls this "signal degradation."

Skills solve this through progressive disclosure. The agent sees lightweight metadata first. Full instructions and tools load on demand.

Where Each Approach Falls Short Alone

MCP's context tax. Every connected MCP server dumps its tool definitions into your context window. Connect to GitHub, Slack, Postgres, and a CI/CD server: hundreds of tool definitions loaded before any work begins. Anthropic's own research found that loading definitions on demand dropped token usage from 150,000 to 2,000 in one case.

Skills' isolation problem. A Skill teaches an agent how to deploy code. But reaching the actual deployment system requires custom scripts (environment-dependent, fragile) or falling back to MCP (losing context efficiency). Write a Skill on macOS, share it with a colleague on Windows, and watch it break.

Multi-server sprawl. Teams end up with five MCP servers connected, a dozen Skills scattered, and no clear relationship between them. The agent must figure out which Skill applies to which server, which tools belong to which workflow. Cognitive load compounds.

The Composition Thesis

The fix: Skills become the composition layer over MCP.

A Skill groups related MCP tools into a coherent unit with instructions on how to use them together. A "deploy-to-staging" Skill links the specific tools it needs and guides the agent through the workflow. The agent sees "deploy-to-staging" as a single concept. It doesn't need to know that GitHub and CircleCI exist as separate systems.

MCP handles connectivity. The Skill handles choreography.

At Skilder, we expose this through a single MCP server. Your agent connects to one endpoint instead of five. Progressive disclosure is built into the protocol itself: the agent starts with a lightweight catalog of available skills and loads full tool schemas only when needed.

The result: instead of paying 20,000 tokens upfront for 10 servers worth of tools, you pay around 2,900 tokens with equivalent capabilities loaded on demand.

Business Context, Not Tool Catalogs

Skills alone become a flat list. In enterprise environments, dozens of skills spanning multiple teams create the same cognitive overload, one level up.

We organize skills into business context groups: named collections by role, domain, or workflow. A "DevOps" group bundles deployment, monitoring, and rollback. A "Customer Support" group bundles lookup, billing, and escalation.

The agent navigates business concepts rather than technical categories. This bridges how engineers think (tools, APIs) and how organizations think (roles, processes, domains).

From Transparency to Delegation

Not every workflow needs the same level of agent involvement. Simple tool groupings need full agent control. Complex, proven workflows benefit from delegation.

Skilder supports a spectrum: from the agent orchestrating individual tools with full transparency, to sub-agent execution where a self-contained process handles the complexity. Organizations start transparent and graduate high-confidence workflows to delegation as they prove reliability.

Why This Scales

Context efficiency. Agents pay for what they use. Not for what they might use.

Reduced cognitive load. Pre-composed capabilities with clear instructions. Tool selection errors drop when agents work with coherent workflows instead of raw tool schemas.

Single connection point. One MCP server to connect, configure, and secure. No credential sprawl.

Enterprise governance. Every skill invocation and tool call is tracked. Full audit trails feed into optimization: unused skills, timeout patterns, failure hotspots. Skills improve from usage data over time.

Dependency awareness. When an underlying MCP server changes, affected Skills are identified automatically. Updates propagate through the system instead of requiring manual audits.

Trade-offs

Authoring complexity. Creating composed Skills requires understanding both the workflow and the underlying tools. Our approach: AI-assisted skill generation. Describe a workflow in natural language. Skilder bootstraps the skill structure.

Debugging depth. Abstraction layers add debugging complexity. Mitigation: structured telemetry at each layer with trace context flowing through the entire stack.

Discovery overhead. Progressive disclosure adds a round-trip before the agent uses tools. Pre-loaded skills bypass this for known workflows. For most enterprise use cases, context savings far outweigh the cost.

Getting Started

Identify high-value workflows. Find three to five workflows where your team repeatedly coordinates multiple tools. Those are your first composed Skills.

Start simple, graduate to delegation. Begin with skills that group related tools with good instructions. Promote stable workflows to higher automation as they prove reliability.

Organize by business context early. Structure skills by role or domain from the start. Imposing structure later is harder.

Expose through a single gateway. Connect your agents through one MCP server. Adding skills doesn't increase baseline context cost.

Looking Forward

The SEP-2076 proposal suggests adding Agent Skills directly to the MCP spec. Native support for composed Skills with tool dependencies and progressive disclosure would make this pattern standard rather than custom-built.

Beyond that, federated skill graphs: organizations publishing skill collections that others consume and extend. Community-maintained DevOps skill graphs, extended with company-specific workflows. Composition at the ecosystem level.

The MCP vs Skills debate is a false dichotomy. MCP solves connectivity. Skills solve context efficiency. The model we've built at Skilder composes them: Skills over MCP, organized by business context, exposed through a single server with protocol-level progressive disclosure.

The future of agent architecture is Skills over MCP, composed into a knowledge graph that scales with your organization.