MCP Servers: Connecting AI to Your Tools and Data

What Is MCP?

The Model Context Protocol (MCP) is an open standard created by Anthropic that defines how AI applications communicate with external tools and data sources. Think of it as a universal adapter layer: instead of every AI agent building custom integrations for every service, MCP provides a standardized interface that any AI client can use to connect to any MCP-compatible server. The protocol specification is open-source and vendor-neutral, meaning any AI model or platform can implement it.

MCP follows a client-server architecture. The client is the AI application (Claude Code, Claude Desktop, or a custom agent built with the Claude Agent SDK). The server is a lightweight process that exposes specific capabilities -- tools (executable functions), resources (data references), and prompts (reusable templates). When an AI agent needs to interact with a service, it discovers available MCP servers, queries their capabilities, and calls their tools through the standardized protocol. A single client can connect to many servers simultaneously, and a single server can serve multiple clients.

The protocol supports three transport modes: Stdio (standard input/output for local processes -- fastest and simplest, ideal for same-machine servers), SSE (Server-Sent Events -- deprecated, replaced by Streamable HTTP; SSE required passing auth tokens in URL query strings, a security anti-pattern), and Streamable HTTP (the newest transport supporting full bidirectional streaming via a single endpoint with proper header-based auth -- best for long-running operations and remote servers that need to push updates). MCP servers can be written in any language, with official SDKs available for Python and TypeScript. The ecosystem already includes 50+ community-maintained servers covering databases, cloud platforms, development tools, communication services, and more.

How I Use It

My MCP stack is the connective tissue between Claude Code and every service I work with daily. The Atlassian Rovo server is the most heavily used -- it lets Claude Code read JIRA tickets, update issue statuses, add comments, search Confluence, and create pages. When I'm working on a feature, Claude Code reads the JIRA story, understands the acceptance criteria, implements the code, and updates the ticket status, all without leaving the terminal.

The Firebase and Supabase MCP servers handle database interactions for different projects. Claude Code can inspect schemas, write queries, check data integrity, and even suggest index optimizations by analyzing query patterns. This is especially powerful during debugging sessions where I need to correlate application behavior with database state.

GitHub and GitLab MCP servers automate my code review workflow. When a PR is ready, Claude Code reads the diff through the MCP server, analyzes changes against project conventions (from CLAUDE.md), and posts structured review comments. For GitLab, it also checks pipeline status and suggests fixes for CI failures.

I run the Slack MCP server for team coordination. Claude Code can read relevant channel history, search for past decisions, and post status updates. Combined with the Stripe MCP for payment-related projects, I have a comprehensive toolset that covers the full development lifecycle from planning (JIRA) through implementation (GitHub/GitLab) to operations (Slack, Stripe).

Getting Started

Adding an MCP server to Claude Code takes just a few configuration lines. Servers are defined in settings files or .mcp.json and started automatically when Claude Code launches. Environment variables use the ${VAR_NAME} syntax for secure credential injection.

// .mcp.json - Project MCP configuration (committed to repo)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${DATABASE_URL}"
      }
    },
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Install and test a server manually before adding it to your configuration. Use /mcp commands to manage servers at runtime.

# Test a server locally
npx -y @modelcontextprotocol/server-github

# Add a server via Claude Code CLI
/mcp add github npx -y @modelcontextprotocol/server-github

# Check status of all connected servers
/mcp status

# Remove a server
/mcp remove github

# Restart Claude Code to pick up config changes
# Or use /mcp to hot-reload individual servers

Build your first custom MCP server using the TypeScript SDK. A minimal server that exposes a single tool takes about 30 lines of code.

// my-server.ts - Custom MCP server (TypeScript)
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from
  "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server({
  name: "my-tools",
  version: "1.0.0"
}, {
  capabilities: { tools: {} }
});

server.setRequestHandler("tools/list", async () => ({
  tools: [{
    name: "greet",
    description: "Generate a greeting",
    inputSchema: {
      type: "object",
      properties: {
        name: { type: "string", description: "Name to greet" }
      },
      required: ["name"]
    }
  }]
}));

server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name === "greet") {
    const name = req.params.arguments.name;
    return {
      content: [{ type: "text", text: `Hello, ${name}!` }]
    };
  }
});

const transport = new StdioServerTransport();
await server.connect(transport);

Here is the equivalent server using the Python SDK with the FastMCP high-level API.

# my_server.py - Custom MCP server (Python)
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-tools")

@mcp.tool()
def greet(name: str) -> str:
    """Generate a greeting for the given name."""
    return f"Hello, {name}!"

