SoylentNews is people
SoylentNews
The Agentic AI Foundation launches to support MCP, AGENTS.md, and goose:
Big Tech has spent the past year telling us we're living in the era of AI agents, but most of what we've been promised is still theoretical. As companies race to turn fantasy into reality, they've developed a collection of tools to guide the development of generative AI. A cadre of major players in the AI race, including Anthropic, Block, and OpenAI, has come together to promote interoperability with the newly formed Agentic AI Foundation (AAIF). This move elevates a handful of popular technologies and could make them a de facto standard for AI development going forward.
The development path for agentic AI models is cloudy to say the least, but companies have invested so heavily in creating these systems that some tools have percolated to the surface. The AAIF, which is part of the nonprofit Linux Foundation, has been launched to govern the development of three key AI technologies: Model Context Protocol (MCP), goose, and AGENTS.md.
MCP is probably the most well-known of the trio, having been open-sourced by Anthropic a year ago. The goal of MCP is to link AI agents to data sources in a standardized way—Anthropic (and now the AAIF) is fond of calling MCP a "USB-C port for AI." Rather than creating custom integrations for every different database or cloud storage platform, MCP allows developers to quickly and easily connect to any MCP-compliant server.
Since its release, MCP has been widely used across the AI industry. Google announced at I/O 2025 that it was adding support for MCP in its dev tools, and many of its products have since added MCP servers to make data more accessible to agents. OpenAI also adopted MCP just a few months after it was released.
Expanding use of MCP might help users customize their AI experience. For instance, the new Pebble Index 01 ring uses a local LLM that can act on your voice notes, and it supports MCP for user customization.
Local AI models have to make some sacrifices compared to bigger cloud-based models, but MCP can fill in the functionality gaps. "A lot of tasks on productivity and content are fully doable on the edge," Qualcomm head of AI products, Vinesh Sukumar, tells Ars. "With MCP, you have a handshake with multiple cloud service providers for any kind of complex task to be completed."
[...] Think about the timeline here. The world in which tech companies operate has changed considerably in a short time as everyone rushes to stuff gen AI into every product and process. And no one knows who is on the right track—maybe no one!
Against that backdrop, big tech has seemingly decided to standardize. Even for MCP, the most widely supported of these tools, there's still considerable flux in how basic technologies like OAuth will be handled.
The Linux Foundation has spun up numerous projects to support neutral and interoperable development of key technologies. For example, it formed the Cloud Native Computing Foundation (CNCF) in 2015 to support Google's open Kubernetes cluster manager, but the project has since integrated a few dozen cloud computing tools. Certification and training for these tools help keep the lights on at the foundation, but Kubernetes was already a proven technology when Google released it widely. All these AI technologies are popular right now, sure, but is MCP or AGENTS.md going to be important in the long term?
Regardless, everyone in the AI industry seems to be on board. In addition to the companies adding their tools to the project, the AAIF has support from Amazon, Google, Cloudflare, Microsoft, and others. The Linux Foundation says it intends to shepherd these key technologies forward in the name of openness, but it may end up collecting a lot of nascent AI tools at this rate.
(Score: 5, Interesting) by VLM on Sunday December 14 2025, @07:45PM
Its a mass market article not for developers or technical people.
I'd describe it more like LSP++. Language Server Protocol that thing for IDEs. The ++ in that it adds a bunch of stuff. It is literally, IIRC, JSON-RPC. Instead of asking for "textDocument/definition" you're asking for stuff like "get_pipeline_jobs" from gitlab, etc.
Comes with a set of libraries so you don't have to mess with raw JSON/RPC (JSON-RPC, wtf its called) unless you want to.
There are three other interesting applications for MCP. All unofficial and "you're not supposed to do that" but its a ton of fun to do anyway.
You can use it like LSP++ and F with things from inside an IDE. You're supposed to use it with AI not play with it this way, but its fun to mess with other things from inside your IDE. Nothing really changes and "doing stupid things from inside emacs" was a hobby back in 1990 (probably still is LOL).
You can hack it, its just megacorporation code, of course there's security holes ready to exploit that humans will do a better job of than AI.
You can use it do weird yet totally legal and intentional things. There exists a SSH agent/server thing that speaks MCP. Ansible can do pretty much anything if it has SSH access. Ansible officially can't connect over MCP instead of SSH (AFAIK, last time I checked) but its fun to think about connecting to a host over MCP instead of using SSH like a civilized caveman. Another is Gitlab (at least self hosted) has a MCP server and you can make a python thing that Jenkins calls to talk to Gitlab over MCP no AI involved. Yes you could use gitlabs "regular" "normal" API but there was a reason for this which I forget. Something to do with jenkins being able to log the output of "get_pipeline_jobs" using MCP easier than using the "real" gitlab API for whatever reason. Probably very local installation dependent.
Anyway my point is MCP is a fairly entertaining "not just for AI anymore" protocol and I don't think anyone who's ever passed fizzbuzz would call it a "usb-c port" I would accept an analogy like "a slightly less psychotic REST API" but really its just good old LSP with a bunch of addons running over JSON-RPC
After the bubble I hope MCP lives on, its a nifty way to remotely mess with stuff thats "lighter" than REST (somewhat).