MCP Servers Explained: Model Context Protocol for AI Agents (2026)

Model Context Protocol (MCP) is the 2026 standard for connecting AI agents and chatbots to external tools, data sources and services. Designed by Anthropic and now supported by Claude, OpenAI's ChatGPT, AWS Bedrock AgentCore and Microsoft Copilot, MCP defines a small protocol (JSON-RPC over stdio or HTTP) that lets any AI client discover and invoke capabilities from any MCP-compliant server — without each integration being hand-coded. If REST APIs let any web client talk to any web server, MCP is the equivalent for AI agents talking to tools. This guide explains what MCP is, why it matters in 2026, and how to build a production MCP server.

What MCP actually is

MCP is a small JSON-RPC protocol that defines three primitive concepts: (1) tools — actions the AI client can invoke (search a database, send an email, file a ticket); (2) resources — data the AI client can read (files, database rows, API responses); (3) prompts — reusable prompt templates the server provides. A client (Claude Desktop, ChatGPT, Bedrock AgentCore, Cursor, Continue, custom agent) connects to a server over stdio (local process) or HTTP/SSE (remote service). The client lists available tools/resources/prompts and the LLM decides which to invoke based on the user's request.

The key insight: MCP standardises the *interface* between AI agents and tools, so the same Salesforce integration written once works with Claude, GPT, Bedrock and any other MCP-compatible client. Before MCP, every agent framework (LangChain, CrewAI, AgentCore, OpenAI Functions) had its own tool-definition format and runtime — porting a tool from one to another was effectively a rewrite. MCP eliminates that fragmentation.

Why MCP matters in 2026

• ›Vendor-agnostic AI integrations — write a CRM connector once, ship it to Claude, ChatGPT, Bedrock and any future AI client.
• ›Faster agent development — instead of building tool integrations from scratch, agents can use existing MCP servers (filesystem, GitHub, Slack, PostgreSQL, Stripe and dozens more are publicly available).
• ›Cleaner separation of concerns — AI clients handle reasoning, MCP servers handle tool execution. The same separation that REST APIs brought to web development.
• ›Auditable and secure — MCP servers control what tools the AI can call, with explicit capability declarations. You decide what the agent can touch.
• ›Local-first or remote — MCP servers can run locally (stdio) for developer tools or remotely (HTTP/SSE) for production multi-user services.

Building an MCP server — the architecture

A minimal MCP server has three responsibilities: (1) advertise capabilities (which tools, resources, prompts it provides), (2) handle invocations (when the AI client calls a tool, execute it and return the result), and (3) negotiate connection lifecycle (initialise, shutdown). The official SDKs (TypeScript, Python) handle most of the protocol plumbing — you provide the tool definitions and implementations.

Production MCP servers add: authentication (OAuth 2.1 for remote servers, environment variables for local), rate limiting per client, audit logging of every tool invocation, scoped permissions (which tools each authenticated client can call), error handling that doesn't leak internals to the LLM, and observability (Datadog, Langfuse, Helicone). For high-stakes tools (write actions, financial transactions) we add human-in-the-loop checkpoints — the MCP server returns a 'confirmation required' state and the client surfaces it to a human approver.

When to build a custom MCP server vs use an existing one

Existing MCP servers (filesystem, GitHub, Slack, Postgres, Stripe, Notion, Linear, Sentry and many more) cover most common integrations. Build a custom MCP server when you have proprietary internal APIs, business logic the LLM should call (your CRM, your billing system, your internal microservices), or compliance requirements that need server-controlled access patterns the public servers don't offer.

Frequently asked questions

Is MCP a standard, or just Anthropic's protocol?

MCP started at Anthropic in late 2024 but is now supported by OpenAI's ChatGPT, AWS Bedrock AgentCore, Microsoft Copilot, plus IDE tools like Cursor, Continue, and Zed. The spec is open and has multiple production implementations. In 2026 it's effectively a de facto standard for AI-tool integration — comparable to how HTTP became the standard for web APIs in the 1990s.

How is MCP different from OpenAI Functions or LangChain tools?

OpenAI Functions and LangChain tools are agent-framework-specific tool definitions — they only work inside that framework. MCP is a separate protocol that any agent framework can speak. In practice, modern frameworks now bridge to MCP — LangChain has an MCP adapter, AgentCore natively speaks MCP, OpenAI's Assistants API can call MCP servers. MCP becomes the lower-level protocol; frameworks become MCP clients.

Can MCP servers be hosted remotely or only locally?

Both. The spec supports stdio (local subprocess, used by Claude Desktop and Cursor for filesystem and IDE integrations) and HTTP/SSE (remote, used for multi-tenant production services). Remote MCP servers add OAuth 2.1 authentication, scoped permissions and multi-tenant data isolation. For enterprise use cases — connecting your AI agent fleet to internal CRM/ERP/helpdesk — remote MCP servers are the right pattern.

How do we secure an MCP server?

Five layers. (1) Authentication — OAuth 2.1 for remote servers, API keys or environment-scoped credentials for local. (2) Authorization — scoped tool permissions per authenticated client (the marketing-bot can read but not delete). (3) Rate limiting per client to prevent abuse. (4) Audit logging of every tool invocation with full input/output context. (5) Human-in-the-loop checkpoints for high-impact tools (the MCP server can require confirmation before executing write actions). We design all five into every production MCP server we build.

Should we build MCP servers for our internal APIs?

Yes, if you're deploying AI agents that need to interact with those APIs. Building an MCP server in front of your existing REST or GraphQL API is the cleanest way to expose business logic to AI agents without giving them raw API credentials. Typical build: 1–3 weeks for a server exposing 5–15 tools on an existing internal API. The MCP server enforces scoped permissions, audit logging and rate limiting that the underlying API may not.

What MCP servers exist that we can use out of the box?

The official MCP servers repository and Anthropic's directory list dozens — filesystem, GitHub, GitLab, Slack, Postgres, MySQL, SQLite, Google Drive, Notion, Linear, Sentry, Brave Search, Memory, Time, Sequential Thinking, EverArt, AWS knowledge bases. Most are MIT-licensed and production-ready. We'd typically use 5–15 existing servers per agent stack and build 1–5 custom servers for proprietary integrations.

Does AWS Bedrock AgentCore support MCP?

Yes — AgentCore added MCP client support in 2026 and can invoke MCP servers as tools alongside its native Lambda-based tool definitions. This is one reason we standardise on Bedrock + AgentCore for production agents: it speaks MCP natively, so tool integrations are portable across the agent stack rather than locked to AgentCore's proprietary format.