Model Context Protocol Emerges as a Common Framework for Enterprise AI Systems

ChatGPT may have accelerated the rise of large language models (LLMs) but turning those models into production-ready AI systems has exposed a different problem. The real engineering challenge has now pivoted from LLMs to everything that surrounds them and allows them to interact reliably with the world. Enterprises need ways to connect models to tools, data sources, memory systems, and business applications while maintaining security, reliability, and cost control. Model Context Protocol (MCP), introduced by Anthropic and now governed through the Agentic AI Foundation (AAIF) under the Linux Foundation, emerges as a common framework for connecting AI models to external tools, services, and data sources used by AI/ML engineers, application developers, platform teams, and enterprise architects. Speaking with EE Times at the recent MCP Dev Summit Mumbai, Ram Iyengar, chief evangelist at Cloud Foundry Foundation, said, “MCP has changed how LLMs discover tools and capabilities and has become widely adopted across AI agent ecosystems.” How MCP connects AI models to external systems MCP acts as a coordination layer above the model, helping systems access memory, discover tools, interact with external services, and connect multiple capabilities without requiring large volumes of contextual information. “The goal is to provide a small number of tokens that can help identify a much larger body of information,” Iyengar said. A system may need several tools to answer even a simple query. Identifying those tools is known as discovery, while invoking them is known as a tool call. These interactions allow the system to bring together different tools and services to generate an answer. “There are multiple conversions and API calls required to answer a single query,” Iyengar said. “MCP provides a standard way for LLMs to interact with tools and services through APIs. It operates above the individual components involved and breaks a prompt into multiple tool calls and skills.” He added that MCP registries, gateways, allowlists, and blocklists provide governance over which tools an AI system can access. “Unlike proprietary ecosystems, MCP is not controlled through a central repository,” Iyengar said. “Anyone can write an MCP. It has become one of the defining technologies enabling modern AI agents.” While the Linux Foundation recommends certain registries, it does not maintain a formal list of approved tools. Referring to the Goose project, Iyengar revealed that the Foundation indirectly influences MCP usage through recommended registries, but there is no official Linux Foundation repository. In an exclusive chat with EE Times, Arpit Joshipura, general manager of networking, IoT, and edge at the Linux Foundation, explained MCP’s ability to reduce vendor lock-in. “Open protocols allow organizations to change technology providers without changing the way models connect to tools and services,” he said. “Everybody supports MCP. It does not matter whether your vendor is one company today and another tomorrow because they all use the same MCP.” Enterprise AI challenges extend beyond the model Organizations increasingly realize that deploying AI involves much more than selecting an LLM. “There is an LLM, and it gets your prompt and acts on some data as a result,” he said. “For the LLM to function, it can either reside on your server or somewhere in the cloud.” Running models internally provides greater control and privacy but introduces infrastructure costs, maintenance requirements, and staffing demands. Cloud deployments, by contrast, offer more predictable expenditure through subscription models. The tradeoff, he said, lies between privacy and operational complexity. As a result, deployment decisions often depend on the sensitivity of the data involved. Iyengar said enterprises must also contend with the probabilistic nature of LLMs. Different models excel at different tasks. “If you run the same prompt with the same data twice, because of the essentially non-deterministic nature of how this system works, you are likely to get two different answers,” he said. This has led organizations to pursue multiple optimization approaches, including model selection, answer-correlation techniques, mixture-of-experts architectures, and quantization methods. Beyond output quality, Iyengar highlighted memory management as another obstacle. A model may answer one query successfully but fail to retain context when a related query follows. “Memory is a major challenge for LLMs,” Iyengar said. Preserving user history, tool state, and conversational context can consume large numbers of tokens before any new interaction begins. This increases operational costs and creates pressure to build more efficient mechanisms for providing contextual information. “The challenge is building a mechanism that provides access to information without exhausting tokens before the interaction even begins,” he explained. It is within this context that MCP becomes relevant. Joshipura described AI systems as evolving into layered architectures consisting of an intelligence layer, an agentic layer, and a domain layer. “The agentic layer sits above the model layer and can access both public and private data,” he said. “Organizations can configure these agents according to enterprise requirements while retaining control over sensitive information.” Goose demonstrates MCP in practice Goose serves as one example of how MCP is being implemented in practice. Iyengar described Goose as an open-source AI agent combining elements of Anthropic Claude, OpenCode, Codex, and other familiar AI tools. “It has about 128,000 tokens available per session, which it consumes as it performs its work,” he said. Iyengar said Goose combines MCP capabilities with open-source development, providing a more native way to connect AI systems with external tools and services. Proprietary platforms such as Claude also support MCP, but Iyengar argued that Goose benefits from being both open source and tightly integrated with MCP. However, Iyengar cautioned against assuming that open source automatically delivers better outcomes. “Open source does not automatically mean better,” he said. “It can evolve in ways that you cannot control, and uncertainty can arise.” Goose also demonstrates how MCP can support model-agnostic deployments, allowing organizations to use different models for different workloads. The platform supports multi-agent workflows, enabling multiple agents to operate under different roles and responsibilities. Organizations can configure these workflows through YAML files that define agent behavior, responsibilities, and default actions. Iyengar said that Goose can operate on local infrastructure while supporting providers such as Ollama, OpenAI, Anthropic’s Claude, and Gemini. For organizations handling sensitive information, it can also run in air-gapped environments using local databases, local runtimes, and local models. “Banks, financial institutions, insurance companies, pharmaceutical organizations, and other organizations handling sensitive data could benefit from such deployments because all required components can remain self-contained within the environment,” he said. Iyengar linked these deployment models to broader discussions around sovereign AI, which he defined as systems that operate within national boundaries, are managed locally, and keep data within local jurisdictions. As enterprises continue to move from AI experimentation to production deployments, Iyengar argued that the focus is shifting away from the model alone and toward the infrastructure that allows models to interact with the outside world. “MCP is emerging as one of the technologies enabling that transition,” he said. Read also: SUSE, Nvidia Launch AI Infra for Enterprise AI Deployment and Sovereignty EDA’s AI Revolution Meets Its Real-World Constraints SiMa Launches Agentic Development Environment for Physical AI Leave a Reply You must Register or Login to post a comment.