What Is an MCP Server? A Practical Guide to Hosts, Clients, and Tools
Learn what an MCP server is, how hosts and clients connect to it, what tools, resources, and prompts it exposes, and how to test one safely.
An MCP server is a program that implements the Model Context Protocol (MCP) and provides an MCP client with discoverable context and capabilities. Depending on what it declares, a server can expose tools, resources, and prompts.
The word server describes the program's role in the protocol. It does not necessarily mean a separate machine or a cloud service. An MCP server can run locally as a subprocess or remotely as a network service.
The most useful mental model is simple: the host is the AI application, the client is the connection managed by that application, and the server is the focused capability provider on the other end.
What is an MCP server?
An MCP server is an integration that speaks MCP rather than a one-off interface designed for a single application. It advertises capabilities in a standard way, including the data it can provide, the operations it can perform, and the prompts it makes available.
For example, a server might connect an AI application to a database. The server owns the database integration and exposes carefully described capabilities. The host remains responsible for coordinating the model, presenting choices to the user, and applying its own consent and permission policies.
This distinction matters because an MCP server is not the model. It does not perform model inference, and the model does not connect directly to it. The host uses an MCP client to manage the connection and route protocol messages.
MCP host vs. client vs. server
An MCP connection has three roles:
AI application (host) → one MCP client connection → MCP server
- Host: The AI application, such as an IDE or chat application. It coordinates model interaction, user consent, and connections to servers.
- Client: A protocol connector created and managed by the host. It negotiates capabilities, routes messages, and maintains the connection to one server.
- Server: The program that supplies the advertised data and operations.
The architecture specifies a one-to-one relationship between one client instance and one server. A host can manage multiple clients, so one application can connect to multiple MCP servers at the same time.
Each connection should be treated as an isolated relationship. A server should not be assumed to see the host's entire conversation or the connections to other servers. Data should cross those boundaries only when the host has an explicit policy for doing so.
Local and remote servers
An MCP server can be deployed in either of two common ways:
- A local server commonly runs as a subprocess launched by the client. The client communicates with it over standard input and standard output, or stdio.
- A remote server commonly exposes an MCP endpoint over Streamable HTTP. It can serve clients over a network.
Neither deployment is more inherently “MCP” than the other. MCP identifies the protocol role and message behavior, not the hosting location, programming language, framework, or process lifetime.
What can an MCP server expose?
MCP calls the main server-side capabilities primitives. Their control models are different, so treating them as interchangeable can lead to incorrect assumptions about what happens automatically.
| Primitive | What it provides | Intended control model | Example |
|---|---|---|---|
| Tools | Schema-described functions that can read data or take actions | Model-controlled, subject to host and user policy | Query a database, create a calendar event, or call an external API |
| Resources | Text or binary context identified by a URI | Application-controlled | File contents, a database schema, or documentation |
| Prompts | Reusable, parameterized messages or instructions | User-controlled | A code-review template or an analysis workflow |
Servers advertise the features they support through capability discovery and negotiation. A client can discover tools with tools/list and invoke one with tools/call. It can discover resources and read them with operations such as resources/list and resources/read, or discover and retrieve prompts with prompts/list and prompts/get.
These names are protocol vocabulary, not a complete implementation tutorial. Listings can be dynamic and may support change notifications. A host also decides how, or whether, to expose a discovered capability in its user interface and model context.
A database server example
Imagine a database MCP server that exposes three related capabilities:
- A resource containing the database schema, so the application can understand tables and relationships.
- A read-only tool named
query_orders, with a JSON Schema input describing the permitted query arguments. - A prompt that a user can select for a repeatable order-cohort analysis workflow.
The server owns the database connection and validates the operation. The client routes the protocol messages. The host decides what to make available, the user chooses whether to use the workflow, and the model may select the read-only tool subject to host and user policy.
That last condition is important: a tool description is not authorization. A tool can read data or create side effects, so the host should apply appropriate approval and permission rules before execution.
How does an MCP server communicate?
At a high level, the flow is:
- Connect to the server.
- Discover the protocol features and capabilities it supports.
- List the primitive needed for the task.
- Read a resource, retrieve a prompt, or call a tool.
- Return the result to the host, which decides how to present or use it.
The current MCP specification dated 2026-07-28 uses JSON-RPC 2.0 messages. A request has an identifier and receives a response. A notification has no identifier and does not receive a response. MCP uses these messages for discovery, primitive operations, capability negotiation, and related protocol utilities.
The standard transports are:
- stdio: The client launches a local server subprocess. JSON-RPC messages travel over stdin and stdout. The server's stdout must contain only valid protocol messages; stderr can be used for logs.
- Streamable HTTP: The server exposes an HTTP endpoint. Server-Sent Events (SSE) may be used for server-to-client streaming or messages where supported by the implementation.
Transport is not the definition of an MCP server. It is the way the MCP messages move between the client and server.
Is an MCP server the same as an API, plugin, or model?
These concepts can overlap in an architecture, but they are not interchangeable.
| Concept | How it differs from an MCP server |
|---|---|
| Ordinary API | An API is a service interface, often designed for direct application calls. An MCP server speaks MCP and provides standardized discovery, capability information, primitive types, and schemas. It may call an ordinary API internally, but it is not synonymous with that API. |
| Plugin | “Plugin” is a broad product or user-interface integration term. An MCP server is a protocol role that compatible hosts can use; it may be local or remote and does not have to be installed into one specific application. |
| Model or large language model (LLM) | The model generates language and may select tool calls. The MCP server supplies context and server-side capabilities. It does not replace model inference. |
| MCP client | The client is the host-managed connector. The server is the capability provider. The host owns the broader orchestration and policy. |
An MCP server can therefore be an adapter around an existing API, database, filesystem, or another integration. The adapter's value is that it presents capabilities through MCP's common discovery and interaction model.
Security and trust: treat every server as a boundary
An MCP server is not a harmless metadata wrapper. Tools may read information or cause side effects. Resources may contain private data. Prompts and tool descriptions can influence model behavior, including through misleading instructions or prompt-injection content.
Before connecting a server, treat it as a trust decision. At a minimum:
- Obtain explicit user consent before exposing data to a server or invoking its tools.
- Make tools, arguments, and results visible enough for users to understand what is happening.
- Keep a human approval path for sensitive actions. A model's tool choice is not authorization.
- Use least-privilege permissions and isolate server connections.
- Apply timeouts, result validation, and audit logging where appropriate.
- Treat tool annotations and descriptions as untrusted unless the server is trusted.
Server operators have responsibilities too. They should validate tool arguments, resource URIs, prompt arguments, and authorization on every relevant operation. They should implement access control, rate limiting, output sanitization, and safe error handling.
For HTTP deployments, use HTTPS and appropriate authentication and authorization. MCP authorization guidance defines an HTTP authorization framework, but authorization is optional at the MCP implementation level; a deployed service still needs controls appropriate to its data and operations. For local HTTP servers, binding to localhost where appropriate and validating the Origin header can help reduce DNS-rebinding risk.
Protocol compliance alone does not make an untrusted server safe. Credentials, consent, sandboxing, policy, and threat modeling remain host and operator responsibilities. The official reference-server repository also describes its examples as educational rather than production-ready, so examples should not be treated as a security guarantee.
A note about protocol versions
This article scopes current wire-level statements to the 2026-07-28 MCP specification. Older material, including documentation for the 2025-06-18 specification, presents parts of initialization, sessions, and transport behavior differently.
That means an older tutorial and a current software development kit (SDK) example may not describe exactly the same lifecycle. Check the specification and SDK version behind the implementation you are using rather than combining examples silently. The official TypeScript SDK repository currently distinguishes v2 material for the 2026-07-28 specification from v1 material for legacy users.
What to check before connecting to an MCP server
A short inspection checklist can prevent avoidable surprises:
- Identify the deployment and transport. Is it a local subprocess over stdio or a network service over Streamable HTTP?
- Inspect the advertised primitives. Look at the tools, resource URIs or templates, prompts, and input schemas rather than assuming the server exposes more than it lists.
- Understand credentials and permissions. Determine what data the server can access and which operations can change state.
- Start with read-only behavior. Test discovery and low-risk reads before attempting actions with side effects.
- Require approval for sensitive operations. Make the user decision explicit instead of treating model selection as permission.
- Plan for failure. Servers can be unavailable, require credentials, return protocol or tool-execution errors, expose stale or changing listings, hit rate limits, or differ in protocol version.
- Check the documentation and version. Match examples to the server and SDK versions actually in use.
If you already have a server URL, you can try the MCP Playground chat as a practical next step for connecting to and inspecting a server. If you are looking for a remote server to evaluate, the MCP server registry is another starting point. A playground is useful for learning and inspection; it is not a substitute for a production security review.
Frequently asked questions
Is an MCP server the same thing as an API?
No. An ordinary API is commonly designed for direct calls by an application, while an MCP server speaks MCP and exposes standardized discovery, schemas, and server primitives. An MCP server may use an API internally, but the two are not the same interface.
Does an MCP server have to run remotely?
No. It can run locally as a subprocess over stdio or remotely as a network service over Streamable HTTP. “Server” describes its protocol role, not its physical location.
What is the difference between an MCP host, client, and server?
The host is the AI application and policy boundary. It creates a client for each server connection; the client manages protocol communication with that one server. The server supplies the advertised context and capabilities.
What can an MCP server expose besides tools?
It can expose resources and prompts. Resources provide URI-addressed text or binary context and are application-controlled; prompts provide reusable, parameterized messages and are user-controlled.
How does an MCP client discover and call a tool?
The client first participates in capability discovery, then uses tools/list to retrieve available tools and their schemas. To invoke one, it sends tools/call with the tool name and arguments, subject to the host's policy and any required user approval.
Can one host connect to multiple MCP servers?
Yes. A host can manage multiple clients, with each client maintaining a dedicated connection to one server. The connections should remain isolated unless the host has an explicit policy for sharing data.
Do MCP servers see the full chat history?
Do not assume that they do. A server should not be assumed to see the host's entire conversation or other server connections; what data is sent is controlled by the host, client behavior, and applicable policy.
How are MCP servers authenticated?
Authentication depends on the deployment. For HTTP servers, the MCP authorization specification describes an optional authorization framework and guidance for authentication, token audience validation, and least-privilege access. Operators still need to choose and enforce controls appropriate to the service; never put bearer tokens in query strings.
Should users approve every tool call?
Sensitive actions should have a human-in-the-loop approval path. The exact user experience varies by host, but a model selecting a tool should not be treated as authorization, especially when the operation can expose data or change state.
How do I build a minimal MCP server with an SDK?
Choose an MCP SDK that matches the specification version used by your client, define the capabilities your server needs, validate inputs, and select an appropriate transport such as stdio or Streamable HTTP. The official TypeScript SDK repository provides server and client packages and examples, but an example is not a production security review.
What changed between older MCP protocol versions and the current specification?
The 2025-06-18 and 2026-07-28 documentation differs in how it presents initialization, sessions, and transport behavior. Check the version-specific specification and SDK documentation instead of assuming that an older lifecycle example applies unchanged to a current implementation.
Conclusion
An MCP server is a program that speaks the Model Context Protocol and provides a client with discoverable context and capabilities. It may expose tools, resources, and prompts, run locally or remotely, and sit behind a dedicated client connection managed by an AI host.
Once you keep the boundary clear—host for orchestration and consent, client for the connection, server for the focused integration—you can evaluate an MCP server more deliberately. Inspect what it advertises, understand what its tools can do, start with least privilege and low-risk operations, and require approval before sensitive actions.
Sources
- MCP architecture overview — host, client, server roles, connections, deployment shape, and primitives.
- MCP server concepts — plain-language server capabilities and control models.
- MCP specification — current protocol scope and architecture.
- MCP basic protocol — JSON-RPC 2.0 messages and protocol basics.
- MCP tools specification — tool discovery, invocation, schemas, and security considerations.
- MCP authorization specification — HTTP authorization scope and token-handling guidance.
- Official TypeScript SDK — current SDK packages, transports, authentication helpers, and version distinction.
- Official MCP reference servers — educational reference implementations and their production-readiness warning.
- MCP transports in the 2025-06-18 specification — historical/version-comparison material for older transport documentation.
- Resources in the 2025-06-18 specification and prompts in the 2025-06-18 specification — historical/version-comparison material for resource and prompt details.