7 ms·

MCP Specification – version 2025-06-18 changes

200 points by owebmaster 1y ago

Aeolun 1y ago
Funny that changes to the spec require a single approval before being merged xD
dend 1y ago
I am just glad that we now have a simple path to authorized MCP servers. Massive shout-out to the MCP community and folks at Anthropic for corralling all the changes here.
- seanobannon 1y ago
  Completely agree - and yet auth is still surprisingly difficult to set up, so I built a library to simplify the setup. In this repo, there is: - a Typescript library to set up ChatGPT-MCP compatible auth - Source code for an Express & NextJS project implementing the library - a URL for the demo of the deployed NextJS app that logs ChatGPT tool calls Should be helpful for folks trying to set up and distribute custom connectors. https://github.com/mcpauth/mcpauth https://github.com/mcpauth/mcpauth
- jjfoooo4 1y ago
  What is the point of a MCP server? If you want to make an RPC from an agent, why not... just use an RPC?
  - refulgentis 1y ago
    Not everyone can code, and not everyone who can code is allowed to write code against the resources I have.
    - nsonha 1y ago
      you have to write code for MCP server, and code to consume them too. It's just the LLM vendor decide that they are going to have the consume side built-in, which people question as they could as well do the same for open API, GRPC and what not, instead of a completely new thing.
  - antupis 1y ago
    It is easier to communicate and sell that we have this MCP server that you can just plug and play vs some custom RPC stuff.
    - freeone3000 1y ago
      But MCP deliberately doesn’t define endpoints, or arguments, or return types… it is the definition of custom RPC stuff. How does it differ from providing a non MCP REST API?
      - hobofan 1y ago
        The main alternative one would have for having a plug-and-play (just configure a single URL) non-MCP REST API would be to use OpenAPI definitions and ingesting them accordingly. However, as someone that has tried to use OpenAPI for that in the past (both via OpenAI's "Custom GPT"s and auto-converting OpenAPI specifications to a list of tools), in my experience almost every existing OpenAPI spec out there is insufficient as a basis for tool calling in one way or another: - Largely insufficient documentation on the endpoints themselves - REST is too open to interpretation, and without operationIds (which almost nobody in the wild defines), there is usually context missing on what "action" is being triggered by POST/PUT/DELETE endpoints (e.g. many APIs do a delete of a resource via a POST or PUT, and some APIs use DELETE to archive resources) - baseUrls are often wrong/broken and assumed to be replaced by the API client - underdocumented AuthZ/AuthN mechanisms (usually only present in the general description comment on the API, and missing on the individual endpoints) In practice you often have to remedy that by patching the officially distributed OpenAPI specs to make them good enough for a basis of tool calling, making it not-very-plug-and-play. I think the biggest upside that MCP brings (given all "content"/"functionality") being equal is that using it instead of just plain REST, is that it acts as a badge that says "we had AI usage in mind when building this". On top of that, MCP also standardizes mechanisms like e.g. elicitation that with traditional REST APIs are completely up to the client to implement.
        ethbr1 1y ago
        REST for all the use cases: We have successfully agreed on what words to use! We just disagree on what they mean.
  - dend 1y ago
    The analogy that was used a lot is that it's essentially USB-C for your data being connected to LLMs. You don't need to fight 4,532,529 standards - there is one (yes, I am familiar with the XKCD comic). As long as your client is MCP-compatible, it can work with _any_ MCP server.
    - fennecfoxy 1y ago
      The whole USB C comparison they make is eyeroll inducing, imo. All they needed to state was that it was a specification for function calling. My gripe is that they had the opportunity to spec out tool use in models and they did not. The client->llm implementation is up to the implementor and many models differ with different tags like <|python_call|> etc.
      - lsaferite 1y ago
        Clearly they need to try explaining it it easy terms. The number of people that cannot or will not understand the protocol is mind boggling. I'm with you on an Agent -> LLM industry standard spec need. The APIs are all over the place and it's frustrating. If there was a spec for that, then agent development becomes simply focused on the business logic and the LLM and the Tools/Resource are just standardized components you plug together like Lego. I've basically done that for our internal agent development. I have a Universal LLM API that everything uses. It's helped a lot.
        ethbr1 1y ago
        The comparison to USB C is valid, given the variety of unmarked support from cable to cable and port to port. It has the physical plug, but what can it actually do? It would be nice to see a standard aiming for better UX than USB C. (Imho they should have used colored micro dots on device and cable connector to physically declare capabilities)
        fennecfoxy 1y ago
        Certainly valid in that just like various usb c cables supporting slightly different data rates or power capacities, MCP doesn't deal with my aforementioned issue of the glue between MCP client and model you've chosen; that exercise is left up to us still.
  - vidarh 1y ago
    MCP is an RPC protocol.
  - fennecfoxy 1y ago
    Standardising tool use, I suppose. Not sure why people treat MCP like it's much more than smashing tool descriptions together and concatenating to the prompt, but here we are. It is nice to have a standard definition of tools that models can be trained/fine tuned for, though.
    - ethbr1 1y ago
      Also nice to have a standard(ish) for evolution purposes. I.e. +15 years from now.
      - lobsterthief 1y ago
        Agreed. Without standards, we wouldn’t have the rich web-based ecosystem we have now. As an example, anyone who’s coded email templates will tell you: it’s hard. While the major browsers adopted the W3C specs, email clients (I.e. email renderers) never adopted the spec, or such a W3C email HTML spec didn’t exist. So something that renders correctly in Gmail looks broken in Yahoo mail in Safari on iOS, etc.
        fennecfoxy 1y ago
        Standards are very important, especially extensible ones where proposals are adopted when they make sense - this means companies can still innovate but users get the benefit of everything just working. But browsers/web ecosystem are still a bad example as we had decades of browsers supporting their own particular features/extensions. This has converged slightly pretty much because everything now uses Chrome underneath (bar Safari and Firefox). But even so...if I write an extension while using Firefox, why can't I install that extension in Chrome? And vice-versa? Even bookmarks are stored in slightly different formats. It is a massive pain to align technology like this but the benefits are huge. Like boxing developers in with a good library (to stop them from doing arbitrary custom per-project BS) I think all software needs to be boxed into standards with provisions for extension/innovation. Rather than this pick & choose BS because muh lock-in.
  - rco8786 1y ago
    Standardization. You spin up a server that conforms to MCP, every LLM instantly knows how to use it.
TOMDM 1y ago
Maybe the Key Changes page would be a better link if we're concerned with a specific version? https://modelcontextprotocol.io/specification/2025-06-18/changelog https://modelcontextprotocol.io/specification/2025-06-18/cha...
- lyjackal 1y ago
  Agree, thanks for the link. I was wondering what actually changed. The resource links and elicitation look like useful functionality.
- tomhow 1y ago
  OK we've changed the URL and the title to that, thanks!
elliotbnvl 1y ago
Fascinated to see that the core spec is written in TypeScript and not, say, an OpenAPI spec or something. I suppose it makes sense, but it’s still surprising to see.
- lovich 1y ago
  Why is it surprising? I use typescript a lot, but I would have never even thought to have this insight so I am missing some language design decisions
  - fnordpiglet 1y ago
    Because type script is a language not a language agnostic specification for languages. As someone who uses typescript a lot that probably is irrelevant. But if I’m using Rust, say, then the typescript means I need to reimplement the spec from scratch. With OpenApi, say, I can code generate canonically correct stubs and implement from there.
    - pattobrien 1y ago
      There's an OpenAPI spec generated from the Typescript schemas in the official spec repo, so codegen of other SDKs is still possible.
_feus 1y ago
What MCP is missing is a reasonable way to do async callbacks where you can have the mcp query the model with a custom prompt and results of some operation.
- lherron 1y ago
  Isn't this what sampling is for? https://modelcontextprotocol.io/docs/concepts/sampling https://modelcontextprotocol.io/docs/concepts/sampling
  - lsaferite 1y ago
    That was my thought as well. My main disappointment with sampling right now is the very limited scope. It'd be nice to support some universal tool calling syntax or something. Otherwise a reasonably complicated MCP Server is still going to need a direct LLM connect.
    - refulgentis 1y ago
      Dumb question: in that case, wouldn't it not be an MCP server? It would be an LLM client with the ability to execute tool calls made by the LLM? I don't get how MCP could create a wrapper for all possible LLM inference APIs or why it'd be desirable (that's an awful long leash for me to give out on my API key)
      - lsaferite 1y ago
        An MCP Server can be many things. It can be as simple as an echo server or as complex as a full-blown tool-calling agent and beyond. The MCP Client Sampling feature is an interesting thing that's designed to allow the primary agent, the MCP Host, to offer up some subset of LLM models that is has access to for the MCP Servers it connects with. That would allow the MCP Server to make LLM calls that are mediated (or not, YMMV) by the MCP Host. As I said above, the feature is very limited right now, but still interesting for some simpler use cases. Why would you do this? So you don't have to configure every MCP Server you use with LLM credentials? And the particulars of exactly what model gets used are under your control. That allows the MCP Server to worry about the business logic and not about how to talk to a specific LLM Provider.
