What is an MCP server? A practical guide
An MCP server is a program that exposes tools, resources, or prompts to an AI application through the Model Context Protocol. The host application connects through an MCP client, discovers what the server offers, and lets the model use those capabilities under the host's permission and approval rules.
In practical terms, an MCP server is an adapter between an AI agent and something outside the chat: a filesystem, issue tracker, database, browser, internal API, or public catalogue. MCP standardizes the conversation between the application and the adapter. It does not automatically make the underlying system safe, trustworthy, or correctly authorized.
Host, client, and server
The architecture has three roles:
User
│
▼
AI host application
├── model and conversation
├── permissions and approval UI
└── MCP client
│ JSON-RPC over stdio or Streamable HTTP
▼
MCP server
├── tools
├── resources
└── prompts
│
▼
external system or local capability
The host is the product the user interacts with, such as Claude Code or another MCP-compatible agent. It manages the model, conversation, user controls, and one or more MCP clients.
The client speaks MCP for one server connection or configuration. It discovers capabilities, sends requests, receives results, and presents the relevant pieces to the host.
The server implements the protocol and exposes a bounded capability. A filesystem server may read files only under configured directories. An issue-tracker server may expose search, read, and create operations using the connected user's identity.
Tools, resources, and prompts
MCP servers can expose three main server features.
Tools perform operations
A tool is a named operation with a description and an input schema. Examples include search_issues,
read_file, query_database, or create_draft. The model can select and call a tool when it fits the
user's request.
The schema matters because it turns a vague capability into validated parameters. A get_issue tool
can require an issue ID; an execute_sql tool can constrain its accepted fields. The current MCP
specification recommends that applications show which tools are exposed, indicate when one runs, and
keep a human able to deny operations.
Resources provide readable context
A resource is content identified by a URI. It may represent a file, schema, record, document, or other data the client can read. Resources are useful when the primary operation is retrieval rather than an action with side effects.
An application might let a user reference file:///project/README.md or a database schema resource.
The URI identifies the content; it does not mean every host must render or select it the same way.
Prompts provide reusable templates
An MCP prompt is a server-provided message template that a user or client can select with arguments.
For example, a server might offer a review_incident prompt grounded in its domain. Prompts are a
capability advertised by the server, not hidden authority. Hosts decide how to expose them.
These features can coexist. A database server may expose schema resources, query tools, and a prompt for investigating a slow query.
What happens when a client connects
MCP uses JSON-RPC messages, but the lifecycle depends on the protocol era. This is important because many tutorials describe only the 2025 behavior.
The latest specification, dated 2026-07-28, defines a stateless protocol. Each request carries the
protocol version, client information, and capabilities in _meta. A server must not infer task or
conversation state from a connection. Earlier protocol revisions used a connection-scoped
initialize handshake and allowed more bidirectional request patterns. The latest specification
includes backward-compatibility rules so implementations can detect the other side's era and fall
back.
At a high level, the client still needs to learn what the server supports. It sends requests such as
tools/list, resources/list, or prompts/list when the corresponding capability is available, then
calls or reads a selected item. The negotiated version and advertised capabilities prevent a client
from assuming every server implements every feature.
This is why version matters when debugging. “MCP server connected” does not tell you which protocol revision, transport behavior, or optional capabilities both sides actually support.
Local stdio and remote Streamable HTTP
The current specification defines two standard transport bindings:
| Transport | How it works | Best fit |
|---|---|---|
| stdio | The client launches a local process and exchanges newline-delimited messages over standard input and output | Local tools, developer utilities, tightly scoped filesystem access |
| Streamable HTTP | Requests use HTTP POST against one MCP endpoint; responses are JSON or a request-scoped event stream | Hosted services, shared integrations, OAuth-protected APIs |
The protocol semantics are the same across transports; the binding changes how messages are framed, delivered, cancelled, and terminated.
Claude Code recommends HTTP for remote MCP servers. It still supports older SSE endpoints, but its documentation marks SSE as deprecated and recommends HTTP when available. A local command from an installation guide usually indicates a stdio server; an HTTPS MCP URL indicates a remote server.
A safe public example: LLM Mart
LLM Mart exposes its public catalogue as an MCP server at https://llmmart.ai/mcp. A Claude Code
project can describe the connection like this:
{
"mcpServers": {
"llmmart": {
"type": "http",
"url": "https://llmmart.ai/mcp"
}
}
}
The public catalogue requires no key. Once connected, a safe first request is read-only: ask the agent to search for a code-review skill. The server exposes catalogue search and detail tools; LLM Mart's documentation warns that returned descriptions and bodies are community-authored text and should be treated as untrusted data, not instructions to execute.
That example shows MCP's useful separation. The server supplies current catalogue data through a defined tool. Your agent decides how to summarize the result. Neither layer should blindly execute a skill body returned by the search.
What MCP does not provide automatically
MCP standardizes messages and capabilities. It does not automatically provide:
- a reason to trust the server or its publisher;
- correct authorization for your application or tenant;
- safe tool descriptions or results;
- least-privilege credentials;
- human approval for consequential actions;
- protection from prompt injection in retrieved content;
- reliable uptime or backward compatibility beyond what the implementation supports; or
- good tool design.
Authorization for a remote transport is one part of the system. The server must still enforce who can access each record and action. The client must still validate what it exposes to the model. The host must still show users what will happen before an irreversible effect.
How to evaluate an MCP server
Before connecting, answer these questions:
- Who publishes and maintains the server?
- Is the source, release, or package version inspectable and immutable?
- Which transport and protocol versions does it support?
- Which tools, resources, and prompts will enter model context?
- What files, accounts, records, and network destinations can it reach?
- Which operations write, send, delete, merge, deploy, or spend?
- Where are credentials stored, and what scopes do they carry?
- What data leaves your environment, and how is it retained?
- Can you log calls, deny actions, disable the server, and revoke credentials?
Start with read-only access and synthetic or non-sensitive input. Inspect the tool list before asking
the model to use it. For a community server, read the package and setup command; a convenient npx
line is still executable supply-chain code.
When something simpler is better
Use a normal prompt when the task is one-off and all necessary information fits in the conversation. Use an agent skill when the missing piece is a repeatable procedure, not live access. Use a direct API integration when one application owns both sides and does not need MCP interoperability.
Choose MCP when multiple compatible hosts should discover the same live capabilities through a standard interface, or when a governed tool boundary is clearer than handing an agent general shell or network access.
Next step: Browse MCP servers on LLM Mart, inspect one server's source and permissions, then connect it with the narrowest scope and run a read-only first test.
Sources
Comments (0)
Sign in to join the conversation.
No comments yet.