MCP Server Primitives: Tools, Resources and Prompts

1.Hosts, clients and servers

MCP splits an integration into three roles, and many server-development questions come down to which role owns a given job. The host is the application the user runs. It creates and manages multiple client instances, controls their connection permissions and lifecycle, enforces security policies and consent requirements, and coordinates the AI/LLM integration. A client lives inside the host and communicates with exactly one server. It attaches the protocol version and capabilities to every request and routes messages in both directions. The server is the part you write. It exposes resources, tools and prompts, and it can be a local process or a remote service.

The split is intentional. The specification says servers should be extremely easy to build because host applications handle the complex orchestration. It also says servers should be highly composable: each one provides focused functionality in isolation, and several can be combined through the shared protocol. Isolation sets a hard limit on server design. A server receives only the context it needs, and it cannot see into other servers. Cross-server interactions are controlled by the host. If a server needs something from the client side, such as sampling, elicitation or roots, it does not reach into the host. It asks for that input inside its reply.

How a client reaches a server is the communication pattern, and it also decides how you deploy the server. Over stdio, the client launches the server as a child process. The server reads JSON-RPC messages from stdin and writes JSON-RPC messages to stdout. Each message is a single request, notification or response. Messages are delimited by newlines and must not contain embedded newlines. Because stdout carries the protocol, the server must not write anything to it that is not a valid MCP message. The client likewise must not write anything to the server's stdin that is not a valid MCP message. Logging goes to stderr, which the client may capture, forward or ignore. The client should not treat stderr output as an error. To shut down, the client closes the input stream to the child process, waits for the server to exit, and forcibly terminates it if it does not exit in a reasonable time.

The other transport defined in the specification is Streamable HTTP, used for remote servers. The server exposes a single HTTP endpoint, the MCP endpoint, that accepts POST. The client sends every JSON-RPC request or notification as its own HTTP POST. It must include an Accept header listing both application/json and text/event-stream. The server answers each request with either one JSON object or a Server-Sent Events stream scoped to that request. When running locally, a server should bind only to localhost (127.0.0.1) rather than all network interfaces, must validate the Origin header, and should implement authentication. Raw network sockets are not one of the two transports these specification pages define. Claude Code's own configuration additionally accepts a WebSocket entry of type ws with a wss:// URL.

Deployment is therefore a choice of where the server runs. A launch command such as npx -y @example/mcp-server means the server runs on your machine over stdio. A URL such as https://mcp.example.com/mcp means the server is remote. You register either kind with Claude Code through claude mcp add:

claude mcp add example --env API_KEY=your-key -- npx -y @example/mcp-server

claude mcp add --transport http example https://mcp.example.com/mcp

Sources1234

2.Declaring what the server supports

Before any primitive is used, both sides declare what they support. Servers declare capabilities such as tool support, resource subscriptions and prompt templates. Clients declare capabilities such as sampling support and elicitation handling. Both sides must respect the declared capabilities for the whole interaction. For a server author, this means every feature you implement has to be advertised, and a client can only invoke tools if your server declares the tool capability. Features can be added gradually: the core protocol is small, and extra capabilities are negotiated as needed.

{
  "capabilities": {
    "resources": {
      "listChanged": true,
      "subscribe": true
    }
  }
}

Each primitive has its own capability object. For resources, listChanged says whether the server will send a notification when the list of available resources changes. subscribe says whether it supports update notifications for specific resources, requested through subscriptions/listen. A server that offers resources without either feature can declare an empty object, "resources": {}. Tools and prompts use the same listChanged flag.

Sources15

3.Authoring tools: definitions, calls and results

A tool definition has a unique name, an optional display title, a description, optional icons, an inputSchema, an optional outputSchema and optional annotations. The inputSchema must be a valid JSON Schema object, not null. If it has no $schema field, it defaults to draft 2020-12. For a tool with no parameters, the recommended schema is { "type": "object", "additionalProperties": false }, which accepts only empty objects. Tool names should be 1 to 128 characters long, are treated as case-sensitive, and should use only ASCII letters, digits, underscore, hyphen and dot. Names should be unique within a server. getUser, DATA_EXPORT_v2 and admin.tools.list are all valid.

