*/list
), retrieval (*/get
), and in some cases, execution (tools/call
).
MCP clients will use the */list
methods to discover available primitives. For example, a client can first list all available tools (tools/list
) and then execute them. This design allows listings to be dynamic.
As a concrete example, consider an MCP server that provides context about a database. It can expose tools for querying the database, a resource that contains the schema of the database, and a prompt that includes few-shot examples for interacting with the tools.
For more details about server primitives see server concepts.
MCP also defines primitives that clients can expose. These primitives allow MCP server authors to build richer interactions.
sampling/complete
method to request a language model completion from the client’s AI application.elicitation/request
method to request additional information from the user.Initialization (Lifecycle Management)
initialize
request to establish the connection and negotiate supported features.protocolVersion
field (e.g., “2025-06-18”) ensures both client and server are using compatible protocol versions. This prevents communication errors that could occur when different versions attempt to interact. If a mutually compatible version is not negotiated, the connection should be terminated.
capabilities
object allows each party to declare what features they support, including which primitives they can handle (tools, resources, prompts) and whether they support features like notifications. This enables efficient communication by avoiding unsupported operations.
clientInfo
and serverInfo
objects provide identification and versioning information for debugging and compatibility purposes.
"tools": {}
- The client declares it can work with the tools primitive (can call tools/list
and tools/call
methods)"tools": {"listChanged": true}
- The server supports the tools primitive AND can send tools/list_changed
notifications when its tool list changes"resources": {}
- The server also supports the resources primitive (can handle resources/list
and resources/read
methods)Tool Discovery (Primitives)
tools/list
request. This request is fundamental to MCP’s tool discovery mechanism — it allows clients to understand what tool are available on the server before attempting to use them.tools/list
request is simple, containing no parameters.tools
array that provides comprehensive metadata about each available tool. This array-based structure allows servers to expose multiple tools simultaneously while maintaining clear boundaries between different functionalities.Each tool object in the response includes several key fields:name
: A unique identifier for the tool within the server’s namespace. This serves as the primary key for tool execution and should be URI-like for better namespacing (e.g., com.example.calculator/arithmetic
rather than just calculate
)title
: A human-readable display name for the tool that clients can show to usersdescription
: Detailed explanation of what the tool does and when to use itinputSchema
: A JSON Schema that defines the expected input parameters, enabling type validation and providing clear documentation about required and optional parametersTool Execution (Primitives)
tools/call
method. This demonstrates how MCP primitives are used in practice: after discovering available tools, the client can invoke them with appropriate arguments.tools/call
request follows a structured format that ensures type safety and clear communication between client and server. Note that we’re using the proper tool name from the discovery response (com.example.weather/current
) rather than a simplified name:name
: Must match exactly the tool name from the discovery response (com.example.weather/current
). This ensures the server can correctly identify which tool to execute.
arguments
: Contains the input parameters as defined by the tool’s inputSchema
. In this example:
location
: “San Francisco” (required parameter)units
: “imperial” (optional parameter, defaults to “metric” if not specified)id
for request-response correlation.
content
Array: Tool responses return an array of content objects, allowing for rich, multi-format responses (text, images, resources, etc.)
type
field. In this example, "type": "text"
indicates plain text content, but MCP supports various content types for different use cases.
Real-time Updates (Notifications)
id
field in the notification. This follows JSON-RPC 2.0 notification semantics where no response is expected or sent.
"listChanged": true
in their tools capability during initialization (as shown in Step 1).