I still struggle to see how a MCP endpoint is easier for agents to work with compared with a REST endpoint and a skills.md file.
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.
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.
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.
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.
MCP has not smoothed over legacy cruft, and it is generally bad at exactly what you’re describing (many unintentionally coupled APIs with unintentional side effects). These require near deterministic trajectories and you’d be better off creating a consumer with a series of well known good patterns with useful results.
If you take it a step further you may allow for a common language and keyspace of these well known results and employ dynamic solvers that are entirely agnostic. LLMs have made creating these much easier!
But there are also folks who put thought into omitting extraneous fields, combining multiple low-level calls into a single tool that covers a common end-to-end use case, and writing much better documentation. With the political air cover that it is in service of the AI boom. Essentially it gave everyone the opportunity to implement API vN+1.
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.
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`.
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.
Instead of the CEO mandating that the API server has to be agent compatible (where who knows what that means), they can just say "our product has an MCP".
On a technical level, who knows what it actually is (is it actually the new stateless version, does it have all the endpoints, is the regular API more feature-rich, do I need those features for my workflow?, etc.). But at a surface-level, the intention is clearer, and lets other gears (like sales and marketing) keep spinning without getting bogged down in technical details.
Are others doing this?
It seemed obvious to me, but I don't hear others saying it.
On low code/no code tools, you get additional metadata for webhooks.
It only has five CRUDE endpoint: Create, Read, Update, Delete, and Execute using a GraphQL-like structure for tool calling of the operations within the endpoints. It's very efficient, and robust. there's all kinds of exemplar tools and components to make adapters for any MCP server. You don't even need to rewrite your own MCP server. Just create an adapter for it.
All open source at MCPAQL.com
We tag each endpoint by category in the OpenAPI spec and require the MCP to request actions by tag and optional query term. At most we return 10 endpoints at a time and the LLM can request more using pagination.
These tags also create your categories in API doc websites like swagger/mintlify so its a win win.
OpenAPI spec is the single source of truth.
To the LLM, the a skill input is deterministic, inflexible, and outputs natural language.
A REST API (not the REST itself, but modern output being JSON primitives) outputs are deterministic, flexible, but doesn't output natural language.
An MCP as an input is deterministic, flexible, outputs natural language.
Then we ask the same question on whether the LLM gets back a response that is deterministic. Skills output are not deterministic, it requires LLM to generate tokens to take action. It may or may not take the specific actions instructed by the skill.
So, Skills + REST API = MCP only if you can deterministically call on the REST API.
* /skill may or may not call on the instructed action
* /tool (or @tool) will guarantee the action is taken
This is overgeneralizing and we need to talk about harness-specific features like hooks (which adds a deterministic action to skill usage).
* Your agent can easily be configured to always allow certain MCP tools. This is very hard to do for only certain REST endpoints. This is even more relevant in enterprise settings, where permission configs might be done centrally.
* If the provider wants to change how an endpoint works, it's a breaking change for a REST API. Not with MCP, as the "endpoints" (tools) are dynamic and tell the agent how to use them.
LLMs do GREAT utilizing well-defined tools to accomplish tasks. Look at Datadog's MCP, instead of figuring out a multitude of filter and navigation options your LLM can immediately navigate to what you want and extract the precise data you need. Tool instructions with defined I/O structures let LLMs fly.
But for a nightly cron job pulling down stats or something like that? Why the hell do you want to route through a protocol built for in-person consumption? This is such a pointless overreach for the protocol. What would have been better is blessing a standardized pattern for exporting any MCP tool definition into a well-structured API endpoint. Then everything related to API endpoints like doc generation, comes along for free.
Instead we get this kitchen sink protocol that is going headlong toward polyfill hell, since no two IDEs support the same protocol features like structured content, local state, elicitations, etc., even from the same provider - Claude Code/Desktop/web all handle MCP connections differently. It's a shitshow.
Almost every major MCP service uses the same baseline default features (plain context) rather than build around partially-supported features. Why add more and more specs on the pile when adoption is so far behind?
it's like saying "i don't want to give Claude access to my file system but i'm fine letting it run bash" ......
Plus why spawning processes all the time.