MCP Explained: Connecting AI Agents to Your Real Development Stack

In the previous articles in this series, we focused mainly on information that lives inside your repository.

We looked at:

• 01 why AI coding assistants lose important context
• 02 how coding agents discover relevant files and symbols
• 03 how AGENTS.md, project rules, documentation, and repository structure can guide an agent

But real software development does not happen entirely inside a Git repository. Developers also work with issue trackers, internal documentation, databases, monitoring platforms, deployment systems, customer support tools, cloud infrastructure, analytics platforms, and company APIs.

An AI agent that can only read source code has access to only part of the engineering environment.

This is the problem the Model Context Protocol (MCP) is designed to address. MCP provides a standardized way for AI applications to connect to external tools and data sources.

Instead of building a completely different integration for every AI assistant, a system can expose capabilities through an MCP server, and compatible AI applications can connect to them through the same protocol.

The important idea is not simply that MCP gives AI “more context.” It gives AI agents a structured interface to the systems where real work happens.

The integration problem before MCP

Imagine your engineering team uses an AI coding assistant. You want the agent to be able to:

1. read a ticket
2. inspect the code
3. look up architecture docs
4. query recent errors
5. implement the fix
6. run tests and update the ticket

Without a common protocol, every AI product needs a custom integration for every external system. Conceptually, you end up with something like this:

AI Assistant
    │
    ├── custom Jira integration
    ├── custom GitHub integration
    ├── custom database integration
    ├── custom documentation integration
    ├── custom monitoring integration
    └── custom deployment integration

Now add another AI assistant. Then another. Soon you have Cursor, Claude Code, and an internal agent each wired separately to Jira, Datadog, internal docs, and a database. The number of integrations grows quickly. Each one may have different authentication, schemas, permission models, error handling, and maintenance requirements.

MCP attempts to standardize that boundary.

Fig. 01 — One protocol, many systems

What is MCP?

Anthropic introduced the Model Context Protocol in November 2024 as an open protocol for connecting AI applications to external systems. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation, where it became one of the foundation’s initial projects alongside AGENTS.md and Block’s goose project.

By 2026, MCP had been adopted across a broad ecosystem of AI development products and infrastructure providers.

At a high level, MCP changes the previous integration diagram into something closer to this:

Cursor    Claude Code    Internal AI
     \         |          /
      \        |         /
               MCP
        /      |       \
Issue Tracker  Database  Internal Docs
               |
           Monitoring

The AI applications still need to decide when and how to use those systems. The external systems still need authentication and authorization. MCP simply creates a standard language between them.

The MCP architecture

The terminology can initially be confusing, but the architecture is relatively straightforward. There are three concepts worth understanding:

1. MCP HostThe AI application: a coding environment, IDE, desktop agent, or internal company product. It manages the model, permissions, and connections to MCP servers.
2. MCP ClientProtocol machinery inside the host that talks to a particular server. End users generally do not need to think about this layer.
3. MCP ServerExposes capabilities to the AI application and maps them onto the systems behind it.

For example, a company’s internal engineering MCP server might expose search_documentation, get_incident, search_application_logs, get_customer_account, create_issue, and deploy_preview.

The AI agent does not necessarily need to know whether search_application_logs is implemented using Datadog, Elasticsearch, CloudWatch, or an internal observability platform. It simply understands the capability exposed to it. That abstraction is one of MCP’s most useful characteristics.

Tools, resources, and prompts

MCP servers can expose several kinds of capabilities. Three of the most important are tools, resources, and prompts. The current MCP SDK documentation describes these as the core surfaces servers expose to compatible hosts. They solve different problems.

Fig. 02 — Three surfaces

Tools: let the agent do something

A tool represents an operation the model can request: search_logs, create_ticket, run_database_query, deploy_preview, get_order_status.

A tool generally has a defined input schema. Conceptually:

{
  "name": "get_order",
  "description": "Retrieve an order by ID",
  "input": {
    "orderId": "string"
  }
}

The agent can reason that it needs to understand why order ORD-18472 failed, then call get_order(orderId="ORD-18472"). The MCP server handles the actual integration.

This is much better than giving the model raw credentials and asking it to figure out how to call an internal API itself. The server establishes a controlled interface.

Resources: give the agent data

A resource exposes information that a client or model can read: architecture documents, runbooks, schemas, API specifications, configuration, internal knowledge.

This fits directly into the context engineering principles we discussed earlier. Instead of placing the company’s entire documentation library into every prompt, the agent can retrieve the relevant information when the task requires it.

Prompts: reusable workflows

MCP servers can also expose prompts: reusable templates that help standardize how a task is performed. An engineering platform might provide investigate_production_incident, review_database_migration, prepare_release, or analyse_customer_bug.

The goal is not simply to store strings. It is to create reusable interaction patterns around the systems exposed by the server. In practice, many teams will initially gain the most value from tools and resources, but prompts can be useful when an organization wants consistent workflows across different AI clients.

A real engineering example

Suppose a customer reports that checkout occasionally fails after applying a discount code. Without access to external systems, the coding agent may only be able to search the repository, inspect tests, and guess.

Fig. 03 — Source context plus operational context

Now the agent is reasoning with both source code context and operational context. That is a major difference.

MCP is an interface, not a database

One misconception is that MCP is essentially a new vector database or knowledge store. It is not. MCP does not require you to move all your information into a new system. Instead, it provides an interface through which an AI application can interact with systems that already exist.

PostgreSQL            → Database MCP Server
Internal REST API     → Company MCP Server
Documentation platform → Documentation MCP Server

