Originally published at tryagentsignal.com/guides/mcp-server-explained. The full guide, which covers building a server, error handling and the complete FAQ, lives there.
What is an MCP server?
The Model Context Protocol (MCP) is an open standard that Anthropic open-sourced on Nov 25, 2024 for "connecting AI assistants to the systems where data lives." It replaces "fragmented integrations with a single protocol" (Anthropic). An MCP server is "a program that provides context to MCP clients," whether it runs on your laptop or remotely (MCP architecture).
MCP covers only the protocol for exchanging context. It doesn't dictate how AI apps use LLMs or manage context (architecture). Your agent framework still owns the loop, memory and approvals.
How do hosts, clients and servers connect?
Host: the AI app, such as Claude Desktop, Claude Code or VS Code.
Client: lives inside the host and keeps one dedicated connection to one server. The host creates one client per server.
Server: exposes context and actions.
Connect VS Code to a Sentry server and a filesystem server and you get two client objects (architecture).
What can a server expose?
Three primitives (architecture):
Tools: functions the app can call, such as API calls or database queries.
Resources: data for context, such as file contents or records.
Prompts: reusable templates, such as few-shot examples.
Clients discover each one with */list methods. Tools are invoked with tools/call, and each tool advertises a name, description and JSON Schema inputSchema (tools spec).
Local or remote?
Messages are JSON-RPC 2.0 over one of two transports (architecture):
stdio: for a local process on the same machine.
Streamable HTTP: for remote servers. MCP recommends OAuth for getting tokens.
If you build a stdio server, never write to stdout. It corrupts the JSON-RPC messages, so log to stderr instead (build-server tutorial).
Is it safe to hand an MCP server to an agent?
Only with guardrails (tools spec):
"There SHOULD always be a human in the loop with the ability to deny tool invocations."
Servers MUST validate inputs, enforce access controls, rate-limit and sanitize outputs.
Clients SHOULD confirm sensitive operations and show tool inputs before calling.
Clients MUST treat tool annotations as untrusted unless the server is trusted.
Approval is only half of it. In our view, a human clicking "yes" doesn't stop a retried or resumed run from charging a card twice. That takes an idempotency key on the side effect. See our LangGraph idempotent approval template and duplicate tool calls after resume.
Originally published at tryagentsignal.com/guides/mcp-server-explained. Read the full guide there.