How Model Context Protocol Is Changing What AI Engineers Build

Most AI engineers have spent time writing custom integration code to connect a language model to an external tool, a database, a file system, an API. The code works, but it belongs to exactly that use case. Change the model provider, add a new tool, or hand the project to another team, and the integration needs to be rebuilt or reverse-engineered. Model Context Protocol (MCP), released by Anthropic in November 2024, was designed to eliminate that cycle entirely.

By February 2025, a wave of open-source MCP connectors had already emerged, with major organizations including Block, Apollo, Zed, Replit, Codeium, and Sourcegraph adopting the standard, according to Anthropic’s official announcement. Understanding what MCP actually does, and where its boundaries are, is increasingly relevant for any engineer building LLM-powered applications.

The Problem MCP Was Built to Solve

Before MCP, connecting a model to an external tool required bespoke code for every combination. If you had M models and N tools, you needed custom logic for each pairing, what engineers refer to as the M×N integration problem. Every new tool required reimplementing the same connection patterns, and those implementations were tightly coupled to specific model providers.

MCP addresses this by introducing a shared protocol that any compatible model and any compatible tool can speak fluently. The integration complexity reduces from M×N to M+N, because developers build once against the standard and the pieces become interchangeable. A common analogy in the AI community captures this well: MCP acts as a universal interface for AI applications, enabling seamless interoperability between models and tools.

This matters practically because it means an MCP server built to expose a company’s internal database can, without modification, be used by a different LLM than the one it was originally built for. That portability directly addresses the vendor lock-in problem that has made many enterprise AI integrations expensive to maintain.

What the Architecture Actually Looks Like

MCP uses a client-server model with three distinct components, each playing a defined role in moving information between the LLM and the outside world.

The host is the application the user interacts with, an AI-powered IDE, a chatbot, a custom enterprise tool. It contains the LLM and manages one or more MCP clients.

The MCP client, running inside the host, handles communication between the LLM and the MCP servers. It discovers available tools and resources, translates the LLM’s intent into structured requests, and returns the server’s responses in a format the model can interpret.

The MCP server is a separate program that wraps a specific data source or capability behind the MCP standard. It exposes three categories of functionality:

• Tools are executable functions the LLM can call, such as reading a file, sending a message, or querying a database. Each tool is defined with a clear input and output schema.
• Resources are data objects the model can read or reference, like a database schema, a document, or configuration state. They are identified by a URI and help ground the model’s responses in current, accurate information.
• Prompts are reusable structured templates that guide the LLM through multi-step tasks, ensuring it collects the necessary inputs before executing an action.

Transport between client and server uses JSON-RPC 2.0 messages. For local environments, standard input/output (stdio) handles communication directly between processes. For remote deployments, Streamable HTTP enables real-time data streaming across networks. According to Teleport’s infrastructure engineering documentation tracking Model Context Protocol (MCP) implementations, the older HTTP+SSE (Server-Sent Events) transport was officially deprecated in the MCP specification version 2025-03-26.

How MCP Differs from Standard Function Calling

If you have worked with native tool use or function calling through APIs from OpenAI, Anthropic, or AWS Bedrock, MCP is structurally familiar. The difference is in how tools are discovered and where the integration logic lives.

In standard function calling, the developer pre-defines the tool schema and embeds it in the request. The LLM returns the function name and arguments, and the developer’s application handles invocation. Each integration is written and maintained at the application layer.

With MCP, the client calls list_tools() dynamically at runtime to discover what a server exposes. The schema comes from the server. When the LLM decides to use a tool, the client calls session.call_tool() and the MCP server handles the actual execution. Servers can also notify connected clients when tools are added, modified, or temporarily unavailable, making the integration reactive rather than static.

This distinction matters most when building applications that need to connect to multiple external systems, or when those systems are owned and maintained by different teams. The MCP server becomes the integration point that each team maintains, while the application layer stays clean.

A Concrete Walkthrough: The Flight Booking Example

A user asks an AI assistant to book a non-stop flight from New York to London next Friday. Here is how MCP handles that workflow in sequence.

The host captures the user’s request and the LLM identifies that it needs external tool access. The MCP client queries the flight booking server using tools/list command and receives flight/search and flight/book. The LLM determines that searching comes first and calls flight/search with the appropriate parameters. The MCP server translates that call into a native airline API request, retrieves the results, and returns a structured list. The LLM identifies the non-stop option and calls flight/book with the selected flight ID. After the server confirms the booking, the LLM generates a final response to the user.

Throughout this workflow, the application layer never touched the airline API directly. The MCP server handled that translation, meaning the same application could swap to a different airline API provider without any changes to the AI-facing integration.

What MCP Does Not Replace

MCP is a layer built on top of existing APIs. Most MCP servers act as lightweight wrappers around REST endpoints. They translate complex raw API responses into tool and resource definitions that are structured for LLM consumption. The underlying API still does the work. MCP standardizes the surface that the model sees.

It is also worth being precise about the agent/tool distinction that MCP introduces. An MCP tool executes a specific, deterministic action. An agent plans, reasons across multiple steps, and evaluates outcomes. MCP provides the tools that agents use as part of a larger reasoning loop. The protocol enables agentic behavior, while the orchestration logic that makes something genuinely agentic sits in the host application and the LLM itself.

Security and Practical Risks for Engineers

The power that MCP provides in connecting LLMs to external systems introduces security considerations that deserve direct attention rather than an afterthought.

The confused deputy problem is the most architecturally significant when an MCP server acts on a user’s request. Implementations that handle this incorrectly can allow users to access resources they should not have access to.

Executable code in MCP servers introduces the same scrutiny requirements as any mission-critical application. More specifically, malicious MCP servers present a supply chain risk. A server may appear legitimate initially but update its tool definitions to redirect an LLM into accessing or leaking data it should not touch. Tool descriptions cannot be trusted unless they originate from a verified server.

Context window overload is a practical operational risk. In enterprise environments with hundreds of available tools, passing all tool definitions to the LLM in every request can consume the entire context window. Approaches like intent-based routing, tool categorization by domain, and embedding-based relevance filtering are necessary when MCP deployments grow beyond a small number of servers.

Conclusion

The growth in adoption comes down to a specific set of practical benefits that engineers building production AI applications have been asking for.

Teams that build MCP servers once can connect them to any compatible host without rewriting integration logic. Organizations can switch LLM providers without breaking existing tool integrations. Third-party MCP servers can be adopted immediately without custom development, which is why open-source connectors emerged within the protocol’s first few months. MCP also reduces hallucinations in production applications by giving models structured, real-time access to authoritative data sources rather than requiring them to rely on training knowledge.

For AI engineers specifically, understanding MCP means building applications where the tool layer is decoupled from the model layer. That separation improves maintainability, makes future model upgrades less disruptive, and allows tool development to happen independently of application development. Those are durable architectural benefits, regardless of which LLM provider a team is using.