MCP (Model Context Protocol) Explained: The New Standard for AI Tool Integration

MCP is the most important infrastructure development in AI since function calling. That's a strong claim, but after building MCP servers for production systems and integrating MCP-based tool access into agentic workflows across 10+ client projects, we're confident it's accurate.

The core insight behind MCP is simple: every AI tool integration is currently built as a custom, one-off connector. When you want Claude to query your database, you build a Claude-specific tool. When you want GPT to do the same thing, you build a different GPT-specific tool. When you switch from LangChain to Mastra, you rebuild all your tools again.

MCP eliminates this by defining a universal protocol for AI-to-tool communication. Build your tool once as an MCP server, and any MCP-compatible AI client can use it.

The problem MCP solves

Before MCP: the N×M integration nightmare

In a typical AI-powered application, you have:

• N AI models (Claude, GPT, Gemini, Llama, Mistral)
• M tools and data sources (databases, APIs, file systems, SaaS apps)

Without MCP, you need N×M integrations. Each model has its own function calling format, its own tool definition schema, and its own way of handling tool results. When OpenAI updates their function calling API (which they've done 4 times since 2023), every tool breaks.

For a company with 5 data sources and 3 AI models, that's 15 custom integrations to build and maintain. For an enterprise with 50 data sources, it's hundreds.

After MCP: the universal adapter

MCP reduces N×M to N+M. Each AI client implements MCP client support once. Each tool implements MCP server support once. Any client can connect to any server through the standard protocol.

Without MCP:
Claude ←→ Database tool (Claude format)
GPT    ←→ Database tool (GPT format)
Gemini ←→ Database tool (Gemini format)
Claude ←→ Slack tool (Claude format)
GPT    ←→ Slack tool (GPT format)
Gemini ←→ Slack tool (Gemini format)
= 6 integrations for 3 models × 2 tools

With MCP:
Claude ←→ MCP ←→ Database MCP server
GPT    ←→ MCP ←→ Database MCP server
Gemini ←→ MCP ←→ Slack MCP server
= 3 client implementations + 2 server implementations = 5 total

The savings scale dramatically with more models and more tools.

How MCP works: the architecture

MCP follows a client-server architecture with three core components:

1. MCP hosts (the AI application)

The host is the AI application that the user interacts with — Claude Desktop, Cursor, a custom chatbot, or any application that embeds AI capabilities. The host manages the connection between the AI model and MCP servers.

2. MCP clients (the protocol handler)

Each host contains one or more MCP clients. A client maintains a 1:1 connection with an MCP server, handles the protocol communication (JSON-RPC over stdio or HTTP+SSE), and translates between the model's internal tool representation and MCP's standard format.

3. MCP servers (the tool provider)

MCP servers expose tools, resources, and prompts to clients. A server can be:

• A local process running on the user's machine (e.g., a file system server that gives the AI access to local files)
• A remote service accessible over HTTP (e.g., a Slack MCP server that reads and sends messages)
• A database connector that translates natural language queries into SQL

Each server declares its capabilities — what tools it offers, what resources it can provide, and what prompts it supports.

The three primitives

MCP defines three types of capabilities that a server can expose:

Tools — Functions the AI can call. Similar to OpenAI function calling, but with a standardized schema. Examples: query_database, send_slack_message, create_github_issue, read_file.

Resources — Data the AI can access. Unlike tools (which do something), resources provide context. Examples: a file's contents, a database schema, a Slack channel's message history. Resources are identified by URIs (file:///path/to/file, slack://channel/general).

Prompts — Reusable prompt templates that servers can provide. A database MCP server might provide a "analyze_table" prompt template that structures the right questions for data analysis. Prompts help the AI use the server's tools more effectively.

Building an MCP server: practical walkthrough

Let's walk through building an MCP server that wraps a common use case — giving an AI agent access to a PostgreSQL database.

The TypeScript approach

Using the official @modelcontextprotocol/sdk package:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import pg from 'pg'

const server = new McpServer({
  name: 'postgres-server',
  version: '1.0.0',
})

const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
})