Clients discover tools with tools/list, which is paginated by cursor. The response can include nextCursor, plus ttlMs and cacheScope hints. Clients run a tool with tools/call, passing the tool name and arguments that match the inputSchema:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    }
  }
}

A completed result has resultType "complete", a content array and an isError flag. If the tool declares an outputSchema, the result also carries structuredContent. Servers must return structured results that conform to the schema, and clients should validate them against it. The schema can describe an object or an array. A tool can also return resultType "input_required" instead of finishing. For example, it might include an elicitation/create input request that asks the user for a GitHub username, along with an opaque requestState. The client then calls tools/call again with inputResponses and the same requestState.

Tools can take real actions, so the specification expects the application to show which tools are exposed to the model, mark each invocation clearly, and ask the user for confirmation before operations. Changes to the tool list are announced with notifications/tools/list_changed.

Sources6

4.Exposing resources

Tools perform actions. Resources are data the server makes readable, and each one is identified by a URI. Besides the uri, a resource has a name and optional title, description, icons, mimeType and size. Clients list resources with resources/list and fetch them with resources/read:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}

The result holds a contents array. Each entry has either a text field or a base64-encoded blob for binary data. For parameterised families of resources, a server publishes templates through resources/templates/list. For example, a uriTemplate of file:///{path} covers every file in a project. Annotations help the client decide what to use. audience is "user", "assistant" or both. priority runs from 0.0 (entirely optional) to 1.0 (effectively required). lastModified is an ISO 8601 timestamp. Clients may offer resources in a tree or list for the user to pick from, let users search and filter them, or include context automatically based on heuristics or the model's selection. A server announces list changes with notifications/resources/list_changed. It sends notifications/resources/updated for resources a client requested through subscriptions/listen, and each notification carries the subscriptionId in _meta.

Resource handling is a security boundary. Servers must validate every resource URI. They must sanitize file paths when serving file:// resources, must encode binary data properly, and should apply access controls and permission checks to sensitive resources. An unknown URI returns error -32602 with the message "Resource not found".

Sources5

5.Exposing prompts

The third primitive is the prompt: a named, reusable message template. A prompt has a name, an optional title, description and icons, and an optional list of arguments, each of which can be marked required. Clients discover prompts with prompts/list. They fill one in with prompts/get, passing values for its arguments:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "code": "def hello():\n    print('world')"
    }
  }
}

The server returns a description and a messages array. Each message has a role of user or assistant and one content item. The item can be text, image, audio, a resource_link or an embedded resource, so a prompt can bring server data into the conversation. An embedded resource needs a valid URI, the correct MIME type, and either text or base64 blob data. Servers should validate prompt arguments before processing them. An invalid prompt name or a missing required argument returns -32602 (Invalid params), and internal failures return -32603. Changes to the prompt list are announced with notifications/prompts/list_changed.

Sources7

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.An MCP server can read the whole conversation and inspect other connected servers to build better answers.Why is that wrong?

   Servers are isolated. They receive only the context they need, the host keeps the full conversation, and the host controls any interaction between servers.

   Covered in Hosts, clients and servers

2. 2.A stdio MCP server can print debug output to stdout, because the client will simply ignore anything that is not a protocol message.Why is that wrong?

   On stdio, stdout carries the protocol itself, so stray output corrupts the message stream. Debug and error logging belongs on stderr.

   Covered in Hosts, clients and servers

3. 3.If a server has handlers for tools/call, clients can invoke its tools whether or not the server advertised them.Why is that wrong?

   Capabilities are negotiated, and both sides must respect them. A server has to declare the tools capability before tools can be invoked.

   Covered in Declaring what the server supports

4. 4.A file:// resource URI from the client can be mapped straight onto the filesystem, because the client only asks for resources the server listed.Why is that wrong?

   The server must validate every resource URI and sanitize file paths itself. Otherwise a crafted URI can escape the intended directory.

   Covered in Exposing resources