Rendered at 23:51:47 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rco8786 1 days ago [-]
> With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload
Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
colingauvin 1 days ago [-]
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.
tarun_anand 9 hours ago [-]
Wrote about this last year and wanted to unify it... at that time the community was so excited about MCP being the best thing since sliced bread
Is stdio being deprecated? I couldn't tell from this page
amluto 1 days ago [-]
The prose on the page is very unclear. My best interpretation is that they want to continue supporting stdio but that they don’t want it to be its own special protocol. The obvious way to do that would be to speak ordinary HTTP (version 1.1? 2?) over stdio and to use the MCP-over-HTTP protocol over the resulting HTTP transport.
This would be more complex to implement for a simple server, but it’s not exactly difficult.
Gormo 1 days ago [-]
Not everyone is on board with the idea of HTTP being the exclusive universal IPC bus.
amluto 1 days ago [-]
I’m not really a fan. But if you’re building a protocol that needs to map to HTTP anyway, then maybe using the HTTP binding everywhere is not totally awful.
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 :)
ranger_danger 1 days ago [-]
> if you’re building a protocol that needs to map to HTTP anyway
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.
amluto 1 days ago [-]
Right. But there is a lot of real-world usage of MCP-over-HTTP-over-the-Internet, and a lot of “harnesses” want to support that use case, so they’re stuck either implementing the HTTP-based protocol or using a shim.
oblio 5 hours ago [-]
What's the disadvantage? MCP doesn't strike me as a high performance protocol.
pstuart 1 days ago [-]
Would you prefer gRPC, thrift, avro, etc... ?
amluto 1 days ago [-]
Those are mostly at a different layer. You can speak Thrift or Avro or Protobuf over stdio or HTTP or TCP or carrier pigeon.
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.
I would prefer a core transport agnostic protocol, and then see MCP-over-HTTP being a spec on top of that.
jauntywundrkind 17 hours ago [-]
I'm pretty ok with http, but, I'd throw https://varlink.org in as my second pick.
intrasight 1 days ago [-]
Count me as not on board
nprateem 1 days ago [-]
The real disaster was making it stateful. Need to get some adults in the room.
nostrebored 1 days ago [-]
Your stateful remote execution needs a stateful tool middleware for your stateful agent, just to make sure that it’s impossible to test or evaluate
otabdeveloper4 13 hours ago [-]
Don't worry about it, the very best Claude tokens designed, implemented and tested it.
What are you, some sort of luddite?
Jhater 1 days ago [-]
[dead]
izend 1 days ago [-]
I am very curious how many MCP servers will actually implement all of this:
"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."
zackify 1 days ago [-]
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...
danappelxx 1 days ago [-]
How does the agent auth with 1pw? How do you give it access to only the credentials it needs, with an approval flow and revocation? Who renews the token? You’ll likely end up reinventing something pretty close to what MCP is building towards.
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.
elenaviter 7 hours ago [-]
There might be the "agent card" - one place where the user manages what a specific agent is allowed to do. The user grants it tools, connects the accounts those tools need, narrows or revokes any of that at any time. For an autonomous agent the card is prepared and consented before the run.
Such card is the primitive in so called "connection hub", a centralized component, and is rendered from what is declared there: tools declare their claims, accounts get connected in the browser (google docs tools need a google account connected), on their own or as part of preparing the card. Account credentials live in this hub, with the claims the user approved when connecting.
The agent authenticates with one token issued for this card and never receives the connected accounts credentials. Every operation is checked against the grant and this agent's binding to the account. If something is missing, the agent gets unauthorized with the details on what exactly. If the check passes, the hub, loaded by the server as a lib or reached in its internal network, releases the account credential into the operation's execution context. Account credentials renewal happens on hub.
Revoking grant is also done in card and leads to agent's unauthorized on that op next call.
Sub-agent and any automation are also such agents and also can be managed with such card.
So such hub develops into a useful ecosystem component, standalone, like an IdP for login.
An MCP server then works together with this hub, it only declares its claims in the hub (so the hub knows what to render in the agent card).
While all these auth realm duties such as approvals, the revocation and the credentials storage live "at infrastructure".
The perceived difficulty is not what is at play here. People and employers are not comfortable with the idea of long lived credentials to begin with -- and even less in the 'hands' of an AI agent.
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).
bensyverson 8 hours ago [-]
Yes, MCP was already overly complicated, and these new features will make it even more unapproachable.
If I need to integrate with a third party service, I'm now skipping their MCP entirely and just going straight for the CLI or API, which are usually more full-featured. An agent usually doesn't even need a dedicated Skill for this.
mpyne 1 days ago [-]
That doesn't work well for enterprise-managed MCP, where you actually do want the user to overtly authorize their agent to user their identity for MCP services, rather than the MCP server just setting a user ID in an HTTP header somewhere and everyone hoping for the best.
sofixa 8 hours ago [-]
> "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...
And when the agent does something stupid, your long lived token is compromised. It also makes it hard to segregate access (e.g. all those "Cursor deleted by production DB and all its backups because it had an API key that could do that").
Nope, you should instead use something that give short-lived tokens, ideally ones scoped based on the desired intent / operation. Or even better, skip the "agent gets a token" part at all, and have all agent operations pass through a gateway/agent/proxy/whatever that handles that part. That way even if the agent gets comrpomised or does something dumb, it doesn't have even a short lived token to give away.
_puk 1 days ago [-]
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.
What people who care about security want -- finely grained permissions that guarantee security boundaries, at the expense of bad UX
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).
mooreds 13 hours ago [-]
Yeah. If we want fine grained "intelligent" authorization, there's a lot of work to be done. You can't simply slap a gateway on existing systems.
I wrote about this more on my employer's blog[0].
> 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.
And this is an even larger effort to implement, especially as agent capabilities change over time (and they are changing rapidly).
A ton of security problems and others to solve but it's still where I want the future of all this to go.
jstummbillig 1 days ago [-]
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.
gz5 1 days ago [-]
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?
maxwellg 1 days ago [-]
It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client:
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.
otabdeveloper4 13 hours ago [-]
Are you reinventing SPIFFE here?
maxwellg 8 hours ago [-]
No - this is built on top of SPIFFE/WIMSE work to enable cross-domain usage where the target domain speaks OAuth instead. You wouldn't expect, say, Slack's APIs to accept SPIFFE SVIDs from your internal deployment. This provides a path for you to exchange your SVID for a Slack-issued Access Token.
bandofthehawk 1 days ago [-]
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.
aliasxneo 1 days ago [-]
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.
huksley 1 days ago [-]
Such an example of overengineering, why not just use OAuth?
dayjah 1 days ago [-]
WIF works far better when you don’t want humans in the loop. For example, we’d do our development on cloud instances, those have identity linked to our humans via our IdP. Our IdP governs all access, for example: it lets devs use Datadog. If an agentic workflow needs Datadog access and the MCP requests OAuth that slows the loop down. At the same time, we don’t want Service Accounts everywhere because we need to be able to answer “who” a lot for compliance reasons.
ljm 7 hours ago [-]
Any service offering MCP that doesn't already have OAuth set up is going to have to build out that support first, so instead they just go for a simple API token.
I wouldn't call it trivial to drop in OAuth either because the authentication is one part, but wiring it up into whatever authorization set up they have is another bit of work.
An AI agent would get the most benefit out of OAuth + ephemeral service accounts (the user is having a bot act on behalf of it) + fine grained scopes.
lll-o-lll 19 hours ago [-]
The dpop thing is oauth. It’s providing a significant enhancement to preventing token replay, or token theft, at the cost of some request size bloat + an additional key verification.
brookst 1 days ago [-]
Oauth assumes interactivity
lll-o-lll 19 hours ago [-]
No. Client assertion flow is for services (or agents).
brookst 10 hours ago [-]
Thanks, TIL. Will read up.
DarmokTanagra 10 hours ago [-]
The entire premise of MCP is misguided and completely counter to the core value proposition of ai agents.
Its insane to me how quickly people flocked to the idea of building a parallel web to maintain for non humans.
I shouldnt be surprised seeing how low priority human accessibility and ux has been on the web when compared to the needs of the all consuming parasite that is ad tech.
ricardobeat 9 hours ago [-]
It was actually a welcome change for 'web access'. There were very few open APIs left, MCP forced everyone to actually build public APIs again.
qingcharles 4 hours ago [-]
This. It's amazing how long humans have screamed for good APIs, cheaply accessible for lots of web sites and all we got were crickets. LLMs come along and the same sites are falling over themselves to build extensive APIs. It's the golden age of APIs finally.
edgyquant 10 hours ago [-]
MCP is at its simplest just a way to describe what the different api endpoints do to an llm and we need some protocol for this. MCP works and is a fine protocol for this
cube00 1 days ago [-]
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.
notatoad 1 days ago [-]
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.
nostrebored 24 hours ago [-]
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.
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.
esalman 1 days ago [-]
> it's easier for organizations to work with.
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.
nevon 15 hours ago [-]
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.
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?
anon84873628 1 days ago [-]
For antiquated "enterprise" APIs that were already a mess of legacy cruft, yes. MCP forced vendors to reconsider the ergonomics of their interface.
nostrebored 24 hours ago [-]
What do you mean by this? It certainly sounds technical but it seems to not mean anything.
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!
anon84873628 22 hours ago [-]
Of course MCP can still be implemented poorly by just making a 1:1 clone of the existing API.
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.
skybrian 1 days ago [-]
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.
cube00 1 days ago [-]
I guess it's similar to SOAP, it was usually over HTTP but sometimes the alternatives were used (eg. email [1])
How is distributing a markdown file the bottleneck?
stillpointlab 1 days ago [-]
It is the automatic distribution and automatic 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".
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.
boredumb 1 days ago [-]
I see. In my head it would be something like the agents harness having a list of services it interacts with, reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.
notatoad 1 days ago [-]
>reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.
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.
liquicity 1 days ago [-]
If that truly is the main selling point - it seems like a shallow moat versus skills + rest..
stillpointlab 1 days ago [-]
Valid. There are many ways to do it.
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.
1 days ago [-]
tass 1 days ago [-]
Because it’s something else that’s non-standard between providers.
valicord 23 hours ago [-]
Or you can just have a URL that points to skill.md?
MikhailTal 1 days ago [-]
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/
agentdev001 23 hours ago [-]
Devil's advocate will say "Well, the agent would need an MCP client to use MCP-served resources... if you can give it that, why not give it an HTTP client?"
preommr 1 days ago [-]
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.
anon84873628 1 days ago [-]
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.
davidrichards 1 days ago [-]
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.
techscruggs 1 days ago [-]
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.
mickdarling 1 days ago [-]
I created MCP AQL, which is an extension to the MCP spec, specifically to reduce the bloat for MCP tools.
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
davidrichards 1 days ago [-]
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.
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.
xienze 1 days ago [-]
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.
pjmlp 1 days ago [-]
Yes, for .NET and Java backend stuff, it is basically extending what is already there.
On low code/no code tools, you get additional metadata for webhooks.
adrian_m 11 hours ago [-]
Off the top of my head:
* 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.
mendapi 11 hours ago [-]
[flagged]
mikeocool 1 days ago [-]
Companies got to release an MCP server for their product and tell their investors they were pivoting to be AI native.
ketozhang 1 days ago [-]
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.
ketozhang 1 days ago [-]
In other words:
* /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).
wolttam 1 days ago [-]
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
peterlk 1 days ago [-]
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
ulrikrasmussen 1 days ago [-]
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.
lubujackson 1 days ago [-]
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?
big-chungus4 1 days ago [-]
MCP can also handle authorization, since you don't want to put your password to skills.md and send it to China
ihuman 1 days ago [-]
I don't want to expose my API key to Claude. An stdio MCP server wrapping an API lets me hide it
mathisfun123 1 days ago [-]
wtf is the difference when 1) you put a key in front of the mcp 2) you mcp a whole bunch of privileged access.
it's like saying "i don't want to give Claude access to my file system but i'm fine letting it run bash" ......
intrasight 1 days ago [-]
The difference is that the LLM never sees your keys/secrets. My understanding is that can make a big difference.
JV00 1 days ago [-]
Does mcp guarantee that, per se?
anon84873628 1 days ago [-]
Not if you assume the straw man like grandparent, but yes if you use it thoughtfully.
ffsm8 1 days ago [-]
Mcp predates skills - and has a more granular permission model then skills + bash commands.
c0rruptbytes 1 days ago [-]
easier to gate MCP tools? you can allow/deny tools very easily
pianopatrick 1 days ago [-]
or a CLI
pjmlp 1 days ago [-]
CLI don't work in cloud environments like MACH architecture.
Plus why spawning processes all the time.
1 days ago [-]
fallat 1 days ago [-]
This is the strongest argument I've seen against CLI for LLMs. Thank you.
pjmlp 1 days ago [-]
Me too, it is just another RPC endpoint, heck all of this kind of stuff could even be done with Sun RPC.
rglover 1 days ago [-]
The degree to which this idea has been overcomplicated is confusing. This could have been solved with some relatively simple patterns wrapped around HTTP and WebSockets (and if absolutely necessary, SSE).
macrolime 9 hours ago [-]
I've tried many MCPs, but have yet to find any that are actually useful. It seems it's generally better to just have the agent run CLI commands and maybe use some skills. From what I can find, MCPs are nothing but bloat. Is anyone aware of any truly useful MCPs that doesn't work better and less bloaty by skipping the MCP part?
sajithdilshan 8 hours ago [-]
Depends on what tool you use. As an example for github gh is way more efficient than using the github MCP because the training data of LLM actually contains gh documentation and how to use it.
However, if you have a very niche command tool or a work related internal tool, LLM has no idea on how to use it and it could waste a lot of tokens by trying to figure out what works and what doesn't and how to use it in every session. That's where MCP comes in handy. LLMs are trained to use the MCP protocol and it can efficiently figure out which tool to be called and how to process the output when a niche command tool is exposed via an MCP.
mmaunder 1 days ago [-]
My dream was for MCP to allow services like ours (cybersecurity) to provide a self documenting endpoint with authentication, and we just give users a URL and it just frikkin works. Instead from day 1 it’s been multiple standards as they pivoted, a context hungry feature, and feels like a kludge. That burned the idea of MCP for me and I’ve had such success with local tools and APIs that it’ll take a lot for me to go back.
brap 1 days ago [-]
I mean… so just HTTP + OpenAPI spec?
mmaunder 1 days ago [-]
It actually doesn’t matter. Pick your favorite way of giving a dev access to capability on a remote server.
dmix 1 days ago [-]
Plus You're likely building an API already if you have an MCP. Not everyone using MCP is a dev, we have random corporate workers using our MCP. They don't know what an API is but they can add a plugin from an agent marketplace (which can also contain skills) and MCP is a bit narrower with a clear authorization system, tool discovery, and annotations (agents ask "confirm you want you want to write this").
Just give your end-users flexible options. If they have Claude Code then build more around the API side if needed.
mikeegg1 1 days ago [-]
When I see "MCP" I still translate that to Master Control Program.
dingaling911 1 days ago [-]
And here I thought I was old.
huksley 1 days ago [-]
In v.1 making MCP stateful was such a deployment-unfriendly way to do it - you need a complicated persistence layer for it to work.
All while it is just a fancy way make your OpenSchema PAI visible to AI.
skinfaxi 1 days ago [-]
> We’re starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows.
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.
wilj 1 days ago [-]
+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.
I was getting fed up with AWS mcp telling me it is eol.
rixed 1 days ago [-]
Interesting, thank you.
Are you aware of any quantitative data to back up the claim that llms are more performant in code mode than mcp mode? Not that i doubt it, but I'm curious about how big of a difference it can make.
vatsachak 1 days ago [-]
Why not just give the model a prompt?
Every gain in LLMs is either through increases in compute efficiency, Architecture or Harnesses...
The rest seems like bells and whistles
threecheese 1 days ago [-]
I wish the “sampling” feature - which is being removed - had found more use. BYO Inference could be really useful in a walled garden like Claude Code, where you are unable to leverage inference outside of that garden without paying per token. Maybe that feature was just more interesting than it was useful.
youre-wrong3 23 hours ago [-]
People seem to ignore the fact that with MCP you can serve up the tools the user wants and has access to instead of a rest api doc specifying every endpoint and bloating the context.
gf000 14 hours ago [-]
All those tools still get into context. Also, it's not hard to filter a rest api doc - like with a special tool for that the harness itself could pre-filter it and add only the relevant ones as tools to be even more leaner than what an MCP returns.
hobofan 10 hours ago [-]
> All those tools still get into context.
100% up to the harness. Most harnesses either fixed (or dymanically depending on size) nowadays add a "search_tool" tool to prevent spamming the context with all tools.
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.
sjeno 1 days ago [-]
Agree 100%, the elegance of JSON-RPC is a virtue.
jdw64 1 days ago [-]
Sometimes I really respect senior developers. When specs change, you obviously have to update existing work too. Looking at this MCP change, it seems like it's becoming stateless—I'm already wondering how to adapt.
Senior programmers always advised me to only use things that have been around for at least three years. Now I finally understand why.
raincole 1 days ago [-]
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.
chrisweekly 1 days ago [-]
> "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.
Bjartr 1 days ago [-]
Keeping up with changes is valuable.
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
DarmokTanagra 6 hours ago [-]
Trying is not the same thing as advocating for and implementing products features using unproven tech.
Ive been in this industry nearly 40 years and I have seen many many people push new tech and later fail to deliver and suffer the consequences.
Experiment where it doesnt matter, everywhere else boring and old is a virtue.
beepbooptheory 1 days ago [-]
Just curious, what kind of work have you done where this conceit feels valid in your mind? My career, at least, feels like an exception to this, but I guess its conceivable to me that it could be otherwise. You have had a lot managers push newer frameworks/technologies on you? Is this more VC startup land, or something else?
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..
surgical_fire 1 days ago [-]
Depends on the thing.
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.
techpression 1 days ago [-]
Three years is nothing, what kind of work do you do where you need something released in the last three years?
And I’m not OP, but I would assume the senior developers made a distinction between try and use.
hnrprtlpdb 1 days ago [-]
Half the battle is just knowing this exists
bhavikagarwal20 14 hours ago [-]
support for media is really needed in mcp now
firatsarlar 1 days ago [-]
Truth doesn't move much. It moves slowly, so that those holding onto it don't fall. Keep up.
simianwords 1 days ago [-]
Is there a way in MCP where I can "approve" certain privileged actions? Like imagine an MCP for buying stuff in Amazon but it can do everything including payment but is behind a gate that the human needs to approve
somnium_sn 1 days ago [-]
Yes use MCP elicitations
paidx 9 hours ago [-]
[flagged]
svyatoslavpavl 1 days ago [-]
[flagged]
mendidou 12 hours ago [-]
[dead]
futurist_hp 14 hours ago [-]
[flagged]
manganate06 4 hours ago [-]
[flagged]
usxr1515 1 days ago [-]
[flagged]
castroneto 1 days ago [-]
[flagged]
madmecodes 1 days ago [-]
[flagged]
kevinbaiv 1 days ago [-]
[dead]
felixlu2026 14 hours ago [-]
[dead]
cjg007 1 days ago [-]
[dead]
luciana1u 1 days ago [-]
[dead]
hnub7akvk6 1 days ago [-]
[flagged]
LowTechHN 1 days ago [-]
[flagged]
michaelbuckbee 1 days ago [-]
I'm very bullish on MCP (or at least MCP "like" implementations), as they solve a lot of problems for non-devs as they're much easier and safer to add into ChatGPT, Claude and other desktop + web apps.
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
petcat 1 days ago [-]
I agree, I've found MCP to be a waste of time. Any HTTP API + OpenAPI spec is sufficient to get my agents to do anything they need to do. Bonus that it just uses regular HTTP semantics and all the tools and infrastructure that have been developed around that for decades. Instead of some inscrutable json RPC POST-only payload that needs tons of custom tooling for introspection, logging, etc.
willio58 1 days ago [-]
So I’ve been working on a personal finance app, and I added an MCP to it. Connected my Claude to it, mainly for testing purposes.
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.
nozzlegear 1 days ago [-]
Is that really much different from building an API for your app though? Claude can use those just as easily.
dcrazy 1 days ago [-]
MCP is essentially just a convention for APIs that standardizes the concept of a “resource”. It spares the LLM a lot of work figuring out what the “things” are in a problem domain, and how various endpoints relate to those “things”.
rolisz 1 days ago [-]
With authentication and on mobile?
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.
nozzlegear 1 days ago [-]
> With authentication and on mobile?
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?
brookst 1 days ago [-]
I’ll never understand the “I’ve never used it but am absolutely certain I would get zero value from it if I did” mentality.
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.
ewild 1 days ago [-]
Because you're a dev thinking for devs. No 60 year old is going to use Claude skills with the CLI. If my customers want their AI to interact with my product and MCP is the best way about it.
nozzlegear 1 days ago [-]
> If my customers want their AI to interact with my product and MCP is the best way about it.
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").
ewild 1 days ago [-]
I actually have data on this albeit it's a bit skewed. None of our clients are dev like folk but they are financial folks. We sell financial data for big players so not the analysts (seat cost is over 50k per year) and of our ~10k users within the last 6 months of us launching MCP we have 1500 DAUs on the MCP
nozzlegear 1 days ago [-]
That's quite interesting, thanks!
drob518 1 days ago [-]
I use Pi and I’m coming to the conclusion that mostly all I need is a bash tool.
huksley 1 days ago [-]
If you need to give access to your CRM/ERP system from ChatGPT / Claude desktop for non-tech users, MCP is the way.
I build integration for DollarDeploy but it was tricky.
Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
https://github.com/modelcontextprotocol/modelcontextprotocol...
https://news.ycombinator.com/item?id=43959474
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.
What are you, some sort of luddite?
"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.
The agent authenticates with one token issued for this card and never receives the connected accounts credentials. Every operation is checked against the grant and this agent's binding to the account. If something is missing, the agent gets unauthorized with the details on what exactly. If the check passes, the hub, loaded by the server as a lib or reached in its internal network, releases the account credential into the operation's execution context. Account credentials renewal happens on hub. Revoking grant is also done in card and leads to agent's unauthorized on that op next call. Sub-agent and any automation are also such agents and also can be managed with such card.
So such hub develops into a useful ecosystem component, standalone, like an IdP for login. An MCP server then works together with this hub, it only declares its claims in the hub (so the hub knows what to render in the agent card). While all these auth realm duties such as approvals, the revocation and the credentials storage live "at infrastructure".
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).
If I need to integrate with a third party service, I'm now skipping their MCP entirely and just going straight for the CLI or API, which are usually more full-featured. An agent usually doesn't even need a dedicated Skill for this.
> Put it in a secret manager like 1pw cli and now start an agent...
And when the agent does something stupid, your long lived token is compromised. It also makes it hard to segregate access (e.g. all those "Cursor deleted by production DB and all its backups because it had an API key that could do that").
Nope, you should instead use something that give short-lived tokens, ideally ones scoped based on the desired intent / operation. Or even better, skip the "agent gets a token" part at all, and have all agent operations pass through a gateway/agent/proxy/whatever that handles that part. That way even if the agent gets comrpomised or does something dumb, it doesn't have even a short lived token to give away.
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 wrote about this more on my employer's blog[0].
> 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.
And this is an even larger effort to implement, especially as agent capabilities change over time (and they are changing rapidly).
0: https://fusionauth.io/blog/ai-authorization
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.
I wouldn't call it trivial to drop in OAuth either because the authentication is one part, but wiring it up into whatever authorization set up they have is another bit of work.
An AI agent would get the most benefit out of OAuth + ephemeral service accounts (the user is having a bot act on behalf of it) + fine grained scopes.
Its insane to me how quickly people flocked to the idea of building a parallel web to maintain for non humans.
I shouldnt be surprised seeing how low priority human accessibility and ux has been on the web when compared to the needs of the all consuming parasite that is ad tech.
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.
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.
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`.
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.
[1]: https://www.w3.org/TR/soap12-email/
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.
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.
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.
On low code/no code tools, you get additional metadata for webhooks.
* 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.
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).
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.
However, if you have a very niche command tool or a work related internal tool, LLM has no idea on how to use it and it could waste a lot of tokens by trying to figure out what works and what doesn't and how to use it in every session. That's where MCP comes in handy. LLMs are trained to use the MCP protocol and it can efficiently figure out which tool to be called and how to process the output when a niche command tool is exposed via an MCP.
Just give your end-users flexible options. If they have Claude Code then build more around the API side if needed.
All while it is just a fancy way make your OpenSchema PAI visible to AI.
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
100% up to the harness. Most harnesses either fixed (or dymanically depending on size) nowadays add a "search_tool" tool to prevent spamming the context with all tools.
[1] https://doc.akka.io/libraries/akka-core/current/typed/actors...
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.
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
Ive been in this industry nearly 40 years and I have seen many many people push new tech and later fail to deliver and suffer the consequences.
Experiment where it doesnt matter, everywhere else boring and old is a virtue.
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.