Jiajun (Nick) Huo

I love making something wonderful

Only an MCP server keeps the author in the loop
skill vs MCP server · who stays in the loop

You Can't Sell a Skill

TL;DR: Skills and MCP servers solve different problems. A skill teaches your agent how to work, and it runs in your environment. An MCP server is an interface to someone else's running service. Skills won the early argument on context cost, but that gap has mostly closed. What's left is a business difference: a skill is delivered once, while an MCP server sits in the path of every call. That position is why Figma, Composio, and Arc now use MCP as the gate their pricing runs through.

A year ago the momentum was all on the skills side. Simon Willison called them maybe a bigger deal than MCP (October 2025), and the argument was hard to dismiss: a skill costs a few dozen tokens until you need it, while an MCP server dumped its whole tool list into context on day one.

I've come around to a different position. Skills are great, and I write them constantly. But for anything that depends on someone else's service, I now reach for MCP first. The reason isn't technical elegance. It's that MCP is the only one of the two you can build a business on.

What MCP looked like in 2025

When I dug into MCP integrations in 2025, both the server and the client ran on my own machine. You started a local process, pasted an API key into a config file, and every tool's full description sat in the context window whether the agent used it or not. Ten servers meant hundreds of tool definitions, all loaded, all the time.

That was a developer toy, not a product surface. Nobody pays for a process they run on their own laptop with their own credentials.

Two things changed

Remote servers got a real login. The March 2025 spec added authorization based on OAuth 2.1, and an HTTP transport built for hosted servers. The November 2025 spec designs for the common case where an agent and a server have never met: the client identifies itself with a URL, the user clicks "Allow," and the connection exists. No developer portal, no API key to copy.

This is easy to misread as "MCP versus OAuth." It isn't. MCP's auth is OAuth. What MCP added is a standard way for any agent to complete OAuth with any server, without either side registering with the other in advance. Plain OAuth never solved that, and it's the reason a hundred agent clients couldn't each integrate with a thousand services.

Tools stopped eating the context window. Skills introduced progressive disclosure: load a one-line description up front, and read the full instructions only when the task calls for them. Anthropic then applied the same idea to MCP with Tool Search (November 2025). Tools can be marked as deferred, and the model searches for them when it needs them.

So MCP fixed its biggest weakness by borrowing the best idea from skills. The context argument that made skills look like the winner mostly doesn't apply anymore.

They were never the same thing

With context cost off the table, the real difference becomes visible. It's not the file format. It's where the code runs and who stays in control.

A skill is instructions, sometimes with scripts attached. It runs inside your agent's environment, with whatever credentials your agent already has. Once you hand it over, the author is out of the loop.

An MCP server is an interface to a service someone else keeps running. The agent calls it, the call goes to their machine, and it runs on their data and their compute. Behind that interface could be a single tool, a database, or another agent entirely.

That second property, the author staying in the loop on every call, is what everything else follows from.

Where the money is

A skill is delivered once. After that, there's nothing left to charge for. An MCP server sits in the path of every call.

Being in the path of every call means you know who is calling, how often, and whether they're allowed to. That's exactly what pricing needs. And the companies already doing it each charge for a different thing:

CompanyCharges byWhat the MCP server does
FigmaSeatView and Collab seats get 20 tool calls a month; Dev and Full seats get 200 a day. The server is a reason to upgrade the seat.
ComposioCallThe paid plan bills every tool call over the included amount. The server is the meter.
Arc UITimeFree and Pro components come through the same server. Sign in with a Pro account and the Pro source unlocks. The subscription buys what ships next.

Seat, call, and time. Three different pricing models, one shared gate. None of them would work if the same capability shipped as a Markdown file.

MCP doesn't stop copying

I want to be careful here, because "MCP can't be pirated and skills can" is the wrong version of this argument.

Arc is the counterexample. What its MCP server returns is component source code, and once you have the source, you can copy it as many times as you like. MCP doesn't protect anything that has already been delivered.

It also isn't the protocol doing the work. The MCP spec defines no payment mechanism, and authorization itself is optional. The business model comes from the position, not the protocol: a remote server, plus a user identity from OAuth, sitting between the agent and something that keeps changing.

So the accurate claim is narrower: MCP lets you sell access instead of content. You can't control what you've already returned. You can control who gets the next response, how many they get, and whether they get what ships tomorrow.

Where skills genuinely win

None of this makes skills less useful. They're the better choice whenever the capability belongs to you:

  • How your team writes commits, reviews code, or structures a PR.
  • A workflow your agent should follow every time, in your own repo.
  • Scripts that should run in your environment, with your permissions, without a network hop.

There's no server to keep alive, no auth flow, no latency. If nobody else needs to stay in the loop, a skill is simpler, and simpler wins.

I think of a skill as the simplest workflow there is. In Most Production Features Don't Need an Agent, I argued that an explicit workflow beats an autonomous agent whenever you can draw the control flow. A skill is that control flow written down in plain language: the steps, their order, and what to check, handed to an agent you already run. There's no graph to build, no orchestration code, and no server. When you already know the path, a skill is the cheapest way to make an agent follow it.

The test I actually use

When I'm deciding how to package a capability, I ask one question:

After I hand this over, does someone still need to be in the loop?

If the answer is no, because it's knowledge, a convention, or a script that runs locally, it's a skill. If the answer is yes, because it needs live data, someone else's compute, someone else's permissions, or updates that keep coming, it's an MCP server. And if it's a yes, you've also found the place where it can be priced.

A skill teaches your agent how to work. An MCP server connects it to someone else's business.

Sources

Pricing and limits were checked on each company's own page on October 21, 2026.