Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
This would be more complex to implement for a simple server, but it’s not exactly difficult.
In the flip side: I’m currently designing an AI-adjacent protocol, and it will be able to map to WebTransport, but I don’t plan to define non-WebTransport HTTP bindings unless a very compelling reason appears. The main implementations will not use HTTP at all :)
I don't think there is any guarantee that HTTP will always be involved. For example I might be calling a local LLM via CLI/script on a server with a stdio MCP connector that just runs other CLI commands, and never sends any HTTP traffic.
gRPC spans layers, and it uses HTTP in a more intrusive way than even MCP does — it expects to own the entire URL space at the IP/port in question. Using gRPC in a nontrivial way for MCP would be fairly heavy-weight: you would probably need to set up reflection and figure out how to bind all the MCP calls to it unless you just use it as a tunnel.
"MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens.
The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks that agent identity needs."
"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...
Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.
https://www.1password.dev/get-started/secure-ai-access#secur...
https://1password.com/blog/1password-trusted-access-layer-fo...
Still far from perfect tho.
The complexity in these protocols is mostly essential in nature (to the extent that you're not willing to totally reinvent the protocol, like AAuth).
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.
What most end users want -- for the machine to do what they want, as often as possible, while bothering them as little as possible
Windows' UAC journey is a microcosm of the space. The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible.
But that's an all-of-ecosystem change: the OS (providing usable boundaries), applications (updating to use minimal boundaries), and users (understanding what they'll need to approve/deny).
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.
And the individual work attached to making that transition will be done by agents.
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?
1. Client generates a private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within
2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof
3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK.
4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof.
5. Clients generate fresh DPoP proofs and send them along with the access token
There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.
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.
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`.
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.
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.
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.
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.
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).
Are others doing this?
It seemed obvious to me, but I don't hear others saying it.
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.
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
On low code/no code tools, you get additional metadata for webhooks.
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.
Just give your end-users flexible options. If they have Claude Code then build more around the API side if needed.
Kind of late to the party. I've had to implement lazy loading of mcps in a couple of harnesses now but am moving to implement everything as code mode instead.
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.
I was getting fed up with AWS mcp telling me it is eol.
Every gain in LLMs is either through increases in compute efficiency, Architecture or Harnesses...
The rest seems like bells and whistles
All while it is just a fancy way make your OpenSchema PAI visible to AI.
Nobody needs to have every functionality of HTTP offloaded to MCP at all, at this point.
I'll stick to the bare minimum that works.
[1] https://doc.akka.io/libraries/akka-core/current/typed/actors...
Senior programmers always advised me to only use things that have been around for at least three years. Now I finally understand why.
I clearly remember there was a time coffeescript looked really like the future of javascript.
Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.
At the same time, it's often smart to avoid putting things into production that haven't matured or demonstrated staying power.
Or, to badly mangle Postel's law:
Be liberal in what you learn, and conservative in what you deploy
Maybe I'm old, but at least in web dev it doesn't feel that long ago that someone had to argue for, e.g., Vite over webpack, Svelte over React, etc..
I had to give maintenance to things people deployed to pad their resumes with "shiny new thing", and it was not fun.
If you intend to deploy and leave that as legacy for some poor shlemiel, sure.
If you intend to stay and actually keep things running, it's much better to use tried and tested stuff.
And I’m not OP, but I would assume the senior developers made a distinction between try and use.
They provide a set of tools and a context when to use those tools (much like a packaged version of a CLI+API and a skill) which makes them more discoverable than other options.
I've got a few folks using my open source data storage MCP - https://github.com/ExpeditedProjects/hutchdb - now and it makes a lot more sense than any other implementation for what they're doing
The other day I was heading to Home Depot to buy some gardening stuff and I was asking some some questions around what I could plant at this time and still harvest before winter.
It answers me, then brings up how my home improvement budget is nearing its limit for the month. I then ask it how I’m doing on my wider retirement plan and it mentions I’m a few thousand dollars ahead of schedule for the plan. So I decided it’s okay to go over budget on that category this month.
This type of emergent behavior of agents you work with having more context about you, it’s very useful in ways I didn’t expect.
I agree that on desktop it's not particularly relevant. Or through openclaw.
But for most people who use it through mobile, MCP solves some problems.
It's been a long time since I've used Claude, but is it not able to just use curl and an API key that it keeps in its "memory" on mobile? Or can it only use curl on the desktop?
I use MCP to accelerate CAD mould-making and for music production. I use it to avoid copying and pasting slack threads, and to let AI drive an eval system so I don’t have to manually configure things in a UI.
It’s just hard to imagine both not using it and being so sure it has no use.
Would be really interested to know how many of your customers actually use the MCP, who aren't already devs thinking like devs. I have doubts that many non-technical people are connecting AI to third-party services via MCP (or even using AI at all beyond "mundane" things like "generate an image of my cat as a clown" or "show me what my house looks like with blue paint and white trim").
I build integration for DollarDeploy but it was tricky.