jjfoooo4 1y ago
It's very hard for me to understand what MCP solves aside from providing a quick and dirty way to prototype something on my laptop. If I'm building a local program, I am going to want tighter control over the toolsets my LLM calls have access to. E.g. an MCP server for Google Calendar. MCP is not saving me significant time - I can access the same API's the MCP can. I probably need to carefully instruct the LLM on when and how to use the Google Calendar calls, and I don't want to delegate that to a third party. I also do not want to spin up a bunch of arbitrary processes in whatever runtime environment the MCP is written in. If I'm writing in Python, why do I want my users to have to set up a typescript runtime? God help me if there's a security issue in the MCP wrapper for language_foo. On the server, things get even more difficult to justify. We have a great tool for having one machine call a process hosted on another machine without knowing it's implementation details: the RPC. MCP just adds a bunch of opinionated middleware (and security holes)
- refulgentis 1y ago
  I agree vehemently, I'm sort of stunned how...slow...things are in practice. I quit my job 2 years ago to do LLM client stuff and I still haven't made it to Google calendar. It's handy as a user to have something to plug holes in the interim. In the limit, I remember some old saw about how every had the same top 3 rows of apps on their iPhone homescreen, but the last row was all different. I bet IT will be managing, and dev teams will make, their own bespoke MCP servers for years to come.
  - throwaway314155 1y ago
    If I understand your point correctly - the main bottleneck for tool-calling/MCP is the models themselves being relatively terrible at tool-calling anything but the tools they were finetuned to work with until recently. Even with the latest developments, any given MCP server has a variable chance of success just due to the nature of LLM's only learning the most common downstream tasks. Further, LLM's _still_ struggle when you give them too many tools to call. They're poor at assessing the correct tool to use when given tools with overlapping functionality or similar function name/args. This is what people mean when they say that MCP should maybe wait for a better LLM before going all-in on this design.
