If you extend an AI coding assistant or an agent host this year, you will meet two very different packaging conventions. One is the MCP server: a separate process that speaks the Model Context Protocol and exposes tools and resources to whatever client supports it. The other - younger and looser - is the packaged skill: a folder of instructions, scripts, and reference material that the host loads to make the model better at a task. They sound interchangeable, and marketing copy treats them as interchangeable, but the engineering differences are concrete. This comparison lays out those differences as they actually work: transport, trust, and maintenance.
Transport and lifecycle: process versus folder
An MCP server is a real program with a real address. It starts, it has dependencies, it may bind a port or speak over stdio, and it holds state: the filesystem agent in this site's catalog, for example, is a Python process that receives tool calls and performs actions on disk with its own error handling. A skill is not a process at all. The host reads a manifest, loads instructions into context, may run its bundled scripts with the host's own execution tools, and disposes of it when the session ends. There is no socket and no process boundary; the boundary is literally the permission system of the host program.
That difference decides your failure modes. Servers fail classically: they crash, hang, or disagree with the transport - the classic deployment problems, with the classic fixes. Skills fail weirdly: the instructions go stale, the model misreads an ambiguous step, or a host update changes what tools are available and the playbook silently degrades. When something breaks, with the server you debug a program; with the skill you debug a document.
Trust and audit: where the boundary actually is
The trust story is the part people skip, and it should be the deciding factor. With an MCP server, the trust boundary is explicit and auditable: the process is a piece of running code you can lock down with OS permissions, container limits, and network policy. Whatever it is allowed to do, it does through its own runtime, and you can watch it. A team can deny it read access to a directory tree and be sure of the denial.
With a skill, the boundary is much blurrier. The skill's instructions travel into the model's context, and whatever those instructions tell the model to do happens - if it can - through the host's built-in tools under the permissions you granted the host. A well-written skill cannot exceed the host's permissions, but it also cannot be reliably fenced below them: you cannot tell the filesystem skill it may write to project directories but never to your shell history, because the fence is enforced by a product permission system you may not control. In our catalog the contrast is visible by design: the document-skills bundle and the markdown-conversion skill are textbook know-how packages, while the filesystem MCP agent is the kind of thing you containerize and network-isolate. The right packaging depends less on the capability than on the blast radius you can tolerate.
Maintenance: two rots, not one
Both packages rot, but at different layers. Skills rot as documents: products change their host behavior, libraries move their APIs, and step 4 of a playbook quietly stops working - and nothing crashes to tell you. The fix is cheap but manual: read the playbook, run it, rewrite the step. Servers rot as programs: dependencies and SDK updates produce hard errors, which are unpleasant but at least honest. The maintenance question to ask when choosing is whether you have documentation-readers or program-debuggers on the team; skills demand the former, servers the latter.
One honest gap to flag: because skills are a young convention, cross-host behavior is not documented in a way we could independently verify while building this comparison. The same skill folder may behave differently in different host applications, and we could not test that matrix - treat cross-host claims in any vendor's readme as unverified until you try it in your own environment.
A selection path that ends arguments
Four questions settle it. One: does the capability need live access to credentials, services, or long-lived state - a server, because only a process holds sessions and secrets properly. Two: is it operational knowledge plus file work - a skill. Three: how hard is the trust boundary - if you would need to explain to a security reviewer which process does what, the skill's boundary will not satisfy them; ship the server. Four: who maintains it - document-readers take skills, program-debuggers take servers.
And when the answer is genuinely both - a skill to teach the model how to think about a task, plus a server to do the privileged part - that is not indecision; it is the correct architecture, and it is what the strongest entries in our catalog do.