Plain Explanation

If MCP is the standard, an MCP server is the runtime unit that connects that standard to real work. A server can expose Postgres reads, GitHub issue creation, file search, internal documentation, or prompt templates as tools, resources, and prompts. When a user asks an AI app to do something, the host uses an MCP client to discover the server's capabilities and invoke only the allowed operation.

The server is not the model. It is a boundary around external systems. Model calls, user consent, and final policy decisions normally belong to the host. That is why MCP server design is not only about what the server can do. It is about who may use it, which data scope is allowed, which actions need approval, and what gets logged.

Examples & Analogies

• Data access server: a database is not opened directly; approved tables or query templates are exposed through resources/read or limited tools/call.
• Operations server: deployment status, log search, and alert muting are exposed as tools, while write actions require explicit user approval.
• Document workflow server: review templates are exposed as prompts, and reference docs are exposed as resources so the model retrieves only the context it needs.

At a Glance

An MCP server is a concrete instance of MCP. Knowing the protocol does not automatically make a server safe to operate.

Where and Why It Matters

• Tool reuse: one MCP server can be reused by multiple AI apps and agents.
• Permission design: read/write access, workspace scope, and user scope can be separated by server.
• Deployment choice: local developer tools can use STDIO, while shared services can use Streamable HTTP.
• Security review: model-visible tool descriptions and external resources are prompt-injection surfaces, so server-level review matters.

Common Misconceptions

• Myth: An MCP server is just an API wrapper → Reality: it should include tools, resources, prompts, capability negotiation, and host-mediated approval boundaries.
• Myth: Exposing a server means the model can execute it directly → Reality: the host should still apply user consent, policy, and input validation.
• Myth: STDIO servers need less security review → Reality: local file, token, and shell access can make their blast radius high.

How It Sounds in Conversation

• "Split this MCP server into read-only resources and approval-gated write tools."
• "Tool descriptions are model input, so run prompt-injection checks before deployment."
• "Use Streamable HTTP for the shared remote server and keep personal developer tools on STDIO."
• "The server registry needs version pinning and provenance checks."

Related Reading

• prerequisite
  MCP — the overall protocol and host/client/server structure an MCP server follows.
• prerequisite
  JSON-RPC — the request, response, and notification message format.
• alternative
  Function Calling — often used alongside MCP tool calls.
• extension
  Prompt Injection — the risk that tool descriptions or resource content influence model behavior.
• extension
  Supply-chain attack — needed for evaluating MCP server package and registry trust.