I've been building AI agents for a while now, and if there's one thing I've learned, it's that the tooling landscape changes *fast*. Just when you think you've got it figured out, someone comes along with a new approach that makes you rethink everything. Lately, I've been seeing a lot of discussion about two different ways to extend AI capabilities: **[Skills](https://developers.openai.com/codex/skills/)** and **[Model Context Protocol (MCP) Tools](https://modelcontextprotocol.io/docs/getting-started/intro)**. At first glance, they seem to solve the same problem, but dig a little deeper and you'll find they're actually coming at it from completely different angles. I've spent some time working with both, and I thought it'd be useful to share what I've learned. ## So, What Are We Even Talking About? ### MCP Tools: The "What Can You Do?" Approach Think of **[MCP Tools](https://modelcontextprotocol.io/docs/getting-started/intro)** as the ingredients in your kitchen. Each one does one thing really well. Need to call an API? There's a tool for that. Want to search a database? Got a tool. Read a file? Yep, tool. The key question MCP Tools answer is: *"What can the AI agent do?"* They're built around a few core principles: - **Stateless**: Each tool call stands on its own—no memory, no baggage - **Discoverable**: Tools register themselves through a protocol, so the agent can find them - **Composable**: Mix and match tools to build more complex operations - **Standardized**: Everyone follows the same interface, which makes things predictable It's like having a well-organized toolbox where every tool has a specific purpose and you know exactly where to find it. ### Skills: The "How Should You Do It?" Approach **[Skills](https://developers.openai.com/codex/skills/)**, on the other hand, are more like recipe cards. They don't just tell you what ingredients you have—they tell you *how* to use them together to make something meaningful. The question Skills answer is: *"How should the AI agent solve this problem?"* Skills are: - **Goal-oriented**: They're designed to accomplish something specific, not just do a thing - **Contextual**: They include guidance on when and how to use tools, not just what tools exist - **Token-efficient**: They load just enough info upfront, then fetch the details when you actually need them - **Customizable**: Easy to tweak and adapt without breaking everything If MCP Tools are the ingredients, Skills are the recipes that tell you how to cook with them. ## How They Actually Work ### MCP Tools: The Centralized Approach [MCP Tools](https://modelcontextprotocol.io/docs/getting-started/intro) work like a traditional client-server setup. You've got your AI agent (the client) talking to an MCP server (the host) through a standardized protocol. It's clean, predictable, and feels familiar if you've worked with APIs before. ```mermaid graph TB subgraph ClientSide["Client Side"] A["AI Agent"] end subgraph ServerSide["Server Side"] B["MCP Server"] D["Tool Registry
Execution Engine"] end A <-->|"MCP Protocol"| B A -->|"Tool Calls"| C["JSON-RPC"] B --> D C --> D style A fill:#6366f1,stroke:#4f46e5,stroke-width:3px,color:#fff,stroke-dasharray: 0 style B fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff style C fill:#8b5cf6,stroke:#7c3aed,stroke-width:3px,color:#fff style D fill:#10b981,stroke:#059669,stroke-width:3px,color:#fff style ClientSide fill:#eef2ff,stroke:#c7d2fe,stroke-width:2px,stroke-dasharray: 5 5 style ServerSide fill:#fef3c7,stroke:#fde68a,stroke-width:2px,stroke-dasharray: 5 5 ``` Here's what makes it tick: 1. **Tool Registry**: Think of this as a catalog. When the server starts up, it registers all its tools with full schemas. The agent can browse this catalog to see what's available. 2. **Protocol Layer**: Everything happens over [JSON-RPC](https://www.jsonrpc.org/). It's like REST, but specifically designed for tool discovery and invocation. 3. **Execution Engine**: When you call a tool, this handles the actual work—validating parameters, running the function, returning results. 4. **Context Management**: If you need to maintain state across calls, the server handles that. You can learn more about the [MCP architecture](https://modelcontextprotocol.io/docs/learn/architecture) in their docs. When you define a tool, it looks something like this: ```json { "name": "search_database", "description": "Search the database for records matching a query", "inputSchema": { "type": "object", "properties": { "query": {"type": "string"}, "limit": {"type": "number"} } } } ``` ### Skills: The Lazy Loading Approach [Skills](https://developers.openai.com/codex/skills/) take a different approach. Instead of loading everything upfront, they use what I like to call "lazy loading" (though the technical term is "deferred loading"). The idea is simple: don't load what you don't need yet. ```mermaid graph TD A["AI Agent"] -->|"1. Load Metadata
(minimal tokens)"| B["Skill Index
Lightweight"] B -->|"2. On-demand
Fetch Instructions"| C["Skill Store
Full Details"] C -->|"3. Execute
Orchestration"| D["Tools
bash • APIs • etc."] style A fill:#6366f1,stroke:#4f46e5,stroke-width:3px,color:#fff style B fill:#10b981,stroke:#059669,stroke-width:3px,color:#fff style C fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff style D fill:#8b5cf6,stroke:#7c3aed,stroke-width:3px,color:#fff ``` The flow goes like this: 1. **Skill Index**: First, you load a lightweight catalog. Just enough info to know what skills exist and what they're for. Think of it like a table of contents. 2. **Skill Store**: When you actually need a skill, *then* you fetch the full instructions. This is where the real magic happens—the detailed steps, the guidance, the orchestration logic. 3. **Orchestration Engine**: This interprets the skill instructions and coordinates the actual tool usage. It's like having a conductor for your tools. 4. **Tool Abstraction**: Skills work with whatever tools you already have. They don't need special tool implementations—they just need to know how to use what's available. A skill definition looks like this: ```yaml # Skill Metadata (loaded initially) name: "data_analysis_pipeline" description: "Analyze data using multiple tools" token_cost: "low" # Full Instructions (loaded on-demand) steps: - tool: "read_file" guidance: "Read the CSV file and validate structure" - tool: "process_data" guidance: "Apply transformations based on data type" - tool: "generate_report" guidance: "Create visualization and summary" ``` ## The Nitty-Gritty Details ### How They Communicate **[MCP Tools](https://modelcontextprotocol.io/docs/getting-started/intro)** use a straightforward request-response pattern. You ask for the list of tools, you get the list. You call a tool, you get a result. It's synchronous, predictable, and feels a lot like calling a REST API. ```typescript // Tool Discovery interface ListToolsRequest { method: "tools/list" } interface ListToolsResponse { tools: Array<{ name: string description: string inputSchema: JSONSchema }> } // Tool Invocation interface CallToolRequest { method: "tools/call" params: { name: string arguments: Record } } ``` **[Skills](https://developers.openai.com/codex/skills/)** work differently. They use a two-phase loading approach: ```typescript // Phase 1: Load Index (minimal tokens) interface SkillIndex { skills: Array<{ id: string name: string brief: string // ~50 tokens category: string }> } // Phase 2: Load Full Instructions (on-demand) interface SkillDefinition { id: string name: string description: string // Full details steps: Array constraints: Constraints examples: Array } ``` ### Finding and Using Tools **MCP Tools** are pretty upfront about everything. When the server starts, it declares all its tools with full schemas. ```python # MCP Server Registration class MCPServer: def __init__(self): self.tools = { "search_db": DatabaseSearchTool(), "read_file": FileReadTool(), } def list_tools(self): return [tool.to_schema() for tool in self.tools.values()] ``` The agent does a handshake with the server and gets the full list. Versioning is handled at the server level, but this means you're loading all that schema data upfront. **Skills** work differently. You browse the catalog first (the index), and only when you need a skill do you fetch the full instructions. ```python # Skill Registry class SkillRegistry: def __init__(self): self.index = SkillIndex() # Lightweight self.store = SkillStore() # Full definitions def get_available_skills(self): return self.index.list() # Returns brief descriptions def get_skill(self, skill_id): return self.store.load(skill_id) # Full instructions ``` Versioning can be per-skill, which is nice for iteration, but it can get messy if you're not careful. ### Keeping Track of Context **MCP Tools** handle context explicitly. Every tool call can include context, and the server maintains session state if needed. It's all very structured: ```typescript interface ToolContext { sessionId: string previousResults: Array metadata: Record } ``` The protocol handles serialization, but you need to think about what context to pass and when. **Skills** bake context management right into the instructions. The skill tells the agent what context it needs and how to use it: ```yaml skill: data_analysis context_requirements: - input_file: "path to data file" - analysis_type: "statistical|visual|both" context_usage: - step: 1 use: "input_file" guidance: "Validate file exists and is readable" ``` This leverages the model's existing context management, but it's less explicit, which can make debugging trickier. ## When Should You Use Which? ### MCP Tools: The Right Tool for the Job I'd reach for **[MCP Tools](https://modelcontextprotocol.io/docs/getting-started/intro)** when: - **You're integrating with APIs**: External services with well-defined interfaces are perfect for MCP. The protocol handles the communication, and you get type safety through schemas. - **You need database operations**: Standard CRUD stuff works great. The schemas make it clear what you're working with, and the stateless nature keeps things simple. - **Your team needs centralized management**: If you've got multiple teams or projects, having tools in one place makes updates and versioning much easier. - **Versioning matters**: When you need strict backward compatibility and controlled rollouts, MCP's server-level versioning is a lifesaver. - **Operations are simple and stateless**: If you're just calling functions without complex orchestration, MCP is probably overkill. ### Skills: When You Need More Guidance **[Skills](https://developers.openai.com/codex/skills/)** shine when: - **You've got complex workflows**: Multi-step processes that need decision-making and conditional logic? Skills are built for this. - **Context is too large**: When you have many tools/skills, MCP Tools load all schemas upfront, which can bloat your context window. Skills only load what you actually use, making them ideal when context size is a constraint. - **Token costs are a concern**: If you're watching your token budget (and who isn't?), Skills' lazy loading can save you real money. - **You need domain-specific behaviors**: Sometimes you want the agent to solve problems in a particular way, not just have access to tools. Skills give you that guidance. - **You're prototyping quickly**: Skills are easier to iterate on. Change the instructions, reload, test. No need to update protocol definitions. - **You're orchestrating multiple tools**: When you need to coordinate several tools with conditional logic, Skills make it much more manageable. At the end of the day, the choice really comes down to: - **Team structure**: Centralized teams work better with MCP; distributed teams might prefer Skills - **Token constraints**: If every token counts, Skills win. If you've got budget, MCP's predictability is nice - **Complexity**: Simple operations? MCP. Complex workflows? Skills. - **Standardization**: Need everything to work the same way? MCP. Need flexibility? Skills. ## The Real Trade-offs ### Token Efficiency: Where It Really Matters Let's talk about the elephant in the room: **token costs**. This is where Skills really shine, but it's not as simple as "Skills are always cheaper." **[MCP Tools](https://modelcontextprotocol.io/docs/getting-started/intro)** have a high upfront cost. Every tool schema gets loaded into the system message, which means: ``` Token Cost = (N × Schema_Size) + (Calls × Param_Size) ``` If you've got 50 tools, that's 50 schemas loaded upfront. Each schema might be 200-500 tokens. That adds up fast. But once they're loaded, each tool call is cheap—just the parameters. **[Skills](https://developers.openai.com/codex/skills/)** flip this around: ``` Token Cost = (Index_Size) + (Active_Skills × Instruction_Size) ``` The index is tiny—maybe 50-100 tokens per skill. You only load the full instructions when you actually use a skill. So if you have 50 skills but only use 3 in a session, you're only paying for those 3. In practice, I've seen Skills achieve **20-40% token reduction** in typical workflows. But MCP Tools give you better predictability—you know exactly what you're paying for upfront, which makes budgeting easier. ### Scaling: The Good and the Bad **[MCP Tools](https://modelcontextprotocol.io/docs/getting-started/intro)** scale horizontally really well. The stateless design means you can throw more servers at it and load balance. But tool proliferation is a real problem. Once you get past a few dozen tools, managing them becomes a pain. The centralized versioning helps, but it also means updates are all-or-nothing. **[Skills](https://developers.openai.com/codex/skills/)** are a bit trickier to scale horizontally because you need to keep the skill store in sync. But skill proliferation is more manageable—the lightweight index means you can have hundreds of skills without killing your token budget. Version management can be a mess though, especially if different teams are maintaining different skills. ### Flexibility vs. Standardization **[MCP Tools](https://modelcontextprotocol.io/docs/getting-started/intro)** are rigid. They have to conform to the protocol, which means you get strong standardization. Every MCP tool works the same way, which is great for interoperability. But if you need something the protocol doesn't support, you're stuck until the protocol evolves. **[Skills](https://developers.openai.com/codex/skills/)** are flexible. You can define custom orchestration patterns, embed domain-specific logic, do whatever you want. But that flexibility comes at a cost—each skill can be structured differently, which makes it harder to build tooling around them. ### When Things Go Wrong **[MCP Tools](https://modelcontextprotocol.io/docs/getting-started/intro)** have explicit error handling built into the protocol: ```typescript // Explicit error handling in protocol interface ToolError { code: string message: string data?: any } // Structured error responses try { result = await callTool(tool, params) } catch (error: ToolError) { // Protocol-defined error handling handleError(error.code, error.message) } ``` **[Skills](https://developers.openai.com/codex/skills/)** handle errors in the skill logic itself: ```yaml # Error handling embedded in skill logic skill: data_processing error_handling: - on_failure: "retry_with_backoff" - on_timeout: "fallback_to_simpler_method" - on_validation_error: "request_clarification" ``` This is more flexible—you can define custom error handling per skill—but it's also less standardized. When something breaks, you may need to dig into the skill definition to understand what happened. ### Getting Started **[MCP Tools](https://modelcontextprotocol.io/docs/develop/build-server)** require more setup. You need to implement an MCP server, define your tools, set up the protocol layer. But once it's done, integration is standardized and maintenance is centralized. **[Skills](https://developers.openai.com/codex/skills/)** are easier to get started with. You can work with existing tools (bash, APIs, whatever), and you just write instructions. But maintenance can be a pain if skills are scattered across different places or teams. ## What I've Learned in Practice Here's the thing: **Skills often outperform MCP** in real-world scenarios, even though they seem less sophisticated on paper. Why? Because they leverage what the model already knows how to do. Skills work with the model's existing reinforcement learning for tool use. You're not fighting against the model—you're guiding it. They don't need special API-side engineering or complex state management. The model's natural language understanding does a lot of the heavy lifting. MCP's protocol is solid, but the implementation overhead is real. You need additional LLM API engineering, more complex state management, and careful prompt engineering to make it work well. ## Where This Is All Going The AI agent ecosystem is still evolving. We've gone from function calling → plugins → GPTs → Skills/MCPs, and I don't think we're done yet. My bet? We'll see hybrid approaches that combine the discoverability of [MCP](https://modelcontextprotocol.io/docs/getting-started/intro) with the efficiency of [Skills](https://developers.openai.com/codex/skills/). Maybe something like "MCP Skills"—skills defined and distributed via the MCP protocol, or unified tooling frameworks that abstract both paradigms. The point is, understanding these differences helps you pick the right tool for the job. When you're deciding between Skills and MCP Tools, think about what problem you're actually trying to solve. The answer will probably be clearer than you think.

Posts tagged: Architecture

Skills vs MCP Tools: A Technical Deep Dive