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 · 9m 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.
dend · 1h 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.
jjfoooo4 · 36m 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 · 23m ago
Not everyone can code, and not everyone who can code is allowed to write code against the resources I have.
elliotbnvl · 1h 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.
freed0mdox · 1h 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.
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 · 21m 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 · 11m 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.
refulgentis · 5m ago
I get the general premise but am uncertain as to if it's desirable to invest more in inverting the protocol, where the tool server becomes an LLM client. "Now you have 2 protocols", comes to mind - more concretely, it upends the security model.
atlgator · 35m ago
The async callbacks are in your implementation. I wrote an MCP server so customers could use an AI model to query a databricks sql catalog. The queries were all async.
ashwinsundar · 50m ago
Why does MCP need to support this explicitly? Is it hard to write a small wrapper than handles async callbacks? (Serious question)
jjfoooo4 · 29m 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)
lsaferite · 6m ago
> It's very hard for me to understand what MCP solves
It's providing a standardized protocol to attach tools (and other stuff) to agents (in an LLM-centric world).
cubancigar11 · 17m ago
It is a protocol. If I have to list a bunch of files on my system I don't call a rest server. Same way mcp is not for you doing your stuff. It is for other people do to stuff on your server by the way of tools.
refulgentis · 24m 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.
TOMDM · 1h ago
Maybe the Key Changes page would be a better link if we're concerned with a specific version?
https://modelcontextprotocol.io/docs/concepts/sampling
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.
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)
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)
It's providing a standardized protocol to attach tools (and other stuff) to agents (in an LLM-centric world).
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.
https://modelcontextprotocol.io/specification/2025-06-18/cha...