Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.by threecheese
- 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?by macrolime
- 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.
- 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
by vatsachak - > 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.
by skinfaxi - What do you mean "as code mode"?by rixed
- +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.
by wilj - 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.
by huksley - 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.
by jdw64 - > "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.
by chrisweekly - 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.
by raincole - When I see "MCP" I still translate that to Master Control Program.by mikeegg1
- And here I thought I was old.by dingaling911
- 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).by rglover
- 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.by mmaunder
- I mean… so just HTTP + OpenAPI spec?by brap
- 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.by cube00
- 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.
by adrian_m - 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.
by ketozhang - 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 nameby wolttam
- Companies got to release an MCP server for their product and tell their investors they were pivoting to be AI native.by mikeocool
- 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.
- 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.
by preommr - 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/by MikhailTal
- 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.
by notatoad - 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."
by izend - 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.by aliasxneo
- 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?by huksley
- 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?
by gz5