@mcp.tool()
def calculate_age(birth_year: int) -> str:
    """Calculate age from birth year."""
    from datetime import datetime
    age = datetime.now().year - birth_year
    return f"Approximately {age} years old"

@mcp.resource("config://app")
def get_config() -> str:
    """Expose application config as a resource."""
    import json
    return json.dumps({
        "version": "1.0.0",
        "environment": "production"
    })

if __name__ == "__main__":
    mcp.run()

Advanced Techniques

Multi-Server Orchestration

Connect multiple MCP servers and let the AI agent compose tool calls across them. A common pattern: read a JIRA ticket (Atlassian server), check the related Git branch (GitHub server), query the database for affected records (PostgreSQL server), and post a summary to Slack (Slack server). The AI agent orchestrates these calls within a single reasoning loop.

// Example: .mcp.json with multi-server stack
{
  "mcpServers": {
    "atlassian": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-atlassian-rovo"],
      "env": {
        "ATLASSIAN_TOKEN": "${ATLASSIAN_TOKEN}",
        "ATLASSIAN_SITE": "mycompany.atlassian.net"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": { "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${DATABASE_URL}" }
    }
  }
}

Remote HTTP-Based Servers

Deploy MCP servers on remote machines for team-wide access. Use SSE or Streamable HTTP transport instead of Stdio. Remote servers support authentication headers, TLS, and load balancing. This is ideal for centralized database access servers, shared API gateways, or compute-intensive tools that need server-grade hardware.

// Remote server configuration via Streamable HTTP
{
  "mcpServers": {
    "company-tools": {
      "type": "streamable-http",
      "url": "https://mcp.internal.company.com/tools",
      "headers": {
        "Authorization": "Bearer ${MCP_AUTH_TOKEN}"
      }
    },
    "analytics": {
      "type": "sse",
      "url": "https://analytics-mcp.company.com/sse",
      "headers": {
        "X-API-Key": "${ANALYTICS_KEY}"
      }
    }
  }
}

Building Stateful Servers

MCP servers can maintain state across tool calls. Use this for connection pooling (databases), session management (authenticated APIs), caching (expensive operations), and transaction coordination. The server process persists for the duration of the Claude Code session, so in-memory state is reliable within a session.

OAuth Flow Implementation

For services requiring OAuth 2.0, implement the authorization flow within your MCP server. On first connection, redirect the user to the authorization URL, capture the callback, exchange for tokens, and store them securely. Implement automatic token refresh to handle expiry transparently. Use environment variables for client IDs and secrets. For enterprise deployments, integrate with identity providers like Okta or Azure AD.

Context-Aware Tool Selection (Deferred Loading)

When running 10+ MCP servers simultaneously, the combined tool descriptions can consume significant context. Use the ToolSearch capability to defer tool loading: servers register their tools by name only, and full schemas (descriptions, parameter definitions) are fetched on-demand when the AI agent decides it needs a specific tool. This keeps the active context lean while maintaining access to the full tool ecosystem.

Enterprise Governance: Allowlists and Denylists

Organizations can enforce MCP server policies through managed configurations. Allowlists restrict agents to only approved servers, preventing unauthorized data access. Denylists block specific servers known to be risky or non-compliant. These policies are enforced at the enterprise settings level and cannot be overridden by user or project configurations. Audit logs capture every server connection and tool invocation for compliance reporting.

MCP Apps: Interactive UI in AI Conversations

MCP Apps is the first official MCP extension, released as GA in January 2026. It enables MCP tools to return interactive UI components -- dashboards, forms, visualizations, charts, and multi-step workflows -- that render directly inside the AI conversation. Instead of tools returning only text, they can now point to rich, interactive web UIs that users interact with inline.

The architecture introduces a ui:// URI scheme for UI resources. When a tool includes a _meta.ui.resourceUri field in its response, the host client (Claude Code, Claude Desktop, VS Code, etc.) fetches the referenced UI resource and renders it in a sandboxed iframe. The UI and host communicate via JSON-RPC 2.0 over the postMessage API, allowing the app to request tool calls, send messages, update the model's context, and receive data from the host.

MCP Apps differ from regular MCP tools in a fundamental way: regular tools return structured data (text, JSON) that the AI interprets and presents as text. MCP Apps return pointers to interactive UIs that the user can directly manipulate -- clicking buttons, filling forms, rotating 3D models, panning maps, or editing spreadsheets. The AI still orchestrates tool calls, but the user experience becomes visual and interactive rather than purely conversational.

Example Use Cases

How It Works: Tool with UI Resource

