MCP Skills vs MCP Tools: The Right Way to Configure Your Server

> Skills and MCP tools are not the same thing — and confusing them costs you. Learn the real difference, the real downsides, and how to combine both for a better agentic workflow. # MCP Skills vs MCP Tools: What's the Difference and How to Combine Them Everyone is talking about MCP. Everyone is talking about skills. Most people are using them interchangeably — and that's exactly the problem. They are not the same thing. They don't solve the same problem. And if you reach for the wrong one, you will feel it: hallucinations, context blowups, agents that drift off-task, and workflows that fall apart under pressure. Let's fix that. --- ## The Core Mental Model Think of it like a kitchen. **MCP tools** are your appliances and ingredients — the oven, the fridge, the fresh vegetables. Raw capability. Without them, nothing gets cooked. **Skills** are your recipes — the step-by-step instructions that tell a skilled chef exactly how to turn those ingredients into something good. Without them, you have power with no direction. An agent with only MCP tools can *do* things but doesn't necessarily know *how* to do them well. An agent with only skills has great instructions but no way to act on them. You need both. --- ## What Is an MCP Tool? The **Model Context Protocol** is an open standard — now under the Linux Foundation's Agentic AI Foundation — that gives AI agents a standardized way to connect to external systems: databases, APIs, file systems, GitHub, Slack, your Angular CLI. When you connect an MCP server to your client—whether that's Claude Code, the Gemini CLI, or a custom agent—it gets access to a set of typed, deterministic tools. Each tool has a clear input/output schema. When the agent calls it, it executes — no interpretation, no hallucination risk at the execution level. It's a structured API call, not a suggestion. ```json { "mcpServers": { "angular-cli": { "command": "npx", "args": ["-y", "@angular/cli", "mcp"] } } } ``` MCP is how the agent *reaches outside itself*. It's the nervous system. **Use MCP when you need the agent to:** - Read or write to a real system (database, filesystem, API) - Execute actions with clear, auditable inputs and outputs - Connect to tools you don't own or control - Integrate multiple services through a consistent interface --- ## What Is a Skill? A **Skill** is a folder containing a Markdown file (with YAML frontmatter) plus optional scripts and resources. It's not executable by itself — it's a playbook. When a user's request matches a Skill's relevance criteria, the agent loads those instructions dynamically and follows them. Think of it as giving the agent expert-level procedural memory on demand. ```markdown --- name: angular-component-review description: Review Angular components for Signal compliance and standalone architecture --- # Angular Component Review When reviewing an Angular component: 1. Check that all state uses `signal()` or `computed()` — never direct property mutation 2. Verify the component is `standalone: true` 3. Confirm no `NgModule` dependencies remain 4. Validate that `@if` / `@for` is used instead of `*ngIf` / `*ngFor` ``` The agent loads this only when it's relevant. When it's not — it costs you nothing. **Use a skill when you need the agent to:** - Follow a consistent process or checklist - Apply domain-specific expertise (your coding standards, review criteria) - Encode knowledge that doesn't change often - Reuse the same workflow across different conversations --- ## The Real Downsides This is where most guides stop. They shouldn't. ### MCP: The Token Tax Every MCP tool you connect injects its full schema into the context window *before the agent processes a single message*. Each tool costs 550–1,400 tokens. Connect GitHub, Slack, and Sentry, and you're looking at **55,000 tokens burned upfront** — over a quarter of Claude's 200k limit before any real work begins. And if you are using Gemini with its 1M+ token window, you might think you can just ignore this. Don't. Even if you have the space to spare, dumping 55,000 tokens of raw JSON schema into every single turn of a conversation drives up your latency, increases API costs, and dilutes the model's focus. One team reported connecting three MCP servers and consuming **143,000 of 200,000 tokens** on tool definitions alone. The agent had 57,000 tokens left for the actual conversation. The good news: modern clients like Claude Code and the Gemini CLI have adopted progressive discovery for MCP—loading only tool names and descriptions upfront (~20–50 tokens each) and fetching full schemas only when the agent actually needs a tool. Token overhead declined by ~85%. But this feature only works if your MCP setup is configured to use it, and most setups still aren't. ### Skills: The Staleness Problem Skills are Markdown files. They don't update themselves. If your Angular patterns evolve — say you migrate from `setInput()` to the new declarative API in Angular 20 — your Skill still teaches the old way until someone updates it manually. The more skills you create, the more maintenance burden you carry. And if a skill is subtly wrong, the agent will follow it confidently — no error, just quietly incorrect output. ### Both: The Selection Problem Give an agent too many tools or too many skills, and it starts making the wrong choices — calling the wrong tool, triggering the wrong playbook, or combining them in ways that produce contradictory instructions. Experts recommend staying under **10–15 active MCP tools** at any time. --- ## How to Combine Them The most powerful pattern is using them as layers: **Layer 1 — MCP provides access.** Connect only what the agent genuinely needs for the current task. Angular CLI, a database, and a file system. Keep it lean. **Layer 2 — Skills provide expertise.** Create a skill that tells the agent *how* to use those tools in your specific context. Not just "run the Angular CLI" — but "when migrating a component, run `ng generate` with these flags, then validate against these patterns." **Layer 3 — Skills can orchestrate MCP.** A Skill can define a multi-step workflow that calls multiple MCP tools in sequence. Example: a "Deploy & Notify" Skill that uses GitHub MCP to push, a CI/CD MCP to trigger a build, and a Slack MCP to notify the team — all under one coherent playbook. ```markdown --- name: angular-migration-workflow description: Full workflow for migrating an Angular component to v21 patterns --- # Migration Workflow 1. Use the Angular CLI MCP to check the current component version 2. Run `ng update` for the affected package 3. Apply the zoneless migration schematic 4. Review the output against the angular-component-review Skill 5. Run tests and report results ``` --- ## The Practical Decision Guide | Situation | Use | |-----------|-----| | Need to query a real database | MCP | | Need to follow a code review checklist | Skill | | Need to push to GitHub | MCP | | Need to apply your team's commit message format | Skill | | Need to read a live API | MCP | | Need to teach the agent your Angular architecture rules | Skill | | Need both access and consistent process | Both | --- ## Improving Your Workflow A few patterns that actually work in production: **1. One MCP server per domain.** Don't load everything at once. Create separate configs for "Angular development," "deployment," and "communication" — and activate only the one you need for a given session. **2. Version your Skills like code.** Put them in your repository. Review them when you update your stack. A Skill for Angular 19 patterns will actively hurt you on Angular 21. **3. Use Skills to write MCP guardrails.** Instead of relying on the agent to figure out when to call a destructive MCP action, write a Skill that explicitly says: *"Before running any `ng update`, always create a git branch first."* **4. Measure your context budget.** Before your agent does any real work, know how many tokens your MCP setup consumes. If you're over 30% of your context window is on tool definitions, you have a configuration problem. **5. Let the agent maintain simple Skills.** For fast-moving areas — like keeping track of your team's current Angular version conventions — let the agent update the Skill file itself when you tell it to. It's faster than doing it manually and keeps the Skill honest. --- ## The Bottom Line MCP gives agents the ability to act. Skills teach them how to act well. The debate of "MCP vs Skills" is a false one. The real question is: *do you need access, expertise, or both?* In most real Angular workflows, you need both. An agent that can run your CLI but doesn't know your architecture is just a faster way to make the same mistakes. An agent that knows your patterns but can't touch your actual project is just an expensive search engine. Used together, with clear boundaries and lean configuration, they're the foundation of agentic development that actually works. --- *Previously I wrote about [Angular 21 MCP and the end of manual migrations](https://www.yeou.dev/articles/angular-21-mcp-migrations) — a good starting point if you're new to the MCP server setup for Angular.*