The question every team building AI agents hits around the third week of production use: how do you give an agent access to your internal stuff without writing bespoke integration code for every tool you want to connect? Your data lives in Postgres. Your issues are in Jira. Your customer records are in Salesforce. Your AI agent needs all of it. And building custom tools for each one that you then maintain indefinitely is not a sustainable architecture.

Model Context Protocol (MCP) is Anthropic’s answer to this, and it’s becoming a de facto standard for how AI agents connect to external systems. Rather than each AI framework inventing its own tool protocol, MCP provides a common interface that any MCP-compatible client — Claude, Cursor, Windsurf, and a growing number of other systems — can speak. You build an MCP server once, and it works with any compatible agent.

What an MCP Server Actually Does

An MCP server exposes three types of things: tools (functions the agent can call), resources (data the agent can read), and prompts (pre-built instruction templates). For most enterprise integrations, you’ll primarily care about tools and resources.

Tools are the action surface — they’re what the agent invokes to do things. get_jira_issues(project="INFRA", status="open") is a tool. query_customer_database(sql="SELECT * FROM customers WHERE churn_risk > 0.8") is a tool. The agent calls them with arguments and gets back results.

Resources are a way to expose documents, datasets, or structured content that the agent can pull into its context. A resource might be a runbook, a schema definition, or a configuration file — something the agent might need to read but doesn’t need to execute.

The client-server relationship matters: your agent application is the MCP client, your internal tool connector is the MCP server. They communicate over either standard I/O (if the server runs as a subprocess) or HTTP with Server-Sent Events (if it runs as a standalone service). For enterprise deployments, HTTP is usually the right choice since it lets the server live on your infrastructure with proper access controls.

Writing a Simple MCP Server

The Python SDK is the most straightforward starting point. Install it with pip install mcp, then define your server:

from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp import types

server = Server("internal-tools")

@server.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="query_customer_db",
            description="Run a read-only SQL query against the customer database",
            inputSchema={
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "SQL SELECT statement"
                    }
                },
                "required": ["query"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[types.TextContent]:
    if name == "query_customer_db":
        # Your actual DB connection logic here
        result = run_readonly_query(arguments["query"])
        return [types.TextContent(type="text", text=str(result))]

if __name__ == "__main__":
    import asyncio
    asyncio.run(stdio_server(server))

That’s the skeleton. You fill in the actual integration code — database connections, API calls, authentication — and the MCP client side handles the rest: tool discovery, argument passing, result surfacing.

The Architecture Decisions That Matter

Single server vs. multiple servers: You can expose all your internal tools through one MCP server or split them into separate servers by domain (a Jira server, a database server, a Salesforce server). Separate servers give you cleaner separation of concerns and let you set different authentication requirements per domain. A single server is simpler to operate. Most teams start single and split later as the tool count grows.

Stdio vs. HTTP transport: Stdio transport (the server runs as a subprocess of the client) is fine for local development and tools that run on the same machine. HTTP transport is better for shared infrastructure — your enterprise MCP server can run as a Docker container, expose an endpoint, and multiple teams’ agents can use it without each running their own copy.

Authentication and access control: MCP servers can be called by any MCP-compatible client that has network access to them. For enterprise deployments, your server should verify that the calling agent has appropriate permissions before executing tools. OAuth 2.0 is the recommended approach: the server validates tokens and enforces per-tool access scopes. Don’t skip this step — an agent with access to a database query tool and no access controls is a very wide blast radius.

Read vs. write tools: Be deliberate about what actions your agent can take. Start with read-only tools. Add write capabilities incrementally and with human approval gates where the consequences matter. An agent that can read your CRM is low-risk. An agent that can update customer records or send emails on your behalf needs careful thought about when it should pause for confirmation.

What to Build First

The most valuable MCP integrations to start with are usually the ones where agents are already failing because they lack context. If your agent keeps hallucinating answers because it doesn’t have access to current data, that’s the gap to close first.

Practical starting points for most organisations:

Jira or Linear — letting agents look up issues, find related tickets, and understand project status. Most teams use a project management tool daily; an agent that can reference it without you copying ticket numbers into chat is immediately useful.

Internal documentation — connecting the agent to your Confluence, Notion, or Obsidian vault. An MCP resource server that indexes your docs and makes them searchable dramatically improves the quality of answers you get from agents for internal processes.

Database read access — scoped, read-only SQL access to key tables. Customer data, metrics, configuration. The agent becomes useful for answering business questions that currently require a BI dashboard query.

Log aggregation — Datadog, Splunk, or whatever you’re using. Agents that can pull recent errors or tail logs when troubleshooting are significantly more useful than agents that have to ask you to paste them in.

The key pattern: identify where your agents are hitting knowledge limits, figure out which internal system holds that knowledge, and build an MCP tool for it. You don’t need to expose everything at once. A focused server with five well-designed tools delivers more value than a sprawling one with fifty poorly-described ones.