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.

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 https://blog.cloudflare.com/code-mode/

Because it's a separate marketing term.

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.

It's determinism, flexibility, and language.

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.

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.

Are others doing this?

It seemed obvious to me, but I don't hear others saying it.

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

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.

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?

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

MCP can also handle authorization, since you don't want to put your password to skills.md and send it to China

Mcp predates skills - and has a more granular permission model then skills + bash commands.

I don't want to expose my API key to Claude. An stdio MCP server wrapping an API lets me hide it

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.