MCPGuide
MCP Servers: The Complete Guide to Building, Deploying & Securing Model Context Protocol Servers
What an MCP server is, how it works, and how to build, deploy, and secure one. A complete developer guide to Model Context Protocol server architecture, transports, and enterprise governance.
Agen.co
12 min read
An MCP server is a lightweight program that exposes your tools, data, and capabilities to AI applications through the Model Context Protocol (MCP), a standardized, open protocol often described as a "USB-C port for AI." Instead of building a custom integration for every model and every data source, you build one MCP server and any MCP-compatible AI agent can use it.
This guide is written for developers, AI and platform engineers, and the security and platform teams who have to stand behind what those engineers ship. It covers the full lifecycle of an MCP server: what it is, how it is architected, how to build, deploy, and host one, and the part most guides skip, which is how to secure and govern it. Because the moment you expose an MCP server, you have created a new piece of production infrastructure and a live access boundary into your systems. It deserves the same rigor you would give any privileged API.
Key takeaways
An MCP server exposes tools (actions), resources (data), and prompts (templates) to AI clients over the Model Context Protocol.
MCP solves the M×N integration problem: build one server, connect to many AI apps (M+N instead of M×N integrations).
Servers communicate using JSON-RPC 2.0 over one of three transports: stdio (local), Streamable HTTP (recommended for remote), and SSE (legacy, deprecated).
An MCP server is an access surface. Authentication, least privilege, gateways, and audit logging are not optional in production.
What is an MCP server?
An MCP server is a service that implements the Model Context Protocol to make a specific set of capabilities available to AI applications. Those capabilities fall into three categories: actions the AI can take, data it can read, and reusable prompt templates. A GitHub MCP server might let an agent open pull requests and read issues. A database MCP server might let it run read-only queries. A filesystem MCP server might let it list and read files.
MCP was open-sourced by Anthropic in late 2024, and it has since been adopted broadly across the AI ecosystem. The protocol is intentionally model-agnostic and vendor-neutral, so a server you write once works with any MCP-compatible client. For the protocol itself, see our companion guide to the Model Context Protocol, and for a focused definition of the server specifically, see what an MCP server is.
MCP server vs MCP client vs host
People often blur these three roles. They are distinct:
Role | What it is | Example |
|---|---|---|
Host | The AI application the user interacts with; it manages one or more clients. | An IDE assistant, a chat app, an agent runtime |
Client | A connector inside the host that maintains a 1:1 connection to a single server. | The host''s MCP client for the GitHub server |
Server | The program that exposes tools, resources, and prompts. | GitHub MCP server, database MCP server |
In short: the host runs the model and orchestrates, the client speaks the protocol, and the server provides the capabilities.
Why MCP servers matter
Before MCP, connecting an AI model to external tools meant building bespoke integrations. If you had M AI applications and N tools, you faced up to M×N custom integrations, each with its own auth, schema, and quirks. MCP collapses that to M+N. Each AI app implements MCP once, each tool exposes an MCP server once, and they interoperate.
That standardization is why MCP servers matter to three audiences at once:
Developers get a reusable, portable way to expose a capability. Write the server once, use it everywhere.
AI and platform teams get a consistent way to give agents real capabilities instead of brittle, one-off plugins.
Security and platform teams get a single, inspectable boundary to authenticate, scope, and audit, provided they treat it as one.
That last point is agen.co''s point of view, and it runs through this entire guide. An MCP server is not just a connector. It is the gateway through which autonomous agents reach your data and act on your systems. Capability and exposure arrive together.
How an MCP server works (architecture)
MCP follows a client-server architecture. A host application creates one MCP client per server, and each client maintains a dedicated connection to its server. Underneath, the protocol is defined in two layers.
The data layer (JSON-RPC 2.0 and lifecycle)
The data layer defines what is communicated. It uses JSON-RPC 2.0 as the message format and specifies:
Lifecycle management: how a client and server initialize, negotiate capabilities, and shut down.
Primitives: the tools, resources, and prompts a server exposes (covered next), plus the requests and responses to list and invoke them.
Notifications: server-to-client messages about changes, such as a tool list updating at runtime.
The transport layer
The transport layer defines how those JSON-RPC messages travel between client and server, over a local pipe or over HTTP. The transport is independent of the data layer, which is why the same server logic can run locally during development and remotely in production. Transports are important enough to get their own section below.
Layer | Responsibility | Key elements |
|---|---|---|
Data layer | What is exchanged | JSON-RPC 2.0, lifecycle, tools/resources/prompts, notifications |
Transport layer | How it is exchanged | stdio, Streamable HTTP, SSE (legacy) |
Core MCP server primitives: tools, resources, and prompts
Everything an MCP server offers is expressed through three primitives. Understanding the difference is the single most useful mental model for working with MCP.
Primitive | What it does | Who controls it | Example |
|---|---|---|---|
Tools | Executable functions the AI can invoke to take an action or compute something. | Model-driven (the AI decides to call) | create_issue, run_query, send_email |
Resources | Read-only data the AI can retrieve for context; returns data, does not execute side effects. | Application-driven | A file''s contents, a database record, a document |
Prompts | Reusable templates and workflows that structure how the model and server interact. | User-driven | A "summarize this PR" template |
A fourth concept, notifications, lets the server proactively tell the client when something changes, for example that the available tools have updated. For a deeper look at the action primitive specifically, including schemas and invocation, see our guide to MCP tools.
MCP server transports: stdio, Streamable HTTP, and SSE
An MCP server speaks JSON-RPC over a transport. There are three, and choosing the right one is mostly a question of where the server runs and who needs to reach it.
Transport | How it works | Best for | Status |
|---|---|---|---|
stdio | The client launches the server as a local subprocess and exchanges JSON-RPC over stdin/stdout. | Local development, desktop tools, single-machine use. Supported by every client. | Current |
Streamable HTTP | The server runs as an independent process handling many clients over HTTP POST/GET, optionally streaming responses via SSE. Single endpoint; supports OAuth 2.1. | Remote and shared deployments, web apps, multi-user access, anything needing authentication. | Current, recommended for remote |
SSE (Server-Sent Events) | The original HTTP transport using two endpoints (one to POST, one to stream). | Existing servers only. | Deprecated in favor of Streamable HTTP |
The practical rule of thumb is simple. Start with stdio while you experiment, because it is the simplest and universally supported. Move to Streamable HTTP when you need remote access, multiple users, or authentication. SSE still works for servers that already use it, but new projects should not adopt it.
Local vs remote MCP servers
The transport choice maps directly onto topology. A local MCP server runs on the same machine as the host, usually over stdio. That is great for a developer''s own tools and for accessing local files. A remote MCP server runs as a networked service over Streamable HTTP, reachable by many users and applications, and it is the model you want for any shared, team, or enterprise capability. Remote is also where security stops being optional, because the server is now exposed beyond a single trusted machine.
MCP server vs API (and vs skills and plugins)
A common question is whether MCP servers replace APIs. They do not. MCP is a standard contract for AI tool use. An MCP server very often sits in front of an existing REST or GraphQL API and translates it into the tools, resources, and prompts an agent can discover and call.
Traditional API | MCP server | |
|---|---|---|
Consumer | Code written by a developer | An AI model/agent at runtime |
Discovery | Read docs, hardcode endpoints | Self-describing; the client lists tools/resources at connect time |
Interface | Bespoke per API | Standardized across all servers |
Relationship | n/a | Frequently wraps an API |
"Skills" or "plugins" in some AI products are a related but narrower idea, often vendor-specific. MCP is the open, cross-vendor standard for the same underlying need: giving a model governed access to capabilities.
How to build an MCP server
You do not need to implement the protocol by hand. Official SDKs exist for popular languages (TypeScript, Python, and others) and handle the JSON-RPC, lifecycle, and transport plumbing. At a high level, building an MCP server follows the same lifecycle regardless of language:
Define the capabilities. Decide which tools (actions), resources (data), and prompts you will expose, and just as importantly which you will not. Scope is a security decision as much as a product one.
Pick an SDK and language. Use an official MCP SDK so lifecycle and transport are handled for you.
Implement the primitives. Write each tool with a clear name, description, and typed input schema; expose resources with stable identifiers; define any prompt templates.
Choose a transport. stdio for local, Streamable HTTP for remote (see above).
Test with a real client. Connect from an MCP-compatible host and confirm the client can list and invoke each capability.
Harden it. Add authentication, validate every input, enforce least privilege, and add logging before anyone but you can reach it.
For team and enterprise deployments, treat steps 1 and 6 as the most important. The capabilities you expose define the blast radius, and the hardening is what keeps an agent, or an attacker who reaches the agent, from turning a useful server into a liability.
Deploying and hosting MCP servers
How you host an MCP server depends on who needs to reach it.
Local (stdio). The host launches the server on demand. No network exposure, no separate hosting. Ideal for individual developer tooling.
Remote (Streamable HTTP). The server runs as a long-lived service, such as a container, a serverless function, or a managed platform, reachable over HTTPS. This is what you deploy for shared and production use.
Self-hosted vs managed. Self-hosting gives maximum control over data residency and network placement. Managed MCP hosting trades some control for less operational overhead.
Private and enterprise MCP servers. For internal tools, keep servers on a private network and front them with authentication and access control so only authorized agents and users can connect.
As soon as you move beyond a single developer''s machine, hosting decisions become governance decisions. Network placement, who can connect, and how connections are authenticated and logged all matter. That is the bridge into security.
MCP server security and governance
This is the section most MCP explainers skim, and it is the one that matters most in production. An MCP server is a privileged access boundary. It lets a non-deterministic AI agent take real actions and read real data. Treat it accordingly.
Common MCP server security risks
Risk | What it means |
|---|---|
Tool poisoning | A malicious or compromised tool description manipulates the model into harmful behavior. |
Prompt injection | Untrusted content the agent reads (a resource, a web page) carries hidden instructions that hijack the agent. |
Credential exposure | Tokens and secrets the server holds leak through logs, errors, or over-broad tool outputs. |
Malicious or fake servers | An agent is pointed at a server that impersonates a trusted one or quietly exfiltrates data. |
Over-broad scopes | A server granted more access than it needs widens the blast radius if anything goes wrong. |
For a full treatment of these, see our deep dives on MCP security and the most common MCP security risks.
How to secure an MCP server
Authenticate every connection. Use OAuth 2.1 (supported by Streamable HTTP) for remote servers, and never leave a remote server open. See MCP authentication.
Enforce least privilege. Expose the narrowest set of tools and scopes the use case requires, and apply fine-grained MCP access control.
Validate and filter calls. Validate every tool input and filter or rate-limit dangerous calls.
Audit and monitor. Log every invocation with enough context to answer "which agent did what, when", and watch for anomalies.
Vet third-party servers. Treat any server you did not write as untrusted until reviewed, and prefer known sources.
Governing MCP servers at scale
One MCP server is manageable. A fleet of them, across teams, vendors, and environments, is a governance problem. The pattern most enterprises converge on is to put a control point in front of every server:
An MCP gateway centralizes authentication, authorization, policy, and audit logging across all your MCP servers, so security is enforced in one place rather than reimplemented in each server.
An MCP proxy sits in the connection path to inspect, route, and control traffic.
Identity and access control bind each connection to a real principal and the least privilege it needs.
Securing MCP servers with agen.co. agen.co provides an MCP gateway, authentication, and access control purpose-built for MCP. It is a single place to authenticate agents, enforce least-privilege access, filter calls, and audit every action across your MCP servers. If you are moving MCP from a prototype to production, this is the layer that makes it safe to do so.
MCP server use cases and examples
MCP servers already exist for a wide range of systems. A few representative categories:
Developer tooling: GitHub, GitLab, filesystem, and CI/CD servers that let agents read code, open PRs, and run pipelines. See the GitHub MCP server.
Data and analytics: database, Snowflake, and BI servers for read access and queries.
SaaS connectors: Slack, Salesforce, Stripe, and dozens more that bring everyday business systems to agents. See the Slack, Salesforce, and Stripe MCP servers.
Browser automation: Playwright MCP for AI-driven browsing and testing.
To discover and evaluate existing servers, browse a curated MCP catalog, and explore the full directory of pre-built connectors in our MCP gateway directory.
MCP server best practices
Scope minimally. Expose only the tools and data a use case needs.
Authenticate every remote connection (OAuth 2.1) and never expose an unauthenticated server.
Validate all inputs and define clear, typed schemas for every tool.
Prefer Streamable HTTP over SSE for new remote servers, and use stdio for local.
Log every invocation and monitor for anomalies.
Vet third-party servers before connecting agents to them.
Put a gateway in front of your servers to centralize auth, policy, and audit.
MCP servers and the wider agent ecosystem
MCP governs how an agent connects to tools and data. A related protocol, A2A (agent-to-agent), governs how agents talk to each other. They are complementary, not competing, and many architectures use both. For the distinction, see MCP vs A2A.
Frequently asked questions
What is an MCP server?
An MCP server is a program that exposes tools, data, and prompt templates to AI applications through the Model Context Protocol, so any compatible AI client can use those capabilities through a standard interface.
What is the difference between an MCP server and an API?
An API is consumed by code a developer writes. An MCP server is consumed by an AI model at runtime and is self-describing, so the client discovers its tools automatically. An MCP server often wraps an existing API rather than replacing it.
What is the difference between an MCP client and an MCP server?
The client lives inside the AI host application and maintains a connection to one server. The server provides the tools, resources, and prompts. One host can run many clients, each connected to a different server.
What are MCP tools, resources, and prompts?
Tools are executable actions the AI can invoke, resources are read-only data it can retrieve for context, and prompts are reusable templates that structure interactions. Together they are the three primitives every MCP server exposes.
What is the difference between a local and a remote MCP server?
A local server runs on the same machine as the host (usually over stdio) and is ideal for personal tooling. A remote server runs as a networked service over Streamable HTTP and is what you deploy for shared, multi-user, or enterprise use.
Which MCP transport should I use, stdio, Streamable HTTP, or SSE?
Use stdio for local development, Streamable HTTP for any remote or multi-user deployment (it supports OAuth 2.1), and avoid SSE for new projects, since it is deprecated in favor of Streamable HTTP.
How do I build an MCP server?
Use an official MCP SDK, define your tools, resources, and prompts, choose a transport, test with a real client, and harden it with authentication, input validation, least privilege, and logging before exposing it.
Are MCP servers safe? What are the main security risks?
MCP servers are safe when secured properly, but they are a privileged access surface. The main risks are tool poisoning, prompt injection, credential exposure, malicious or fake servers, and over-broad scopes.
How do I secure an MCP server?
Authenticate every connection, enforce least privilege, validate and filter calls, audit every invocation, vet third-party servers, and put a gateway in front of your servers to enforce policy centrally.
What are some examples of MCP servers?
Common examples include GitHub, filesystem, database, Slack, Salesforce, Stripe, and Playwright servers, spanning developer tooling, data, SaaS connectors, and browser automation.
Related resources
Written by
Agen.co
Keep reading
More from MCP
MCP
Keon Armin·
What is MCP (Model Context Protocol)? A Complete Guide
Learn what MCP is, how it works, its architecture, key concepts like tools and resources, security risks, and how to get started building with it.
Keon Armin·MCPKeon Armin·
MCP Security: Risks, Best Practices & Enterprise Guide
What is MCP security? Learn the top risks - prompt injection, token theft, supply chain attacks, and enterprise best practices to secure AI agent tool calls.
Keon Armin·MCPKeon Armin·
MCP Security Risks: Complete Guide for 2026
Understand the top MCP security risks threatening AI agent deployments. Learn about prompt injection, tool poisoning, privilege abuse, and how to mitigate each.
Keon Armin·