// MCP server exposing a tool with an MCP App UI
server.setRequestHandler("tools/list", async () => ({
  tools: [{
    name: "show_dashboard",
    description: "Display an interactive metrics dashboard",
    inputSchema: {
      type: "object",
      properties: {
        metric: { type: "string", description: "Metric to display" }
      }
    }
  }]
}));

server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name === "show_dashboard") {
    return {
      content: [{ type: "text", text: "Dashboard ready." }],
      _meta: {
        ui: { resourceUri: "ui://my-server/dashboard" }
      }
    };
  }
});

// The UI resource (served via ui:// scheme) contains
// bundled HTML/JS that renders in a sandboxed iframe.
// The app communicates with the host via JSON-RPC 2.0
// over postMessage for tool calls and context updates.

All UI content runs in sandboxed iframes with restricted permissions. The iframe cannot access the parent window or make arbitrary network requests. All communication between the UI and host goes through loggable JSON-RPC messages, ensuring security and auditability.

MCP Server Cards

MCP Server Cards are a standard for exposing structured server metadata via a .well-known/mcp.json URL. When a browser, crawler, or MCP registry visits a domain, it can discover available MCP servers, their capabilities, transport endpoints, and authentication requirements from a single well-known URL. This enables automated server discovery, registry indexing, and browser-based MCP client integration without manual configuration.

A Server Card includes the server name, description, version, list of tools with descriptions, supported transport modes, authentication requirements, and contact information. Organizations can publish Server Cards for their internal MCP servers, making them discoverable by any compliant client. This is the MCP equivalent of OpenAPI specifications for REST APIs.

Elicitation

Elicitation allows MCP servers to request structured user input mid-task via interactive dialogs. When a server needs additional information to complete a tool call -- a confirmation, a choice from a set of options, or freeform input -- it can send an elicitation request back to the client. The client renders the appropriate UI (a confirmation dialog, dropdown, text field, or form) and returns the user's response to the server.

This enables multi-step workflows where the server drives the interaction: a deployment tool can ask "Deploy to staging or production?", a database tool can request confirmation before destructive operations, and a form-filling tool can collect structured data field by field. Elicitation makes MCP servers interactive rather than purely request-response, enabling richer human-in-the-loop automation.

MCP v2.1 Specification and 2026 Roadmap

The MCP v2.1 specification (March 2026) introduces RFC 8707-compliant resource indicators to prevent token mis-redemption attacks -- a critical security enhancement for OAuth-authenticated servers. This mandates that authorization servers validate which specific resource a token was issued for, preventing tokens issued for one MCP server from being used on another.

The 2026 roadmap is organized around four priority areas driven by Working Groups and Spec Enhancement Proposals (SEPs): (1) Transport Evolution -- evolving Streamable HTTP to run statelessly across multiple server instances behind load balancers; (2) Agent Communication -- closing lifecycle gaps in the Tasks primitive (retry semantics, expiry policies), with deliberate alignment to the A2A Protocol so MCP tools and A2A agents share compatible task models; (3) Governance Maturation -- Working Groups and Interest Groups as the primary vehicle for protocol development; (4) Enterprise Readiness -- audit trails, SSO-integrated auth, gateway behavior, and configuration portability.

Server Cards are now part of the v2.1 spec, standardized as a .well-known URL for automated discovery. Production benchmarks show MCP servers handling over 10,000 concurrent connections with sub-50ms response times under typical workloads.

The governance structure continues to mature with key leadership appointments. On April 8, 2026, Den Delimarsky (Anthropic) joined as Lead Maintainer and Clare Liguori (AWS) joined as Core Maintainer, complementing Peter Alexander (Anthropic) who joined as a maintainer in January 2026. This multi-organization maintainer team ensures the protocol evolves with input from both the original creators and major adopters, reinforcing MCP's vendor-neutral governance model.

The 2026 roadmap priorities are being refined through active Working Groups: transport scalability (running Streamable HTTP statelessly behind load balancers with session affinity), agent communication and composability (enabling MCP servers to call other MCP servers, creating composable tool chains), governance formalization (Working Groups and Interest Groups as the canonical vehicle for spec changes), and enterprise readiness (audit logging, SSO-integrated OAuth, and configuration portability across environments).

The next specification release is targeted for June 2026. Draft v1.27 is currently in community review, with proposed changes addressing session resumption across server restarts, standardized error taxonomies, and improvements to the elicitation flow for interactive tool parameters. The community review process runs through the open GitHub repository, where any implementer can file feedback on proposed Spec Enhancement Proposals (SEPs) before ratification.