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.
it's not easier for agents to work with. it's easier for organizations to work with.<p>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.<p>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.
> it's easier for organizations to work with.<p>I can see that.<p>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.<p>Maybe there are easier ways to do it, just learning and exploring now.
This is how I'm doing it as well, for an internal enterprise platform for agentic workflows. Let's me implement as fine-grained access rules as I want, and gives me somewhere that can hold credentials without exposing them to the agent.
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.<p>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.<p>It is an unuseful fiction that by storing a blob of instructions next to a remote endpoint that things have been made easier.
No need to invent skill.md distribution protocols. Use `/.well-known/agent-skills/index.json` -- see <a href="https://github.com/agentskills/agentskills/pull/254" rel="nofollow">https://github.com/agentskills/agentskills/pull/254</a>.<p>It's already in use in several places (e.g., <a href="https://www.mintlify.com/docs/ai/skillmd#skills-discovery-endpoints">https://www.mintlify.com/docs/ai/skillmd#skills-discovery-en...</a>) 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?
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.
That would be /llms.txt <a href="https://llmstxt.org/" rel="nofollow">https://llmstxt.org/</a>
How is distributing a markdown file the bottleneck?
It is the <i>automatic</i> distribution and <i>automatic</i> 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".<p>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.<p>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.
Because it’s something else that’s non-standard between providers.
Or you can just have a URL that points to skill.md?
Not all agents have access to a sandbox/cli/code execution environment to run arbitrary api calls etc. MCP helps by essentially having another tool call without needing a sandbox. If you do have a sandbox, then might as well do codemode if you insist on mcp <a href="https://blog.cloudflare.com/code-mode/" rel="nofollow">https://blog.cloudflare.com/code-mode/</a>
Because it's a separate marketing term.<p>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".<p>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.
All that, yes. And at a technical level, it is much easier to have a single spec to follow. When a customer complains that their client isn't working, I can point at how they aren't following OAuth discovery properly or something.
At my company Parallel AI, I just built an extremely well documented openapi spec and then MCP builds from that. Complete alignment with UI/API/MCP so there is no extra work.<p>Are others doing this?<p>It seemed obvious to me, but I don't hear others saying it.
The challenge with this is that it often causes a proliferation of MCP tools which bloats context, which is one of the reasons that MCP was created.
Oh sorry I didn't explain that we are not dumping the entire endpoint list to the MCP. We have 400+ endpoints so this would be terrible.<p>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.<p>These tags also create your categories in API doc websites like swagger/mintlify so its a win win.<p>OpenAPI spec is the single source of truth.
I created MCP AQL, which is an extension to the MCP spec, specifically to reduce the bloat for MCP tools.<p>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.<p>All open source at MCPAQL.com
Just because a MCP server offers 100 MCP tools doesn't mean that they all have to be in your context. Any decent harness will let you filter out ones you don't want. And to take that concept further you really should be designing specialized subagents that only have access to a small subset of total MCP tools in the first place.
Yes, for .NET and Java backend stuff, it is basically extending what is already there.<p>On low code/no code tools, you get additional metadata for webhooks.
It's determinism, flexibility, and language.<p>To the LLM, the a skill input is deterministic, inflexible, and outputs natural language.<p>A REST API (not the REST itself, but modern output being JSON primitives) outputs are deterministic, flexible, but doesn't output natural language.<p>An MCP as an input is deterministic, flexible, outputs natural language.<p>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.<p>So, Skills + REST API = MCP only if you can deterministically call on the REST API.
Companies got to release an MCP server for their product and tell their investors they were pivoting to be AI native.
The model has zero awareness of MCP, it’s the harness’ job to talk to the MCP server and simply present the model with the tools just like any other tool. The only giveaway to the model about where the tools come from is the ‘mcp__’ prefix in the name
Yep. I’ve found that having an endpoint that serves a well, documented openapi.yaml is very effective for agentic usage. The biggest difference is that you can break down a REST API into RPC-like chunks and save on some tokens if you break up the tools well. But pragmatically, I think saying “tell your agent to hit /api/v3/openapi.yaml” is quite useful
We did a prototype to integrate an agent into our application and basically just gave it a tool to discover the OpenAPI spec and call endpoints. It worked surprisingly well! One caveat was that some responses were too big and would poison the context, but then I gave the agent a GraalJS engine and allowed it to save responses and post-process them using JS. For the little amount of work required this gives the agent a lot of power without having to give it full CLI and without having to create bespoke tools.
I work on an MCP server and I agree. There is no need to make MCP servers the gateway for agentic or programmatic integration - that's exactly what API servers handle out of the box. The value of MCP servers is fine-toothed access on a tool-by-tool basis and leaving output digestion to the LLM.<p>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.<p>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.<p>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.<p>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?
MCP can also handle authorization, since you don't want to put your password to skills.md and send it to China
I don't want to expose my API key to Claude. An stdio MCP server wrapping an API lets me hide it
Mcp predates skills - and has a more granular permission model then skills + bash commands.
easier to gate MCP tools? you can allow/deny tools very easily
or a CLI
Me too, it is just another RPC endpoint, heck all of this kind of stuff could even be done with Sun RPC.