// Expose a tool for running read-only SQL queries
server.tool(
  'query',
  'Run a read-only SQL query against the database',
  {
    sql: { type: 'string', description: 'The SQL query to execute (SELECT only)' },
  },
  async ({ sql }) => {
    // Safety: only allow SELECT queries
    if (!sql.trim().toUpperCase().startsWith('SELECT')) {
      return { content: [{ type: 'text', text: 'Error: Only SELECT queries are allowed' }] }
    }

    const result = await pool.query(sql)
    return {
      content: [{ type: 'text', text: JSON.stringify(result.rows, null, 2) }],
    }
  }
)

// Expose the database schema as a resource
server.resource(
  'schema',
  'postgres://schema',
  async () => {
    const result = await pool.query(`
      SELECT table_name, column_name, data_type
      FROM information_schema.columns
      WHERE table_schema = 'public'
      ORDER BY table_name, ordinal_position
    `)
    return {
      contents: [{
        uri: 'postgres://schema',
        text: JSON.stringify(result.rows, null, 2),
        mimeType: 'application/json',
      }],
    }
  }
)

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

This MCP server gives any MCP-compatible AI client the ability to:

1. Read the database schema (to understand what tables and columns exist)
2. Run SELECT queries (to answer questions about the data)

The AI can now answer questions like "How many orders were placed last month?" by reading the schema, writing a SQL query, and executing it — all through the standard MCP protocol.

Security considerations for MCP servers

MCP servers have direct access to your data and systems. Security isn't optional:

Authentication: Production MCP servers should require authentication. The MCP spec supports OAuth 2.0 flows and API key authentication. Don't deploy an MCP server that gives unauthenticated access to your database.

Authorization: Implement fine-grained permissions. Different users should have access to different tools and data. A sales rep's MCP session shouldn't have access to the HR database.

Input validation: Every tool input should be validated before execution. SQL injection through an MCP tool is a real risk — use parameterized queries, not string concatenation.

Read vs. write separation: For most use cases, MCP servers should be read-only by default. Write operations (updating records, sending messages, creating issues) should require explicit user confirmation through the MCP protocol's confirmation flow.

Audit logging: Log every tool call with the requesting user, the input, the output, and the timestamp. This is essential for security monitoring and debugging.

MCP in production: what we've learned

Lesson 1: Tool design matters more than protocol implementation

The MCP protocol is well-designed and the SDKs handle the implementation details. What determines success or failure is how you design the tools themselves.

Good tool design:

• Each tool does one thing clearly
• Tool descriptions are specific enough for the AI to know when to use them
• Input parameters have clear types and descriptions
• Error responses are informative (not just "error occurred")
• Tools have reasonable timeout limits

Bad tool design:

• Tools that try to do too much (a single "database" tool that handles queries, schema inspection, and data modification)
• Vague descriptions ("interact with the system")
• Missing parameter descriptions (the AI guesses what to pass)
• Tools that silently fail or return ambiguous results

Lesson 2: Resource exposure is as important as tool definition

Tools let the AI do things. Resources let the AI understand context. In our experience, the ratio should be roughly 1:1 — for every tool you expose, expose a corresponding resource that helps the AI use the tool effectively.

A database MCP server with a query tool but no schema resource forces the AI to guess table and column names — leading to failed queries and wasted LLM calls. Adding the schema resource gives the AI the context it needs to write correct queries on the first attempt.

Lesson 3: Latency adds up in multi-tool workflows

In an agentic workflow where the AI calls 5-10 MCP tools sequentially, the cumulative latency can exceed 10-30 seconds. Each tool call involves: AI generating the tool call (200-500ms), MCP protocol overhead (50-100ms), tool execution (variable — 10ms to 5s), and AI processing the result (200-500ms).

Optimization strategies:

• Keep tool execution fast (cache database queries, pre-compute resource data)
• Design tools to return focused results (not the entire table, just the relevant rows)
• Enable parallel tool calling when tools are independent (the MCP protocol supports this)

Lesson 4: MCP server lifecycle management needs attention

In production, MCP servers need to be:

• Started reliably (auto-restart on crash, health checks)
• Updated without downtime (graceful shutdown, connection draining)
• Monitored (uptime, error rates, latency, resource usage)
• Scaled (multiple instances behind a load balancer for remote servers)