That distinction matters because mature businesses already have years of infrastructure and data. The objective is usually not to move everything into something built specifically for AI. It is to give AI a controlled way to interact with the systems we already trust.

Local MCP servers vs. remote MCP servers

MCP servers can operate in different environments. A local development tool might launch an MCP server as a local process and communicate through standard input and output (stdio). The official TypeScript SDK describes stdio as the natural choice when a host launches and controls a local MCP server process.

Enterprise integrations frequently need remote servers over HTTPS. One managed service can then serve multiple authorized users and AI applications, sitting in front of documentation, issue trackers, observability, and internal APIs.

MCP became more production friendly in 2026

The protocol itself has also been evolving quickly. The 28 July 2026 MCP specification introduced one of its largest architectural changes: the remote protocol core became stateless.

Earlier versions relied more heavily on protocol level sessions. Under the current design, individual requests can carry the information necessary to process them independently. This makes remote MCP servers easier to run behind ordinary HTTP infrastructure such as load balancers, gateways, rate limiters, and web application firewalls.

That is exactly the kind of architectural detail that becomes important when MCP moves from a developer experiment to shared enterprise infrastructure. The 2026 specification also formalized an extension model and strengthened authorization related parts of the protocol.

Where MCP becomes genuinely useful

Not every API needs an MCP server. MCP becomes particularly interesting when multiple AI clients need controlled access to the same capabilities.

You could teach every AI application how to call GET /internal/customers/:id and similar endpoints. Or you could expose a stable set of agent facing operations: get_customer, create_incident, search_logs, deploy_preview.

Now the AI facing contract is separated from the underlying application architecture. Your internal APIs can evolve. Your monitoring provider can change. Your issue tracker can change. Your MCP interface can remain relatively stable. That is a useful architectural boundary.

Design tools around intent, not raw infrastructure

Imagine giving an AI agent execute_sql(query). The tool is extremely powerful. It is also extremely broad. The agent now has to generate SQL correctly, understand your database structure, respect access restrictions, and avoid destructive operations.

What is the smallest useful capability the agent needs to complete this workflow?

MCP does not make security problems disappear

Connecting AI agents to external systems creates obvious risks. An agent that can read documentation is relatively low risk. An agent that can modify production databases, deploy applications, send customer emails, issue refunds, or delete infrastructure is something very different.

MCP standardizes communication. It does not eliminate the need for authentication, authorization, access control, auditing, and careful capability design. The MCP specification has consistently emphasized user control, data privacy, and caution around tools capable of arbitrary actions. Its authorization model for remote HTTP servers also builds on established OAuth security practices, including resource bound access tokens rather than passing credentials indiscriminately between services.

Fig. 04 — Least privilege

Agent infrastructure should be treated like other production infrastructure.

MCP can also reduce vendor lock in

Imagine your engineering team builds a sophisticated integration between its internal systems and one specific AI coding product. Two years later, you want to use another model or another agent platform. If your integration is proprietary to the first product, you may need to rebuild everything.

A company MCP layer sitting in front of internal systems can serve coding tool A, coding tool B, an internal agent, and future AI applications. That does not guarantee perfect portability. Different hosts support different features, permissions, and workflows. But it creates a much stronger separation between your business capabilities and the AI product consuming them.

When you probably do not need MCP

MCP is useful, but it is also easy to over engineer. Suppose you are building one internal AI workflow and it needs to call one existing API. You may not need an MCP server in the middle. Similarly, if an agent simply needs to read three Markdown files inside the repository, exposing them through MCP would probably add complexity without adding value.

MCP becomes more compelling when you have:

• multiple AI clients
• reusable integrations
• external or internal systems
• structured capabilities
• centralized authentication
• organization wide agent infrastructure

It is an architectural tool. And like every architectural tool, it should solve a real problem.

MCP does not replace good APIs

A poorly designed backend does not become well designed because you placed an MCP server in front of it. If your internal systems have inconsistent permissions, unclear ownership, undocumented APIs, unreliable data, weak authentication, or dangerous side effects, an MCP layer may simply expose those problems to AI agents faster.

A good MCP implementation usually sits on top of well designed services. The MCP server translates between the agent facing capability and your existing application architecture. It should not become a second implementation of your business logic.

The bigger picture

The importance of MCP becomes clearer when we connect it to the previous articles in this series.

1. AGENTS.mdHow should I work in this repository?
2. Repository searchWhere is the relevant code?
3. DocumentationHow does this system work?
4. MCPWhat is happening outside the repository, and what external actions am I allowed to take?

Together, these systems form something much more powerful than a chatbot with a large context window. They create an engineering environment where the agent can progressively gather information and interact with the systems required to complete a real task.

              AI Coding Agent
                     │
     ┌───────────────┼───────────────┐
     │               │               │
AGENTS.md       Repository       MCP Servers
     │               │               │
Project Rules       Code        Docs, logs, APIs

Now we are no longer simply giving a model a prompt. We are building an operating environment for an agent.

The key principle

MCP is not valuable because it lets an AI connect to everything. It is valuable because it gives us a standardized way to decide exactly what an AI can access and how it can interact with it.

A well designed MCP server should expose meaningful, limited capabilities. It should hide unnecessary infrastructure complexity. It should respect existing authentication and authorization boundaries. And it should allow agents to retrieve information or perform actions only when the task actually requires them.

The goal is not to give the AI access to the company. The goal is to give the AI the smallest reliable interface it needs to complete useful work.

That difference becomes more important as agents move from isolated coding sessions into production workflows.