eadmund 1y ago
It is mostly pointless complexity, but I’m going to miss batching. It was kind of neat to be able to say ‘do all these things, then respond,’ even if the client can batch the responses itself if it wants to.
- lsaferite 1y ago
  I agree. JSON-RPC batching has always been my "gee, that's neat" feature and seeing it removed from the spec is sad. But, as you said, it's mostly just adding complexity.
curtisszmania 1y ago
[dead]
neya 1y ago
One of the biggest lessons for me while riding the MCP hype was that if you're writing backend software, you don't actually need to do MCP. Architecturally, they don't make sense. Atleast not on Elixir anyway. One server per API? That actually sounds crazy if you're doing backend. That's 500 different microservices for 500 APIs. After working with 20 different MCP servers, it then finally dawned on me, good ole' function calling (which is what MCP is under the hood) works just fine. And each API can be just it's own module instead of a server. So, no need to keep yourself updated on the latest MCP spec nor need to update 100s of microservices because the spec changed. Needless complexity.
- aryehof 1y ago
  It really is a standard protocol for connecting clients to models and vice versa. It’s not there to just be a container for tool calls.
  - deleted 1y ago
    [deleted]
- leonidasv 1y ago
  I always saw MCPs as a plug-and-play integration for enabling function calling without incurring API costs when using Claude. If you're using the API and not in a hurry, there's no need for it.
- throwaway314155 1y ago
  > One server per API? That actually sounds crazy if you're doing backend Not familiar with elixir, but is there anything prohibiting you from just making a monolith MCP combining multiple disparate API's/backends/microservices as you were doing previously? Further, you won't get the various client-application integrations with MCP merely using tool-calling; which to me is the "killer app" of MCP (as a sibling comment touches on). (I do still have mixed feelings about MCP, but in this case MCP sorta wins for me)
  - neya 1y ago
gotts 1y ago
Very glad to see MCP Specification rapid improvement. With each new release I notice something that I was missing in my MCP integrations.
swalsh 1y ago
Elicitation is a big win. One of my favorite MCP servers is an SSH server I built, it allows me to basically automate 90% of the server tasks I need done. I handled authentication via a config file, but it's kind of a pain to manage if I want to access a new server.
- surfingdino 1y ago
  There's always https://www.fabfile.org/ https://www.fabfile.org/ no need to throw an LLM into a conversation that is best kept private.
  - dig1 1y ago
    Ansible, puppet, chef, salt, cfengine... There are tons of tools that are more precise and succinct for describing sensitive tasks, such as managing a single or a fleet of remote servers. Using MCP/LLMs for this is... :O
    - ethbr1 1y ago
      ... the future? There are security / reliability concerns, true, but finally getting technically close to Star Trek computers and then still doing things 'the way they've always been done' doesn't seem efficient.
  - swalsh 1y ago
    I don't know if you understand the role the LLM is playing here. The mechanism used to execute the command is not the relevant thing. The LLM autonomously executing commands has intelligence, it's not just a shell script. If I ask it to do a task, and it runs into an issue... LLMs like Claude can recognize the problem, and find a way to resolve it. Script failed because of a missing dependency, it'll install it. Need a config change, it'll do it. The SSH mcp is just the interface for the LLM to do the work. You can give an LLM a github repo link, a fresh VPC, and say "deploy my app using nginx" and any other details you need... and it'll get it done.
troupo 1y ago
They keep inventing new terms for things. This time it's "Elicitation" for user input.
- spiritplumber 1y ago
  We need to work CLU and TRON in there too, then!
- lsaferite 1y ago
  What would you have preferred it to be called? > n. the process of getting or producing something, especially information or a reaction Now, Sampling seems like an odd feature name to me, but maybe I'm missing the driver behind that name.
  - troupo 1y ago
    > What would you have preferred it to be called? It's right there in my comment. You don't need to call user input "elicitation" just to pretend it's something it's not. Same goes for sampling.
    - esafak 1y ago
      That one's even more egregious, coming from a field where statistics is central.
