> "Since its inception, we’ve been committed to ensuring MCP remains open-source, community-driven and vendor-neutral. Today, we further that commitment by donating MCP to the Linux Foundation."
Interesting move by Anthropic! Seems clever although curious if MCP will succeed long-term or not given this.
It feels far too early for a protocol that's barely a year old with so much turbulence to be donated into its own foundation under the LF.
Alot of people don't realize this, but the foundations that wrap up to the LF have revenue pipelines that are supported by those foundations events (like Kubecon brings in ALOT of money for the CNCF), courses, certifications, etc. And, by proxy, the projects support those revenue streams for the foundations they're in. The flywheel is _supposed_ to be that companies donate to the foundation, those companies support the projects with engineering resources, they get a booth at the event for marketing, and the LF can ensure the health and well-being of the ecosystem and foundation through technical oversight committees, elections, a service-desk, owning the domains, etc.
I don't see how MCP supports that revenue stream nor does it seem like a good idea at this stage: why get a certification for "Certified MCP Developer" when the protocol is evolving so quickly and we've yet to figure how OAuth is going to work in a sane manner?
Mature projects like Kuberentes becoming the backbone of a foundation, like it did with CNCF, makes alot of sense: it was a relatively proven technology at Google that had alot of practical use cases for the emerging world of "cloud" and containers. MCP, at least for me, has not yet proven it's robustness as a mature and stable project: I'd put it into the "sandbox" category of projects which are still rapidly evolving and proving their value. I would have much preferred for Anthropic and a small strike team of engaged developers to move fast and fix alot of the issues in the protocol vs. it getting donated and slowing to a crawl.
It really feels to me that MCP is a fad. Tool calling seems like the overwhelming use case, but a dedicated protocol that goes through arbitrary runtimes is massive overkill
I am more interested in how MCP can change human interaction with software.
Practical example: there exists an MCP server for Jira.
Connect that MCP server to e.g. Claude and then you can write prompts like this:
"Produce a release notes document for project XYZ based on the Epics associated to version 1.2.3"
or
"Export to CSV all tickets with worklog related to project XYZ and version 1.2.3. Make sure the CSV includes these columns ....."
Especially the second example totally removes the need for the CSV export functionality in Jira. Now imagine a scenario in which your favourite AI is connected via MCP to different services. You can mix and match information from all of them.
Alibaba for example is making MCP servers for all of its user-facing services (alibaba mail, cloud drive, etc etc)
A chat UI powered by the appropriate MCP servers can provide a lot of value to regular end users and make it possible for people to use their own data easily in ways that earlier would require dedicated software solutions (exports, reports). People could use software for use cases that the original authors didn't even imagine.
How does it remove the need for CSV export? The LLM can make mistakes right? Wouldn’t you want the LLM calling the deterministic csv export tool rather than trying to create a csv on its own?
I have been creating an MCP server over the past week or so. Based on what I have seen first hand, an MCP can give much richer context to the AI engine just by using very verbose descriptions in the functions. When it the AI tool (Claude Desktop, Gemini, etc) connects to the server, it examines the descriptions in each function and gets much better context on how to use the tool. I don't know if an API can do the same. I have been very, very impressed how much Claude can do with a good MCP.
I've been involved with a few MCP servers. MCP seems like an API designed specifically for LLMs/AIs to interact with.
Agree that tool calling is the primary use case.
Because of context window limits, a 1:1 mapping of REST API endpoint to MCP tool endpoint is usually the wrong approach. Even though LLMs/agents are very good at figuring out the right API call to make.
So you can build on top of APIs or other business logic to present a higher level workflow.
But many of the same concerns apply to MCP servers as they did to REST APIs, which is why we're seeing an explosion of gateways and other management software for MCP servers.
I don't think it is a fad, as it is gaining traction and I don't see what replaces it for a very real use case: tool calling by agents/LLMs.
I hope MCP will prosper inside this new structure!
Block donating Goose is a bit more worrisome - it feels like they are throwing it away into the graveyard.
Depends a bit on where your agent runs and how/if you built it.
I'm not arguing if one or the other is better but I think the distinction is the following:
If an agent understands MCP, you can just give it the MCP server: It will get the instructions from there.
Tool-Calling happens at the level of calling an LLM with a prompt. You need to include the tool into the call before that.
So you have two extremes:
- You build your own agent (or LLM-based workflow, depending on what you want to call it) and you know what tools to use at each step and build the tool definitions into your workflow code.
- You have a generic agent (most likely a loop with some built-in-tools) that can also work with MCP and you just give it a list of servers. It will get the definitions at time of execution.
This also gives MCP maintainers/providers the ability/power/(or attack surface) to alter the capabilities without you.
Of course you could also imagine some middle ground solution (TCDCP - tool calling definition context protocol, lol) that serves as a plugin-system more at the tool-calling level.
But I think MCP has some use cases. Depending on your development budget it might make sense to use tool-calling.
I think one general development pattern could be:
- Start with an expensive generic agent that gets MCP access.
- Later (if you're a big company) streamline this into specific tool-calling workflows with probably task-specific fine-tuning to reduce cost and increase control (Later = more knowledge about your use case)
Anthropic wants to ditch MCP and not be on the hook for it in the future -- but lots of enterprises haven't realized its a dumb, vibe coded standard that is missing so much. They need to hand the hot potato off to someone else.
Contrary to what a lot of the other comments here are claiming, I don't think that's the mark of death for MCP and Anthropic trying to get rid of it.
From the announcement and keeping up with the RFCs for MCP, it's pretty obvious that a lot of the main players in AI are actively working with MCP and are trying to advance the standard. At some point or another those companies probably (more or less forcefully) approached Anthropic to put MCP under a neutral body, as long-term pouring resources into a standard that your competitor controls is a dumb idea.
I also don't think the Linux Foundation has become the same "donate your project to die" dumping ground that the Apache Software Foundation was for some time (especially for Facebook). There are some implications that come with it like conference-ification and establishing certificates programs, which aren't purely good, but overall most multi-party LF/CNCF projects have been doing fairly well.
41 comments
[ 2.6 ms ] story [ 58.8 ms ] threadInteresting move by Anthropic! Seems clever although curious if MCP will succeed long-term or not given this.
so for like a year?
I really like Claude models, but I abhor the management at Anthropic. Kinda like Apple.
They never open sourced any models, not even once.
Alot of people don't realize this, but the foundations that wrap up to the LF have revenue pipelines that are supported by those foundations events (like Kubecon brings in ALOT of money for the CNCF), courses, certifications, etc. And, by proxy, the projects support those revenue streams for the foundations they're in. The flywheel is _supposed_ to be that companies donate to the foundation, those companies support the projects with engineering resources, they get a booth at the event for marketing, and the LF can ensure the health and well-being of the ecosystem and foundation through technical oversight committees, elections, a service-desk, owning the domains, etc.
I don't see how MCP supports that revenue stream nor does it seem like a good idea at this stage: why get a certification for "Certified MCP Developer" when the protocol is evolving so quickly and we've yet to figure how OAuth is going to work in a sane manner?
Mature projects like Kuberentes becoming the backbone of a foundation, like it did with CNCF, makes alot of sense: it was a relatively proven technology at Google that had alot of practical use cases for the emerging world of "cloud" and containers. MCP, at least for me, has not yet proven it's robustness as a mature and stable project: I'd put it into the "sandbox" category of projects which are still rapidly evolving and proving their value. I would have much preferred for Anthropic and a small strike team of engaged developers to move fast and fix alot of the issues in the protocol vs. it getting donated and slowing to a crawl.
Now there are CLI tools which can invoke MCP endpoints, since agents in general fare better with CLI tools.
Practical example: there exists an MCP server for Jira. Connect that MCP server to e.g. Claude and then you can write prompts like this:
"Produce a release notes document for project XYZ based on the Epics associated to version 1.2.3"
or
"Export to CSV all tickets with worklog related to project XYZ and version 1.2.3. Make sure the CSV includes these columns ....."
Especially the second example totally removes the need for the CSV export functionality in Jira. Now imagine a scenario in which your favourite AI is connected via MCP to different services. You can mix and match information from all of them.
Alibaba for example is making MCP servers for all of its user-facing services (alibaba mail, cloud drive, etc etc)
A chat UI powered by the appropriate MCP servers can provide a lot of value to regular end users and make it possible for people to use their own data easily in ways that earlier would require dedicated software solutions (exports, reports). People could use software for use cases that the original authors didn't even imagine.
Agree that tool calling is the primary use case.
Because of context window limits, a 1:1 mapping of REST API endpoint to MCP tool endpoint is usually the wrong approach. Even though LLMs/agents are very good at figuring out the right API call to make.
So you can build on top of APIs or other business logic to present a higher level workflow.
But many of the same concerns apply to MCP servers as they did to REST APIs, which is why we're seeing an explosion of gateways and other management software for MCP servers.
I don't think it is a fad, as it is gaining traction and I don't see what replaces it for a very real use case: tool calling by agents/LLMs.
I'm not arguing if one or the other is better but I think the distinction is the following:
If an agent understands MCP, you can just give it the MCP server: It will get the instructions from there.
Tool-Calling happens at the level of calling an LLM with a prompt. You need to include the tool into the call before that.
So you have two extremes:
- You build your own agent (or LLM-based workflow, depending on what you want to call it) and you know what tools to use at each step and build the tool definitions into your workflow code.
- You have a generic agent (most likely a loop with some built-in-tools) that can also work with MCP and you just give it a list of servers. It will get the definitions at time of execution.
This also gives MCP maintainers/providers the ability/power/(or attack surface) to alter the capabilities without you.
Of course you could also imagine some middle ground solution (TCDCP - tool calling definition context protocol, lol) that serves as a plugin-system more at the tool-calling level.
But I think MCP has some use cases. Depending on your development budget it might make sense to use tool-calling.
I think one general development pattern could be:
- Start with an expensive generic agent that gets MCP access.
- Later (if you're a big company) streamline this into specific tool-calling workflows with probably task-specific fine-tuning to reduce cost and increase control (Later = more knowledge about your use case)
Facebook still has de facto control over PyTorch.
Anthropic will move onto bigger projects and other teams/companies will be stuck with sunk cost fallacy to try and get mcp to work for them.
Good luck to everyone.
From the announcement and keeping up with the RFCs for MCP, it's pretty obvious that a lot of the main players in AI are actively working with MCP and are trying to advance the standard. At some point or another those companies probably (more or less forcefully) approached Anthropic to put MCP under a neutral body, as long-term pouring resources into a standard that your competitor controls is a dumb idea.
I also don't think the Linux Foundation has become the same "donate your project to die" dumping ground that the Apache Software Foundation was for some time (especially for Facebook). There are some implications that come with it like conference-ification and establishing certificates programs, which aren't purely good, but overall most multi-party LF/CNCF projects have been doing fairly well.