it's not easier for agents to work with. it's easier for organizations to work with.
for agents, they're essentially the same thing - remote endpoints, and instructions on how to call those endpoints. what MCP brings is centralized updating and distribution of the instructions, and a promise that the skill and the REST api won't be out of sync with each other.
the one thing that skill.md+REST doesn't solve is how you get that skill.md to somebody else's computer, and how you ship an update to somebody else's computer once they've got a copy of the skill. if that's a problem you need to solve, you can either start inventing skill.md distribution protocols, or you can just use MCP.
Enterprises have been managing thousands of http endpoints for decades now. It is not easier. It would have been easier to have something swaggeresque that lives at the openapi spec layer but that’s not cool and AI.
What is not hard to understand is that EVERY MCP UPDATE is almost certainly a breaking change. The versioning story is not as mature. The models using it are different.
It is an unuseful fiction that by storing a blob of instructions next to a remote endpoint that things have been made easier.
> it's easier for organizations to work with.
I can see that.
I am developing my first custom agents. I am finding that if I offload some workflow to another agent (e.g. Claude Code), the simplest way to control what it can or cannot do is via an MCP server (which only lets it access tools that I develop/approve myself). I do need that control in the corporate environment.
Maybe there are easier ways to do it, just learning and exploring now.
No need to invent skill.md distribution protocols. Use `/.well-known/agent-skills/index.json` -- see https://github.com/agentskills/agentskills/pull/254.
It's already in use in several places (e.g., https://www.mintlify.com/docs/ai/skillmd#skills-discovery-en...) and is supported by `npx skills add`.
Maybe I just need more patience, but I took a look at some tools that have MCPs, and their "setup guide" on how to start using the MCP server really gave me brain damage. Is this really easier to work with?
For antiquated "enterprise" APIs that were already a mess of legacy cruft, yes. MCP forced vendors to reconsider the ergonomics of their interface.
It seems like organizations will mostly want remote access via http and the other flavors of MCP aren’t so useful? Although, I suppose if you install an app locally, it might have an MCP interface.
I guess it's similar to SOAP, it was usually over HTTP but sometimes the alternatives were used (eg. email [1])
[1]: https://www.w3.org/TR/soap12-email/
That would be /llms.txt https://llmstxt.org/
How is distributing a markdown file the bottleneck?
It is the automatic distribution and automatic update. The questions isn't "how does one download a text file to another persons computer?". It is "how does someone with a skill.md file on their computer discover that a new version of that file is available".
This isn't a "bottleneck" but rather a capability (or lack thereof). As you add more and more capabilities, especially ones relevant to enterprise situations like authentication, authorization, governance, etc. then MCP starts to pay off.
If you do not need those capabilities, then you do not need MCP. And then you shouldn't use it. But if you do need those capabilities then it might be worth using MCP rather than inventing your own way to do them.
I see. In my head it would be something like the agents harness having a list of services it interacts with, reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.
Valid. There are many ways to do it.
But for enterprise there may be teams, each developing their own way to do it. Then there will be many different ways that it is done throughout the enterprise, which is hard re: governance. Better/easier to adhere to an industry standard which can be audited, especially for enterprises where that is a legal requirement.
That isn't a reason you should use it, just an explanation about why someone has to use it.
>reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.
that is basically what MCP is. except it answers all the questions that your version handwaves away - how often do you get a fresh copy, how do you describe the relevant tool calls, how are the tools organized, and how does auth work.
If that truly is the main selling point - it seems like a shallow moat versus skills + rest..
Because it’s something else that’s non-standard between providers.