Key takeaways

• An MCP server is a lightweight process that exposes tools, resources, and prompts to AI applications over a standardized protocol.
• It acts as the bridge between an LLM-powered client and an external system — a database, API, file system, or SaaS product.
• The protocol standardizes how AI apps discover and invoke capabilities, replacing per-integration custom code.
• MCP servers communicate with MCP clients over a defined transport layer (stdio or HTTP+SSE), not directly with the LLM.
• A single MCP server works well for development; production environments with many servers introduce governance, auth, and routing challenges that require additional infrastructure.

---

What is an MCP server?

You have an AI-powered application that needs to query a database, create a GitHub issue, or pull data from a SaaS tool. Before November 2024, you wrote custom glue code for each integration — one-off adapters with their own schemas, auth flows, and error handling. Every new external system meant another bespoke connector.

An MCP server eliminates that pattern. It is a process that exposes capabilities — tools, resources, and prompts — to AI applications using the [Model Context Protocol (MCP)](https://konghq.com/blog/learning-center/what-is-mcp)Model Context Protocol (MCP), an [open standard](https://www.infoq.com/news/2024/12/anthropic-model-context-protocol/)open standard [introduced by Anthropic in November 2024](https://www.anthropic.com/news/model-context-protocol)introduced by Anthropic in November 2024.

A critical distinction: MCP and MCP server are not synonyms. MCP is the protocol specification — the set of rules governing how AI applications discover and invoke external capabilities. An MCP server is a process that implements the server side of that specification. The relationship is the same as HTTP and a web server: HTTP defines the protocol, Apache or Nginx implements it.

What MCP standardizes is discovery and invocation. Instead of reading API docs, writing integration code, and maintaining per-service adapters, an AI application connects to an MCP server and learns what it can do through capability negotiation. The server declares its tools, resources, and prompts. The client understands how to call them. The protocol handles the rest.

This matters because AI applications need to interact with dozens or hundreds of external systems. Without a standard, each integration is a maintenance burden. With MCP, the integration surface is consistent: one protocol, one discovery mechanism, one invocation pattern.

---

MCP architecture: how servers fit in

MCP defines four components, each with a distinct role:

• Host: The AI application the user interacts with — Claude Desktop, an IDE with AI features, or a custom agent application.
• Client: A protocol connector that lives inside the host. It manages the connection to a specific MCP server.
• Server: The process that exposes capabilities. It runs locally or remotely and responds to client requests.
• Transport: The communication layer between client and server — stdio for local processes, HTTP with Server-Sent Events (SSE) for remote connections.

Here is how a request flows through the system:

1. The host starts one or more MCP clients, each configured to connect to a specific server.
2. Each client establishes a connection to its assigned server over the chosen transport.
3. Capability negotiation occurs: the server declares what tools, resources, and prompts it exposes, and the client and server agree on supported protocol features.
4. The user interacts with the host. The LLM determines it needs to invoke an external tool — for example, querying a database.
5. The client sends a [JSON-RPC request](https://www.jsonrpc.org/specification)JSON-RPC request to the server, specifying the tool name and parameters.
6. The server executes the operation, and returns the result to the client, which passes it back to the host and the LLM.

One detail engineers often miss: the server never talks directly to the LLM. The client mediates all communication. The LLM decides it needs a tool, the host tells the client, and the client talks to the server. This separation keeps the protocol clean and the server implementation simple — it does not need to understand LLM internals.

Each client-server connection is a 1:1 pairing. If a host needs to interact with five external systems, it runs five clients, each connected to one server. The host orchestrates across all of them.

For a detailed reference, the MCP specification and architecture documentation are available at [modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-06-18)modelcontextprotocol.io.

---

What an MCP server exposes

An MCP server declares three types of capabilities, each with a different control boundary. If you want to go deeper and [build an MCP server](https://konghq.com/blog/engineering/mcp-servers-guide)build an MCP server yourself, Kong's developer guide walks through the full implementation.

Tools (model-controlled)

Tools are functions the LLM can invoke autonomously during a conversation. The server describes each tool — its name, parameters, and schema — and the LLM decides when to call it based on context.

Examples:

• query_database(sql) — Execute a SQL query against a connected database.
• create_github_issue(title, body) — Open a new issue in a GitHub repository.
• send_slack_message(channel, text) — Post a message to a Slack channel.

Resources (application-controlled)

Resources are data the host application can fetch to provide context to the LLM. Unlike tools, the LLM does not decide when to retrieve resources — the host does.

Examples:

• File contents from a local or remote file system.
• Database schemas describing table structures and relationships.
• API documentation for a connected service.

Prompts (user-controlled)

Prompts are predefined templates that users explicitly select. They provide structured ways to interact with the server's capabilities.

Examples:

• "Summarize this table" — A prompt template that takes a table name and generates a summary.
• "Explain this table's relationships" — A prompt that describes foreign keys and joins.

Why three types matter

The distinction is not arbitrary. Each type maps to a different control boundary, which directly affects authorization policy.

Tools let the LLM trigger actions autonomously — creating records, sending messages, modifying state. These require the strictest authorization controls because a misconfigured tool could let an LLM execute operations the user never intended.

Resources are read-only context, fetched by the application on behalf of the user. The risk profile is lower, but access still needs governance — not every user should see every database schema.

Prompts are user-initiated and explicit. The user chooses to run them, so the control model is straightforward.

A concrete example ties this together. A PostgreSQL MCP server might expose:

• Tools: query(sql), insert(table, data), update(table, conditions, data)
• Resources: Table schemas, column types, index definitions
• Prompts: "Explain this table's relationships," "Generate a migration for this schema change"

One server, three capability types, three control boundaries.

MCP server vs. REST API

When you need more than one MCP server

Running a single MCP server during development is straightforward. You connect Claude Desktop or Cursor to a local server, test your tools, and iterate. The experience is simple and self-contained.

Production is a different problem. A real deployment might involve dozens of MCP servers — one for each database, SaaS platform, internal service, and third-party API your AI applications need to reach. Each server has its own authentication requirements, rate limits, and access policies.

At this scale, several problems compound:

• Authentication sprawl: Each MCP server manages its own credentials. There is no centralized identity layer, so every server-client connection requires separate auth configuration. Credential rotation becomes a per-server operational task.
• No fleet-wide observability: You cannot see which agents are calling which tools, how often, or with what error rates — unless you instrument each server individually.
• Governance gaps: Who authorized this agent to access production databases? Which teams have access to which MCP servers? Without centralized policy, these questions have no consistent answer.
• Discovery does not scale manually: With five servers, developers can hardcode connection details. With fifty, you need a registry. With hundreds, you need automated discovery.

A pattern emerges here — the same pattern the API industry identified and solved over the past decade. When you have many services behind many endpoints with different auth and different policies, you put a [gateway](https://konghq.com/blog/learning-center/what-is-a-mcp-gateway)gateway in front of them. Centralized authentication, rate limiting, observability, and routing through a single control plane.

Kong builds infrastructure for exactly this problem. [Kong AI Gateway](https://konghq.com/blog/product-releases/enterprise-mcp-gateway)Kong AI Gateway provides centralized authentication, rate limiting, [observability, and governance](https://konghq.com/blog/product-releases/securing-observing-governing-mcp-servers-with-ai-gateway)observability, and governance across MCP servers — the same capabilities Kong has delivered for REST APIs at scale. [Kong MCP Registry](https://developer.konghq.com/konnect-platform/konnect-mcp/)Kong MCP Registry gives agents a centralized catalog to discover approved MCP servers at runtime, replacing hardcoded connections with dynamic, policy-governed discovery. And Kong's MCP Client in Insomnia lets teams test and validate MCP servers before agents consume them in production. For a deeper look at how these components work together, see the [AI Gateway, MCP Gateway, and MCP Server](https://konghq.com/blog/engineering/ai-gateway-mcp-gateway-mcp-server-breakdown)AI Gateway, MCP Gateway, and MCP Server technical breakdown.

This is not a new category of problem. It is the API gateway pattern applied to AI infrastructure. The difference is the consumer: instead of applications calling APIs, agents call MCP servers. The governance requirements — auth, rate limiting, observability, access control — are the same.

---

If you are evaluating MCP for production, explore how Kong governs MCP servers at scale. See the [MCP Gateway report](https://konghq.com/resources/reports/mcp-gateway)MCP Gateway report or learn how [Kong Konnect](https://konghq.com/products/kong-konnect/agents)Kong Konnect provides centralized control for agentic AI infrastructure. Ready to try it? [Get started with Kong MCP](https://developer.konghq.com/mcp/kong-mcp/get-started/)Get started with Kong MCP or [explore the available tools](https://developer.konghq.com/mcp/kong-mcp/tools/)explore the available tools. [Request a demo](https://konghq.com/contact-sales)Request a demo to see how it works in your environment.

---

MCP Server FAQS

What exactly is an MCP server? An MCP server is a process that exposes tools, resources, and prompts to AI applications using the Model Context Protocol. It acts as the interface between an LLM-powered client and an external system like a database, API, or SaaS product.

Why would I need an MCP server? When you want AI applications to interact with external systems through a standard interface instead of writing custom integration code for each connection. MCP servers replace per-service glue code with a single, consistent protocol.

What is the difference between a REST API and an MCP server? A REST API uses custom schemas for application-to-application communication. An MCP server provides a standardized, self-describing interface designed for AI applications, with built-in capability negotiation so clients automatically discover available tools and resources.

Does ChatGPT use MCP? [OpenAI announced MCP support for ChatGPT in March 2025](https://openai.com/index/new-tools-and-features-in-the-responses-api/)OpenAI announced MCP support for ChatGPT in March 2025. Other platforms including Claude, Cursor, and Windsurf also support MCP as a standard protocol for connecting AI applications to external tools.

How is MCP different from tool calling? Tool calling is an LLM feature that lets the model request execution of a specific function. MCP is the standardized protocol that defines how those function calls reach external systems, how capabilities are discovered, and how results are returned. Tool calling is what the LLM does; MCP is how the call gets to the server and back.