It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different portion of that matrix implemented.

I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules.

"Oh no it's a long lived token that's bad"

Put it in a secret manager like 1pw cli and now start an agent...

Authorization for sub-entities is what is needed.

Having to define what an agent can do when it identifies on my behalf is cumbersome, especially when you start to get specialised agents.

Pattern based would be too easy for AI to game, but there's got to be a service independent way to limit permissions based on role.

I am Jack's right ear - awesome you get to hear stuff.

I am jack's right hand - great you get to input stuff.

Hopefully quite a few.

I really love the idea of fully enabled agents and being able to cut down on human in the loop moments.

Things like https://projects.dev/ for example.

A ton of security problems and others to solve but it's still where I want the future of all this to go.

Why, directionally all of them. What they say is obviously true. Having to manually click things in the browser is a bottleneck and will be less and less acceptable for serious users.

And the individual work attached to making that transition will be done by agents.

agree. it seems there are two streams and they could diverge or converge?

1. workloads use existing credentials support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm.

2. DPoP mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with #1, or does it diverge (e.g. because most #1 methods as most are not designed for DPoP?

I've been working on a protocol that promises all of that and more. We're currently targeting a NOSTR/Buzz demo in the coming week as a proof of concept.

Even now, the mcp server itself doesn't have to implement all of the possible security options. You can use something like agentgateway to act as an auth proxy for your mcp servers.

Such an example of overengineering, why not just use OAuth?

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.

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?

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

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.

And here I thought I was old.

+1 for code mode. It's a game changer for runtime performance, flexibility of orchestrating lots of tool calls with complex logic, and all sorts of other goodies.

I'm in the process of switching all my personal stuff to a self-hosted fork of cloudflare-os right now. It's taking a lot of rearchitecting how my stuff works to fit within the cloudflare "no local files" paradigm, but for now I've got a container gatekeeper they can drive and they can check repos out in it.

What do you mean "as code mode"?

I mean… so just HTTP + OpenAPI spec?

Agree 100%, the elegance of JSON-RPC is a virtue.

At this point, I think 5 or even 10 years would be a more appropriate number (except for minor updates over things that have been around for a long time).

I clearly remember there was a time coffeescript looked really like the future of javascript.

> "only use things that have been around for at least three years"

Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.