For local MCP servers (running on the user's machine), the host application handles lifecycle management. For remote MCP servers (running in your infrastructure), you need the same operational maturity as any production microservice.

The MCP ecosystem in mid-2026

Client support

Client	MCP support	Notes
Claude Desktop	Full (native)	Anthropic's reference implementation
Cursor	Full (native)	Primary tool integration method
Claude Code	Full (native)	CLI and agent support
OpenAI GPTs/agents	Adopted	Added MCP support in 2025
Gemini	Via A2A interop	Google's Agent-to-Agent protocol bridges to MCP
VS Code extensions	Via MCP SDKs	Continue, Cody, and others
Custom applications	Via SDKs	TypeScript, Python, Java SDKs available

Popular MCP servers

The MCP server ecosystem has grown to 1,000+ community-maintained servers. The most popular categories:

Developer tools: GitHub (issues, PRs, repos), Linear (project management), Jira, GitLab, Sentry (error tracking), Datadog (monitoring).

Communication: Slack (read/send messages, channel management), Discord, Email (IMAP/SMTP).

Databases: PostgreSQL, MySQL, MongoDB, Redis, Supabase, PlanetScale.

Cloud services: AWS, Google Cloud, Azure, Vercel, Cloudflare.

Productivity: Google Workspace (Docs, Sheets, Drive), Notion, Confluence, Obsidian.

Web: Browser automation (Playwright-based), web scraping, URL fetching.

File systems: Local file access, S3, Google Drive, Dropbox.

Building vs. using existing MCP servers

For common integrations (Slack, GitHub, PostgreSQL), use existing community MCP servers. They're battle-tested, well-maintained, and handle edge cases you haven't thought of.

Build custom MCP servers when:

• You need to expose proprietary business logic (your custom CRM, your internal API)
• Existing servers don't cover your use case
• You need fine-grained security controls that community servers don't provide
• Performance requirements exceed what generic servers offer

How MCP changes AI application architecture

Before MCP: tightly coupled tool integrations

A typical pre-MCP AI application defines tools inline with the AI prompt:

const response = await anthropic.messages.create({
  model: 'claude-sonnet-4-6-20260514',
  tools: [
    {
      name: 'query_database',
      description: 'Query the PostgreSQL database',
      input_schema: { /* ... */ }
    },
    {
      name: 'send_slack_message',
      description: 'Send a message to Slack',
      input_schema: { /* ... */ }
    }
  ],
  messages: [{ role: 'user', content: userMessage }]
})

When you add a new tool, you modify the application code. When you change providers, you rewrite the tool definitions. When you want to reuse tools across applications, you copy-paste.

After MCP: loosely coupled, composable tool servers

With MCP, the application discovers tools dynamically from connected servers:

// Connect to MCP servers
const dbServer = await connectMcp('postgres-server')
const slackServer = await connectMcp('slack-server')

// Tools are discovered automatically from server capabilities
const tools = [
  ...dbServer.getTools(),     // query, schema, etc.
  ...slackServer.getTools(),  // send_message, read_channel, etc.
]

// Pass discovered tools to the AI model
const response = await model.chat({
  tools,
  messages: [{ role: 'user', content: userMessage }]
})

Adding a new tool means connecting a new MCP server — no application code changes. Reusing tools across applications means pointing multiple applications at the same MCP server. Changing AI models means changing the model configuration, not the tool integration.

This is the architectural shift that makes MCP important. It separates tool implementation from AI application logic, enabling a component ecosystem similar to what npm did for JavaScript or Docker did for deployment.

Getting started with MCP

For AI application developers

1. Pick a client framework that supports MCP natively (Cursor, Claude Desktop, or build with the MCP SDK)
2. Start with community MCP servers for your most common integrations (database, Slack, GitHub)
3. Build custom MCP servers for your proprietary tools and data
4. Test tool interactions thoroughly — the AI's ability to use tools correctly depends on clear tool descriptions and parameter schemas

For tool/API providers

1. Build an MCP server that wraps your API. Use the TypeScript or Python SDK
2. Publish to the MCP server registry for community discovery
3. Include resources (not just tools) — context helps the AI use your tools more effectively
4. Test with multiple AI clients to ensure compatibility

MCP is still evolving, but the core protocol is stable and adoption is accelerating. If you're building AI applications that need tool access, building on MCP now means your tool integrations will work with every major AI platform — today and as the ecosystem grows.

---

Building MCP servers or integrating MCP into your AI platform? Talk to our AI infrastructure team — we've built MCP servers for databases, CRMs, and custom business logic in production.