Two separate Anthropic-ecosystem concepts get conflated constantly: Claude Skills and the Model Context Protocol. They’re not competing features and they’re not the same thing — they solve two different halves of “how does an AI agent do real work on my WordPress site.”

What Claude Skills Are
A Skill is a packaged, reusable set of instructions, and sometimes scripts, that Claude loads on demand for a specific kind of task — a repo-specific deployment checklist, a house style guide for content, a domain playbook for a recurring workflow. Instead of re-explaining the same process in every conversation, the Skill is written once and Claude reads it when the task matches. It’s how an agent scales expertise across many similar tasks without a human re-teaching it each time. Anthropic launched Agent Skills as an open standard in October 2025, and within months other major tooling ecosystems (OpenAI, Google, GitHub, and Cursor among them) had adopted the same format, which is part of why a Skill written once tends to travel well across different AI coding tools rather than being locked to one vendor.
What a Skill Actually Looks Like
Structurally, a Skill is just a folder with a markdown file at its core: a short frontmatter block (a name and a one-line description of when this Skill applies) followed by the actual instructions in plain markdown — the process, the rules, the examples. Claude reads the frontmatter first to decide relevance, then loads the full body only when the current task matches. A Skill folder can also bundle scripts or reference files the instructions point to, so it isn’t limited to prose alone. This is deliberately low-tech: no special runtime, no proprietary format, just structured markdown a team can write, version, and review the same way they’d review any other documentation.
Progressive Disclosure: Why Skills Don’t Bloat Context
The mechanism that makes it practical to have many Skills installed at once without paying a context-window penalty for all of them is called progressive disclosure, and it happens in stages. At startup, only each Skill’s frontmatter (the name and one-line description) loads into context — a few dozen tokens per Skill, not the full body. When a task actually matches a Skill and it triggers, Claude reads the full SKILL.md file from disk into context at that point, and if those instructions reference other files (a reference doc, a schema, a template), those get read in turn only as needed. If the Skill bundles an executable script, Claude runs it and receives just the output — the script’s own code never has to enter the context window at all. The practical result: a team can accumulate dozens of Skills covering different tasks and sites without every one of them eating into the working context on every single conversation, since only the tiny frontmatter for unused Skills sits there until one is actually triggered.
What MCP Is
The Model Context Protocol is the connection layer: it standardizes how Claude (or any compatible model) reaches external tools and data — your WordPress REST API, a database, a file system, a WordPress MCP server exposing the Abilities API. Where a Skill is knowledge and process, MCP is plumbing and access.

Also Read: How to Set Up a WordPress MCP Server, Step by Step — the MCP half of this picture, applied directly to WordPress.
Skills vs. Subagents: A Third Concept People Also Conflate
Alongside Skills and MCP, there’s a third piece worth distinguishing clearly: subagents. A Skill is procedural knowledge that runs inline, inside your current conversation — every step it takes is visible in the same thread, and its results land directly there. A subagent is architecturally different: it’s a separate Claude instance spun up with its own context window and tool access, working in isolation, that returns only a summary of what it did back to the main conversation. Put simply, a Skill changes how an agent works on a task; a subagent changes where that work actually happens. For a WordPress team, this distinction matters when deciding how to scale a workflow: a repeatable process (your ship-gate checklist, your exact category rules) is a Skill; a task that needs its own isolated context so it doesn’t clutter the main conversation (a long research pass, an independent audit) is better suited to a subagent, and the two can be combined — a subagent can itself load and follow a Skill while it works.
How They Combine in Practice
A realistic setup: a Skill defines your team’s exact SEO-writing process, ship-gate checklist, and product facts for a specific WordPress site, while an MCP connection to that same site gives Claude the actual read/write access to publish, update meta, or pull live data while following that Skill. Neither one substitutes for the other — a Skill with no MCP connection can plan and draft but not touch the live site; an MCP connection with no Skill can technically read/write but without the domain-specific process and standards a team actually wants followed.
Why This Matters for a WordPress Team Specifically
If your team is using Claude (via Claude Code, an IDE integration, or a similar setup) to help manage a WordPress site, the Skill layer is where your team’s actual standards live — brand voice, categories, shortcode conventions, ship-gate checks — while the MCP/Abilities layer is what lets those standards actually get executed against the live site instead of staying theoretical.
Also Read: Nexter Abilities Explained: The WordPress Abilities API Inside Nexter Blocks — the specific WordPress-side abilities a Claude MCP connection can call on a Nexter site.
A Practical Starting Point for a Team
- Write your first Skill around your single most-repeated task (a specific content format, a recurring audit, a publishing checklist) rather than trying to cover everything at once.
- Keep the Skill’s instructions specific and concrete — exact category IDs, exact shortcode syntax, exact required blocks — the same level of detail you’d give a new hire, not a vague style guide.
- Add the MCP connection only once the Skill itself is solid; a well-written Skill with no live access still saves real time on drafting and planning.
- Version the Skill file the same way you’d version any other team documentation, and update it when your process actually changes rather than letting it drift out of sync.
- Reach for a subagent, not a bigger Skill, when a task genuinely needs its own isolated context (a long independent research pass) rather than trying to cram everything into one conversation.
FAQ
Is a Claude Skill the same thing as an MCP server?
No. A Skill packages instructions and process; an MCP server (or connection) provides live access to tools and data. They’re complementary, not interchangeable.
Do I need to enable MCP for Skills to work at all?
No, a Skill can guide drafting, planning, and review-only tasks without any live site connection. MCP becomes necessary once the task requires actually reading or writing to your WordPress site.
Is this specific to Nexter, or does it apply to any WordPress site?
The Skills/MCP distinction is general to how Claude works, not Nexter-specific. Nexter’s own Abilities implementation is one concrete example of the MCP-connected side of this on a WordPress site.
Do I need to write code to create a Skill?
No, at its core a Skill is a markdown file with a small frontmatter block; writing one is closer to writing documentation than writing code, though a Skill folder can optionally bundle scripts if a task genuinely needs them.
What’s the difference between a Skill and a subagent?
A Skill runs inline in your current conversation, with every step visible in the same thread. A subagent is a separate Claude instance with its own isolated context that only returns a summary back. A Skill changes how work happens; a subagent changes where it happens, and the two can be used together.
Conclusion
Skills and MCP solve different halves of the same problem: one carries your team’s process and standards, the other carries the access to actually execute on them, and progressive disclosure is what makes stacking many Skills together practical without bloating every conversation’s context. A WordPress team getting real value from Claude needs both pieces working together, not just one — and knowing where subagents fit in keeps the whole picture from collapsing into one confused “AI feature.”
Suggested Reading
- How to Set Up a WordPress MCP Server, Step by Step
- Nexter Abilities Explained: The WordPress Abilities API Inside Nexter Blocks
- AI Agents and Your WordPress Site: What They Can Actually Do in 2026