surfingdino 1y ago
> structured tool output Yeah, let's pretend it works. So far structured output from an LLM is an exercise in programmers' ability to code defensively against responses that may or may not be valid JSON, may not conform to the schema, or may just be null. There's a new cottage industry of modules that automate dealing with this crap.
- sanxiyn 1y ago
  No? With structured outputs you get valid JSON 100% of the time. This is a non-problem now. (If you understand how it works, it really can't be otherwise.) https://openai.com/index/introducing-structured-outputs-in-the-api/ https://openai.com/index/introducing-structured-outputs-in-t... https://platform.openai.com/docs/guides/structured-outputs https://platform.openai.com/docs/guides/structured-outputs
  - OtherShrezzing 1y ago
    From the 2nd link: > Structured Outputs can still contain mistakes. The guarantee promised in link 1 is not supported by the documentation in link 2. Structured Output does a _very good_ job, but still sometimes messes up. When you’re trying to parse hundreds of thousands of documents per day, you need a lot of 9s of reliability before you can earnestly say “100% guarantee” of accuracy.
  - hobofan 1y ago
    Whether it's a non-problem or not very much depends on how much the LLM API providers actually bother to add enforcement server-side. Anecdotally, I've seen Azure OpenAI services hallucinate tools just last week, when I provided an empty array of tools rather than not providing the tools key at all (silly me!). Up until that point I would have assumed that there are server-side safeguards against that, but now I have to consider spending time on adding client-side checks for all kinds of bugs in that area.
  - fooster 1y ago
    Have you actually used this stuff at scale? The replies are often not valid.
fennecfoxy 1y ago
Did they fix evil MCP servers/prompt injection/data exfiltration yet?
- noodletheworld 1y ago
  No. That (prompt injection) isn’t something you can fix until you come up with a way to split prompts. That means new types models; there is no variant on MCP that can solve it with existing models.
  - ethbr1 1y ago
    It's hilarious how LLMs are relearning the idea that it might be a good idea to carry control signals out of band. I guess the phone phreak generation wasn't around to say 'Maybe this is a bad idea...' (because the first thing users are going to do is try to hijack control via in band overrides)
whazor 1y ago
It would make sense to have a 'resource update/delete' approval workflow, where a MCP server can have an o-auth link just to approve the particular step.
- zackify 1y ago
  Yeah unfortunately doesn’t exist yet and it’s an open issue
disintegrator 1y ago
The introduction of WWW-Authenticate challenge is so welcome. Now it's much clearer that the MCP server can punt the client to resource provider's OAuth flow and sit back waiting for an `Authorization: Bearer ...`.
practal 1y ago
Does any popular MCP host support sampling by now?
- evalstate 1y ago
  Yes. VSCode 1.101.0 does, as well as fast-agent. Earlier I posted about mcp-webcam (you can find it) which gives you a no-install way to try out Sampling if you like.
martinald 1y ago
I spent the last few days playing with MCP building some wrappers for some datasets. My thoughts: 1) Probably the coolest thing to happen with LLMs. While you could do all this with tool calling and APIs, being able to send to less technical friends a MCP URL for claude and seeing them get going with it in a few clicks is amazing. 2) I'm using the csharp SDK, which only has auth in a branch - so very bleeding edge. Had a lot of problems with implementing that - 95% of my time was spent on auth (which is required for claude MCP integrations if you are not building locally). I'm sure this will get easier with docs but it's pretty involved. 3) Related to that, Claude doesn't AFIAK expose much in terms of developer logs for what they are sending via their web (not desktop) app and what is going wrong. Would be super helpful to have a developer mode where it showed you request/response of errors. I had real problems with refresh on auth and it turned out I was logging the wrong endpoint on my side. Operator error for sure but would have fixed that in a couple of mins had they had better MCP logging somewhere in the webui. It all worked fine with stdio in desktop and MCP inspector. 4) My main question/issue is handling longer running tasks. The dataset I'm exposing is effectively a load of PDF documents as I can't get claude to handle the PDF files itself (I am all ears if there is a way!). What I'm currently doing is sending them through gemini to get the text, then sending that to the user via MCP. This works fine for short/simple documents, but for longer length documents (which can take some time to process) I return a message saying it is processing and to retry later. While I'm aware there is a progress API, it still requires keeping the connection open to the server (which times out after a while with Cloudflare at least) - could be wrong here though?. It would be much better to be able to tell the LLM to check back in x seconds when you predict it will be done and the LLM can do other stuff in the background (which it will do), but then sorta 'pause execution' until the timer is hit. Right now (AFIAK!) you can either keep it waiting (which means it can't do anything else in the meantime) with an open connection w/ progress, or you can return a job ID, but then it will just return a half finished answer which is often misleading as it doesn't have all the context yet. Don't know if this makes any sense, but I can imagine this being a real pain for tasks that take 10mins+.
- jonathanhefner 1y ago
  Long-running tasks are an open topic of discussion, and I think MCP intends to address it in the future. There are a few proposals floating around, but one issue is that you don't always know whether a task will be long-running, so having separate APIs for long-running tasks vs "regular" tool calls doesn't fully address the problem. I've written a proposal to solve the problem in a more holistic way: https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/543 https://github.com/modelcontextprotocol/modelcontextprotocol...
dgellow 1y ago
Oh nice! I know what to do over the weekend: I will be updating my mcp oauth proxy :D

200 points by owebmaster 1y ago

Funny that changes to the spec require a single approval before being merged xD

dend 1y ago

I am just glad that we now have a simple path to authorized MCP servers. Massive shout-out to the MCP community and folks at Anthropic for corralling all the changes here.

seanobannon 1y ago
Completely agree - and yet auth is still surprisingly difficult to set up, so I built a library to simplify the setup. In this repo, there is: - a Typescript library to set up ChatGPT-MCP compatible auth - Source code for an Express & NextJS project implementing the library - a URL for the demo of the deployed NextJS app that logs ChatGPT tool calls Should be helpful for folks trying to set up and distribute custom connectors. https://github.com/mcpauth/mcpauth https://github.com/mcpauth/mcpauth
jjfoooo4 1y ago
What is the point of a MCP server? If you want to make an RPC from an agent, why not... just use an RPC?
- refulgentis 1y ago
  Not everyone can code, and not everyone who can code is allowed to write code against the resources I have.
  - nsonha 1y ago
    you have to write code for MCP server, and code to consume them too. It's just the LLM vendor decide that they are going to have the consume side built-in, which people question as they could as well do the same for open API, GRPC and what not, instead of a completely new thing.
- antupis 1y ago
  It is easier to communicate and sell that we have this MCP server that you can just plug and play vs some custom RPC stuff.
  - freeone3000 1y ago
    But MCP deliberately doesn’t define endpoints, or arguments, or return types… it is the definition of custom RPC stuff. How does it differ from providing a non MCP REST API?
    - hobofan 1y ago
      The main alternative one would have for having a plug-and-play (just configure a single URL) non-MCP REST API would be to use OpenAPI definitions and ingesting them accordingly. However, as someone that has tried to use OpenAPI for that in the past (both via OpenAI's "Custom GPT"s and auto-converting OpenAPI specifications to a list of tools), in my experience almost every existing OpenAPI spec out there is insufficient as a basis for tool calling in one way or another: - Largely insufficient documentation on the endpoints themselves - REST is too open to interpretation, and without operationIds (which almost nobody in the wild defines), there is usually context missing on what "action" is being triggered by POST/PUT/DELETE endpoints (e.g. many APIs do a delete of a resource via a POST or PUT, and some APIs use DELETE to archive resources) - baseUrls are often wrong/broken and assumed to be replaced by the API client - underdocumented AuthZ/AuthN mechanisms (usually only present in the general description comment on the API, and missing on the individual endpoints) In practice you often have to remedy that by patching the officially distributed OpenAPI specs to make them good enough for a basis of tool calling, making it not-very-plug-and-play. I think the biggest upside that MCP brings (given all "content"/"functionality") being equal is that using it instead of just plain REST, is that it acts as a badge that says "we had AI usage in mind when building this". On top of that, MCP also standardizes mechanisms like e.g. elicitation that with traditional REST APIs are completely up to the client to implement.
      - ethbr1 1y ago
        REST for all the use cases: We have successfully agreed on what words to use! We just disagree on what they mean.
- dend 1y ago
  The analogy that was used a lot is that it's essentially USB-C for your data being connected to LLMs. You don't need to fight 4,532,529 standards - there is one (yes, I am familiar with the XKCD comic). As long as your client is MCP-compatible, it can work with _any_ MCP server.
  - fennecfoxy 1y ago
    The whole USB C comparison they make is eyeroll inducing, imo. All they needed to state was that it was a specification for function calling. My gripe is that they had the opportunity to spec out tool use in models and they did not. The client->llm implementation is up to the implementor and many models differ with different tags like <|python_call|> etc.
    - lsaferite 1y ago
      Clearly they need to try explaining it it easy terms. The number of people that cannot or will not understand the protocol is mind boggling. I'm with you on an Agent -> LLM industry standard spec need. The APIs are all over the place and it's frustrating. If there was a spec for that, then agent development becomes simply focused on the business logic and the LLM and the Tools/Resource are just standardized components you plug together like Lego. I've basically done that for our internal agent development. I have a Universal LLM API that everything uses. It's helped a lot.
      - ethbr1 1y ago
        The comparison to USB C is valid, given the variety of unmarked support from cable to cable and port to port. It has the physical plug, but what can it actually do? It would be nice to see a standard aiming for better UX than USB C. (Imho they should have used colored micro dots on device and cable connector to physically declare capabilities)
        fennecfoxy 1y ago
        Certainly valid in that just like various usb c cables supporting slightly different data rates or power capacities, MCP doesn't deal with my aforementioned issue of the glue between MCP client and model you've chosen; that exercise is left up to us still.
- vidarh 1y ago
  MCP is an RPC protocol.
- fennecfoxy 1y ago
  Standardising tool use, I suppose. Not sure why people treat MCP like it's much more than smashing tool descriptions together and concatenating to the prompt, but here we are. It is nice to have a standard definition of tools that models can be trained/fine tuned for, though.
  - ethbr1 1y ago
    Also nice to have a standard(ish) for evolution purposes. I.e. +15 years from now.
    - lobsterthief 1y ago
      Agreed. Without standards, we wouldn’t have the rich web-based ecosystem we have now. As an example, anyone who’s coded email templates will tell you: it’s hard. While the major browsers adopted the W3C specs, email clients (I.e. email renderers) never adopted the spec, or such a W3C email HTML spec didn’t exist. So something that renders correctly in Gmail looks broken in Yahoo mail in Safari on iOS, etc.
      - fennecfoxy 1y ago
        Standards are very important, especially extensible ones where proposals are adopted when they make sense - this means companies can still innovate but users get the benefit of everything just working. But browsers/web ecosystem are still a bad example as we had decades of browsers supporting their own particular features/extensions. This has converged slightly pretty much because everything now uses Chrome underneath (bar Safari and Firefox). But even so...if I write an extension while using Firefox, why can't I install that extension in Chrome? And vice-versa? Even bookmarks are stored in slightly different formats. It is a massive pain to align technology like this but the benefits are huge. Like boxing developers in with a good library (to stop them from doing arbitrary custom per-project BS) I think all software needs to be boxed into standards with provisions for extension/innovation. Rather than this pick & choose BS because muh lock-in.
- rco8786 1y ago
  Standardization. You spin up a server that conforms to MCP, every LLM instantly knows how to use it.

TOMDM 1y ago

Maybe the Key Changes page would be a better link if we're concerned with a specific version? https://modelcontextprotocol.io/specification/2025-06-18/changelog https://modelcontextprotocol.io/specification/2025-06-18/cha...

lyjackal 1y ago
Agree, thanks for the link. I was wondering what actually changed. The resource links and elicitation look like useful functionality.
tomhow 1y ago
OK we've changed the URL and the title to that, thanks!

elliotbnvl 1y ago

Fascinated to see that the core spec is written in TypeScript and not, say, an OpenAPI spec or something. I suppose it makes sense, but it’s still surprising to see.

lovich 1y ago
Why is it surprising? I use typescript a lot, but I would have never even thought to have this insight so I am missing some language design decisions
- fnordpiglet 1y ago
  Because type script is a language not a language agnostic specification for languages. As someone who uses typescript a lot that probably is irrelevant. But if I’m using Rust, say, then the typescript means I need to reimplement the spec from scratch. With OpenApi, say, I can code generate canonically correct stubs and implement from there.
  - pattobrien 1y ago
    There's an OpenAPI spec generated from the Typescript schemas in the official spec repo, so codegen of other SDKs is still possible.

_feus 1y ago

What MCP is missing is a reasonable way to do async callbacks where you can have the mcp query the model with a custom prompt and results of some operation.

lherron 1y ago
Isn't this what sampling is for? https://modelcontextprotocol.io/docs/concepts/sampling https://modelcontextprotocol.io/docs/concepts/sampling
- lsaferite 1y ago
  That was my thought as well. My main disappointment with sampling right now is the very limited scope. It'd be nice to support some universal tool calling syntax or something. Otherwise a reasonably complicated MCP Server is still going to need a direct LLM connect.
  - refulgentis 1y ago
    Dumb question: in that case, wouldn't it not be an MCP server? It would be an LLM client with the ability to execute tool calls made by the LLM? I don't get how MCP could create a wrapper for all possible LLM inference APIs or why it'd be desirable (that's an awful long leash for me to give out on my API key)
    - lsaferite 1y ago
      An MCP Server can be many things. It can be as simple as an echo server or as complex as a full-blown tool-calling agent and beyond. The MCP Client Sampling feature is an interesting thing that's designed to allow the primary agent, the MCP Host, to offer up some subset of LLM models that is has access to for the MCP Servers it connects with. That would allow the MCP Server to make LLM calls that are mediated (or not, YMMV) by the MCP Host. As I said above, the feature is very limited right now, but still interesting for some simpler use cases. Why would you do this? So you don't have to configure every MCP Server you use with LLM credentials? And the particulars of exactly what model gets used are under your control. That allows the MCP Server to worry about the business logic and not about how to talk to a specific LLM Provider.

jjfoooo4 1y ago

It's very hard for me to understand what MCP solves aside from providing a quick and dirty way to prototype something on my laptop. If I'm building a local program, I am going to want tighter control over the toolsets my LLM calls have access to. E.g. an MCP server for Google Calendar. MCP is not saving me significant time - I can access the same API's the MCP can. I probably need to carefully instruct the LLM on when and how to use the Google Calendar calls, and I don't want to delegate that to a third party. I also do not want to spin up a bunch of arbitrary processes in whatever runtime environment the MCP is written in. If I'm writing in Python, why do I want my users to have to set up a typescript runtime? God help me if there's a security issue in the MCP wrapper for language_foo. On the server, things get even more difficult to justify. We have a great tool for having one machine call a process hosted on another machine without knowing it's implementation details: the RPC. MCP just adds a bunch of opinionated middleware (and security holes)

refulgentis 1y ago
I agree vehemently, I'm sort of stunned how...slow...things are in practice. I quit my job 2 years ago to do LLM client stuff and I still haven't made it to Google calendar. It's handy as a user to have something to plug holes in the interim. In the limit, I remember some old saw about how every had the same top 3 rows of apps on their iPhone homescreen, but the last row was all different. I bet IT will be managing, and dev teams will make, their own bespoke MCP servers for years to come.
- throwaway314155 1y ago
  If I understand your point correctly - the main bottleneck for tool-calling/MCP is the models themselves being relatively terrible at tool-calling anything but the tools they were finetuned to work with until recently. Even with the latest developments, any given MCP server has a variable chance of success just due to the nature of LLM's only learning the most common downstream tasks. Further, LLM's _still_ struggle when you give them too many tools to call. They're poor at assessing the correct tool to use when given tools with overlapping functionality or similar function name/args. This is what people mean when they say that MCP should maybe wait for a better LLM before going all-in on this design.

eadmund 1y ago

It is mostly pointless complexity, but I’m going to miss batching. It was kind of neat to be able to say ‘do all these things, then respond,’ even if the client can batch the responses itself if it wants to.

lsaferite 1y ago
I agree. JSON-RPC batching has always been my "gee, that's neat" feature and seeing it removed from the spec is sad. But, as you said, it's mostly just adding complexity.

curtisszmania 1y ago

[dead]

neya 1y ago

One of the biggest lessons for me while riding the MCP hype was that if you're writing backend software, you don't actually need to do MCP. Architecturally, they don't make sense. Atleast not on Elixir anyway. One server per API? That actually sounds crazy if you're doing backend. That's 500 different microservices for 500 APIs. After working with 20 different MCP servers, it then finally dawned on me, good ole' function calling (which is what MCP is under the hood) works just fine. And each API can be just it's own module instead of a server. So, no need to keep yourself updated on the latest MCP spec nor need to update 100s of microservices because the spec changed. Needless complexity.

aryehof 1y ago
It really is a standard protocol for connecting clients to models and vice versa. It’s not there to just be a container for tool calls.
- deleted 1y ago
  [deleted]
leonidasv 1y ago
I always saw MCPs as a plug-and-play integration for enabling function calling without incurring API costs when using Claude. If you're using the API and not in a hurry, there's no need for it.
throwaway314155 1y ago
> One server per API? That actually sounds crazy if you're doing backend Not familiar with elixir, but is there anything prohibiting you from just making a monolith MCP combining multiple disparate API's/backends/microservices as you were doing previously? Further, you won't get the various client-application integrations with MCP merely using tool-calling; which to me is the "killer app" of MCP (as a sibling comment touches on). (I do still have mixed feelings about MCP, but in this case MCP sorta wins for me)
- neya 1y ago

gotts 1y ago

Very glad to see MCP Specification rapid improvement. With each new release I notice something that I was missing in my MCP integrations.

swalsh 1y ago

Elicitation is a big win. One of my favorite MCP servers is an SSH server I built, it allows me to basically automate 90% of the server tasks I need done. I handled authentication via a config file, but it's kind of a pain to manage if I want to access a new server.

surfingdino 1y ago
There's always https://www.fabfile.org/ https://www.fabfile.org/ no need to throw an LLM into a conversation that is best kept private.
- dig1 1y ago
  Ansible, puppet, chef, salt, cfengine... There are tons of tools that are more precise and succinct for describing sensitive tasks, such as managing a single or a fleet of remote servers. Using MCP/LLMs for this is... :O
  - ethbr1 1y ago
    ... the future? There are security / reliability concerns, true, but finally getting technically close to Star Trek computers and then still doing things 'the way they've always been done' doesn't seem efficient.
- swalsh 1y ago
  I don't know if you understand the role the LLM is playing here. The mechanism used to execute the command is not the relevant thing. The LLM autonomously executing commands has intelligence, it's not just a shell script. If I ask it to do a task, and it runs into an issue... LLMs like Claude can recognize the problem, and find a way to resolve it. Script failed because of a missing dependency, it'll install it. Need a config change, it'll do it. The SSH mcp is just the interface for the LLM to do the work. You can give an LLM a github repo link, a fresh VPC, and say "deploy my app using nginx" and any other details you need... and it'll get it done.

troupo 1y ago

They keep inventing new terms for things. This time it's "Elicitation" for user input.

spiritplumber 1y ago
We need to work CLU and TRON in there too, then!
lsaferite 1y ago
What would you have preferred it to be called? > n. the process of getting or producing something, especially information or a reaction Now, Sampling seems like an odd feature name to me, but maybe I'm missing the driver behind that name.
- troupo 1y ago
  > What would you have preferred it to be called? It's right there in my comment. You don't need to call user input "elicitation" just to pretend it's something it's not. Same goes for sampling.
  - esafak 1y ago
    That one's even more egregious, coming from a field where statistics is central.

surfingdino 1y ago

> structured tool output Yeah, let's pretend it works. So far structured output from an LLM is an exercise in programmers' ability to code defensively against responses that may or may not be valid JSON, may not conform to the schema, or may just be null. There's a new cottage industry of modules that automate dealing with this crap.

sanxiyn 1y ago
No? With structured outputs you get valid JSON 100% of the time. This is a non-problem now. (If you understand how it works, it really can't be otherwise.) https://openai.com/index/introducing-structured-outputs-in-the-api/ https://openai.com/index/introducing-structured-outputs-in-t... https://platform.openai.com/docs/guides/structured-outputs https://platform.openai.com/docs/guides/structured-outputs
- OtherShrezzing 1y ago
  From the 2nd link: > Structured Outputs can still contain mistakes. The guarantee promised in link 1 is not supported by the documentation in link 2. Structured Output does a _very good_ job, but still sometimes messes up. When you’re trying to parse hundreds of thousands of documents per day, you need a lot of 9s of reliability before you can earnestly say “100% guarantee” of accuracy.
- hobofan 1y ago
  Whether it's a non-problem or not very much depends on how much the LLM API providers actually bother to add enforcement server-side. Anecdotally, I've seen Azure OpenAI services hallucinate tools just last week, when I provided an empty array of tools rather than not providing the tools key at all (silly me!). Up until that point I would have assumed that there are server-side safeguards against that, but now I have to consider spending time on adding client-side checks for all kinds of bugs in that area.
- fooster 1y ago
  Have you actually used this stuff at scale? The replies are often not valid.

fennecfoxy 1y ago

Did they fix evil MCP servers/prompt injection/data exfiltration yet?

noodletheworld 1y ago
No. That (prompt injection) isn’t something you can fix until you come up with a way to split prompts. That means new types models; there is no variant on MCP that can solve it with existing models.
- ethbr1 1y ago
  It's hilarious how LLMs are relearning the idea that it might be a good idea to carry control signals out of band. I guess the phone phreak generation wasn't around to say 'Maybe this is a bad idea...' (because the first thing users are going to do is try to hijack control via in band overrides)

whazor 1y ago

It would make sense to have a 'resource update/delete' approval workflow, where a MCP server can have an o-auth link just to approve the particular step.

zackify 1y ago
Yeah unfortunately doesn’t exist yet and it’s an open issue

disintegrator 1y ago

The introduction of WWW-Authenticate challenge is so welcome. Now it's much clearer that the MCP server can punt the client to resource provider's OAuth flow and sit back waiting for an `Authorization: Bearer ...`.

practal 1y ago

Does any popular MCP host support sampling by now?

evalstate 1y ago
Yes. VSCode 1.101.0 does, as well as fast-agent. Earlier I posted about mcp-webcam (you can find it) which gives you a no-install way to try out Sampling if you like.

martinald 1y ago

I spent the last few days playing with MCP building some wrappers for some datasets. My thoughts: 1) Probably the coolest thing to happen with LLMs. While you could do all this with tool calling and APIs, being able to send to less technical friends a MCP URL for claude and seeing them get going with it in a few clicks is amazing. 2) I'm using the csharp SDK, which only has auth in a branch - so very bleeding edge. Had a lot of problems with implementing that - 95% of my time was spent on auth (which is required for claude MCP integrations if you are not building locally). I'm sure this will get easier with docs but it's pretty involved. 3) Related to that, Claude doesn't AFIAK expose much in terms of developer logs for what they are sending via their web (not desktop) app and what is going wrong. Would be super helpful to have a developer mode where it showed you request/response of errors. I had real problems with refresh on auth and it turned out I was logging the wrong endpoint on my side. Operator error for sure but would have fixed that in a couple of mins had they had better MCP logging somewhere in the webui. It all worked fine with stdio in desktop and MCP inspector. 4) My main question/issue is handling longer running tasks. The dataset I'm exposing is effectively a load of PDF documents as I can't get claude to handle the PDF files itself (I am all ears if there is a way!). What I'm currently doing is sending them through gemini to get the text, then sending that to the user via MCP. This works fine for short/simple documents, but for longer length documents (which can take some time to process) I return a message saying it is processing and to retry later. While I'm aware there is a progress API, it still requires keeping the connection open to the server (which times out after a while with Cloudflare at least) - could be wrong here though?. It would be much better to be able to tell the LLM to check back in x seconds when you predict it will be done and the LLM can do other stuff in the background (which it will do), but then sorta 'pause execution' until the timer is hit. Right now (AFIAK!) you can either keep it waiting (which means it can't do anything else in the meantime) with an open connection w/ progress, or you can return a job ID, but then it will just return a half finished answer which is often misleading as it doesn't have all the context yet. Don't know if this makes any sense, but I can imagine this being a real pain for tasks that take 10mins+.

jonathanhefner 1y ago
Long-running tasks are an open topic of discussion, and I think MCP intends to address it in the future. There are a few proposals floating around, but one issue is that you don't always know whether a task will be long-running, so having separate APIs for long-running tasks vs "regular" tool calls doesn't fully address the problem. I've written a proposal to solve the problem in a more holistic way: https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/543 https://github.com/modelcontextprotocol/modelcontextprotocol...

dgellow 1y ago

Oh nice! I know what to do over the weekend: I will be updating my mcp oauth proxy :D