# Model Context Protocol Source: https://modelcontextprotocol.io/about/index The open protocol that connects AI applications to the systems where context lives
AI-enabled tools are powerful, but they're often limited to the information you manually provide or require bespoke integrations.
Whether it's reading files from your computer, searching through an internal or external knowledge base, or updating tasks in an project management tool, MCP provides a secure, standardized, *simple* way to give AI systems the context they need.
Pick from pre-built servers for popular tools like GitHub, Google Drive, Slack and hundreds of others. Combine multiple servers for complete workflows, or easily build your own for custom integrations.
Configure your AI application (like Claude, VS Code, or ChatGPT) to connect to your MCP servers. The application can now see available tools, resources and prompts from all connected servers.
Your AI-powered application can now access real data, execute actions, and provide more helpful responses based on your actual context.
## How It Works
When you submit a query:
1. The client gets the list of available tools from the server
2. Your query is sent to Claude along with tool descriptions
3. Claude decides which tools (if any) to use
4. The client executes any requested tool calls through the server
5. Results are sent back to Claude
6. Claude provides a natural language response
7. The response is displayed to you
## Best practices
1. **Error Handling**
* Always wrap tool calls in try-catch blocks
* Provide meaningful error messages
* Gracefully handle connection issues
2. **Resource Management**
* Use `AsyncExitStack` for proper cleanup
* Close connections when done
* Handle server disconnections
3. **Security**
* Store API keys securely in `.env`
* Validate server responses
* Be cautious with tool permissions
## Troubleshooting
### Server Path Issues
* Double-check the path to your server script is correct
* Use the absolute path if the relative path isn't working
* For Windows users, make sure to use forward slashes (/) or escaped backslashes (\\) in the path
* Verify the server file has the correct extension (.py for Python or .js for Node.js)
Example of correct path usage:
```bash
# Relative path
uv run client.py ./server/weather.py
# Absolute path
uv run client.py /Users/username/projects/mcp-server/weather.py
# Windows path (either format works)
uv run client.py C:/projects/mcp-server/weather.py
uv run client.py C:\\projects\\mcp-server\\weather.py
```
### Response Timing
* The first response might take up to 30 seconds to return
* This is normal and happens while:
* The server initializes
* Claude processes the query
* Tools are being executed
* Subsequent responses are typically faster
* Don't interrupt the process during this initial waiting period
### Common Error Messages
If you see:
* `FileNotFoundError`: Check your server path
* `Connection refused`: Ensure the server is running and the path is correct
* `Tool execution failed`: Verify the tool's required environment variables are set
* `Timeout error`: Consider increasing the timeout in your client configuration
After clicking on the slider icon, you should see two tools listed:
If your server isn't being picked up by Claude for Desktop, proceed to the [Troubleshooting](#troubleshooting) section for debugging tips.
If the tool settings icon has shown up, you can now test your server by running the following commands in Claude for Desktop:
* What's the weather in Sacramento?
* What are the active weather alerts in Texas?
## Prerequisites
Before starting this tutorial, ensure you have the following installed on your system:
### Claude Desktop
Download and install [Claude Desktop](https://claude.ai/download) for your operating system. Claude Desktop is currently available for macOS and Windows. Linux support is coming soon.
If you already have Claude Desktop installed, verify you're running the latest version by clicking the Claude menu and selecting "Check for Updates..."
### Node.js
The Filesystem Server and many other MCP servers require Node.js to run. Verify your Node.js installation by opening a terminal or command prompt and running:
```bash
node --version
```
If Node.js is not installed, download it from [nodejs.org](https://nodejs.org/). We recommend the LTS (Long Term Support) version for stability.
## Understanding MCP Servers
MCP servers are programs that run on your computer and provide specific capabilities to Claude Desktop through a standardized protocol. Each server exposes tools that Claude can use to perform actions, with your approval. The Filesystem Server we'll install provides tools for:
* Reading file contents and directory structures
* Creating new files and directories
* Moving and renaming files
* Searching for files by name or content
All actions require your explicit approval before execution, ensuring you maintain full control over what Claude can access and modify.
## Installing the Filesystem Server
The process involves configuring Claude Desktop to automatically start the Filesystem Server whenever you launch the application. This configuration is done through a JSON file that tells Claude Desktop which servers to run and how to connect to them.
This opens the Claude Desktop configuration window, which is separate from your Claude account settings.
This action creates a new configuration file if one doesn't exist, or opens your existing configuration. The file is located at:
* **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json`
* **Windows**: `%APPDATA%\Claude\claude_desktop_config.json`
Click on this indicator to view the available tools provided by the Filesystem Server:
If the server indicator doesn't appear, refer to the [Troubleshooting](#troubleshooting) section for debugging steps.
Review each request carefully before approving. You can always deny a request if you're not comfortable with the proposed action.
## Troubleshooting
If you encounter issues setting up or using the Filesystem Server, these solutions address common problems:
A dialog will appear prompting you to enter the remote MCP server URL. This URL should be provided by the server developer or administrator. Enter the complete URL, ensuring it includes the proper protocol (https\://) and any necessary path components.
After entering the URL, click "Add" to proceed with the connection.
Follow the authentication prompts provided by the server. This may redirect you to a third-party authentication provider or display a form within Claude. Once authentication is complete, Claude will establish a secure connection to the remote server.
The menu displays all available resources and prompts from your connected servers. Select the items you want to include in your conversation. These resources provide Claude with context and information from your external tools.
Navigate back to the Connectors settings and click on your connected server. Here you can enable or disable specific tools, set usage limits, and configure other security parameters according to your needs.
## What can MCP enable?
* Agents can access your Google Calendar and Notion, acting as a more personalized AI assistant.
* Claude Code can generate an entire web app using a Figma design.
* Enterprise chatbots can connect to multiple databases across an organization, empowering users to analyze data using chat.
* AI models can create 3D designs on Blender and print them out using a 3D printer.
## Why does MCP matter?
Depending on where you sit in the ecosystem, MCP can have a range of benefits.
* **Developers**: MCP reduces development time and complexity when building, or integrating with, an AI application or agent.
* **AI applications or agents**: MCP provides access to an ecosystem of data sources, tools and apps which will enhance capabilities and improve the end-user experience.
* **End-users**: MCP results in more capable AI applications or agents which can access your data and take actions on your behalf when necessary.
## Start Building
The Inspector provides several features for interacting with your MCP server:
### Server connection pane
* Allows selecting the [transport](/legacy/concepts/transports) for connecting to the server
* For local servers, supports customizing the command-line arguments and environment
### Resources tab
* Lists all available resources
* Shows resource metadata (MIME types, descriptions)
* Allows resource content inspection
* Supports subscription testing
### Prompts tab
* Displays available prompt templates
* Shows prompt arguments and descriptions
* Enables prompt testing with custom arguments
* Previews generated messages
### Tools tab
* Lists available tools
* Shows tool schemas and descriptions
* Enables tool testing with custom inputs
* Displays tool execution results
### Notifications pane
* Presents all logs recorded from the server
* Shows notifications received from the server
## Best practices
### Development workflow
1. Start Development
* Launch Inspector with your server
* Verify basic connectivity
* Check capability negotiation
2. Iterative testing
* Make server changes
* Rebuild the server
* Reconnect the Inspector
* Test affected features
* Monitor messages
3. Test edge cases
* Invalid inputs
* Missing prompt arguments
* Concurrent operations
* Verify error handling and error responses
## Next steps
Describes who the intended customer of this object or data is.
It can include multiple entries to indicate content useful for multiple audiences (e.g., \["user", "assistant"]).
The moment the resource was last modified, as an ISO 8601 formatted string.
Should be an ISO 8601 formatted string (e.g., "2025-01-12T15:00:58Z").
Examples: last activity timestamp in an open file, timestamp when the resource was attached, etc.
Describes how important this data is for operating the server.
A value of 1 means "most important," and indicates that the data is effectively required, while 0 means "least important," and indicates that the data is entirely optional.
Audio provided to or from an LLM.
See General fields: \_meta for notes on \_meta usage.
Optional annotations for the client.
The base64-encoded audio data.
The MIME type of the audio. Different providers may support different audio types.
The contents of a specific resource or sub-resource.
See General fields: \_meta for notes on \_meta usage.
A base64-encoded string representing the binary data of the item.
The MIME type of this resource, if known.
The URI of this resource.
Capabilities a client may support. Known capabilities are defined here, in this schema, but this is not a closed set: any client can define its own, additional capabilities.
Present if the client supports elicitation from the server.
Experimental, non-standard capabilities that the client supports.
Present if the client supports listing roots.
OptionallistChanged?: booleanWhether the client supports notifications for changes to the roots list.
Present if the client supports sampling from an LLM.
An opaque token used to represent a cursor for pagination.
The contents of a resource, embedded into a prompt or tool call result.
It is up to the client how best to render embedded resources for the benefit of the LLM and/or the user.
See General fields: \_meta for notes on \_meta usage.
Optional annotations for the client.
A response that indicates success but carries no data.
An image provided to or from an LLM.
See General fields: \_meta for notes on \_meta usage.
Optional annotations for the client.
The base64-encoded image data.
The MIME type of the image. Different providers may support different image types.
Describes the name and version of an MCP implementation, with an optional title for UI representation.
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn't present).
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool,
where annotations.title should be given precedence over using name,
if present).
A response to a request that indicates an error occurred.
The error type that occurred.
Optionaldata?: unknownAdditional information about the error. The value of this member is defined by the sender (e.g. detailed error information, nested errors etc.).
A short description of the error. The message SHOULD be limited to a concise single sentence.
A notification which does not expect a response.
Optional\_meta?: \{ \[key: string]: unknown }See General fields: \_meta for notes on \_meta usage.
A request that expects a response.
See General fields: \_meta for notes on \_meta usage.
If specified, the caller is requesting out-of-band progress notifications for this request (as represented by notifications/progress). The value of this parameter is an opaque token that will be attached to any subsequent notifications. The receiver is not obligated to provide these notifications.
A successful (non-error) response to a request.
The severity of a log message.
These map to syslog message severities, as specified in RFC-5424: [https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.1](https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.1)
Hints to use for model selection.
Keys not declared here are currently left unspecified by the spec and are up to the client to interpret.
A hint for a model name.
The client SHOULD treat this as a substring of a model name; for example:
claude-3-5-sonnet should match claude-3-5-sonnet-20241022sonnet should match claude-3-5-sonnet-20241022, claude-3-sonnet-20240229, etc.claude should match any Claude modelThe client MAY also map the string to a different provider's model name or a different model family, as long as it fills a similar niche; for example:
gemini-1.5-flash could match claude-3-haiku-20240307The server's preferences for model selection, requested of the client during sampling.
Because LLMs can vary along multiple dimensions, choosing the "best" model is rarely straightforward. Different models excel in different areas—some are faster but less capable, others are more capable but more expensive, and so on. This interface allows servers to express their priorities across multiple dimensions to help clients make an appropriate selection for their use case.
These preferences are always advisory. The client MAY ignore them. It is also up to the client to decide how to interpret these preferences and how to balance them against other considerations.
How much to prioritize cost when selecting a model. A value of 0 means cost is not important, while a value of 1 means cost is the most important factor.
Optional hints to use for model selection.
If multiple hints are specified, the client MUST evaluate them in order (such that the first match is taken).
The client SHOULD prioritize these hints over the numeric priorities, but MAY still use the priorities to select from ambiguous matches.
How much to prioritize intelligence and capabilities when selecting a model. A value of 0 means intelligence is not important, while a value of 1 means intelligence is the most important factor.
How much to prioritize sampling speed (latency) when selecting a model. A value of 0 means speed is not important, while a value of 1 means speed is the most important factor.
Restricted schema definitions that only allow primitive types without nested objects or arrays.
A progress token, used to associate progress notifications with the original request.
A prompt or prompt template that the server offers.
See General fields: \_meta for notes on \_meta usage.
A list of arguments to use for templating the prompt.
An optional description of what this prompt provides
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn't present).
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool,
where annotations.title should be given precedence over using name,
if present).
Describes an argument that a prompt can accept.
A human-readable description of the argument.
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn't present).
Whether this argument must be provided.
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool,
where annotations.title should be given precedence over using name,
if present).
Describes a message returned as part of a prompt.
This is similar to SamplingMessage, but also supports the embedding of
resources from the MCP server.
Identifies a prompt.
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn't present).
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool,
where annotations.title should be given precedence over using name,
if present).
A uniquely identifying ID for a request in JSON-RPC.
A known resource that the server is capable of reading.
See General fields: \_meta for notes on \_meta usage.
Optional annotations for the client.
A description of what this resource represents.
This can be used by clients to improve the LLM's understanding of available resources. It can be thought of like a "hint" to the model.
The MIME type of this resource, if known.
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn't present).
The size of the raw resource content, in bytes (i.e., before base64 encoding or any tokenization), if known.
This can be used by Hosts to display file sizes and estimate context window usage.
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool,
where annotations.title should be given precedence over using name,
if present).
The URI of this resource.
The contents of a specific resource or sub-resource.
See General fields: \_meta for notes on \_meta usage.
The MIME type of this resource, if known.
The URI of this resource.
A resource that the server is capable of reading, included in a prompt or tool call result.
Note: resource links returned by tools are not guaranteed to appear in the results of resources/list requests.
See General fields: \_meta for notes on \_meta usage.
Optional annotations for the client.
A description of what this resource represents.
This can be used by clients to improve the LLM's understanding of available resources. It can be thought of like a "hint" to the model.
The MIME type of this resource, if known.
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn't present).
The size of the raw resource content, in bytes (i.e., before base64 encoding or any tokenization), if known.
This can be used by Hosts to display file sizes and estimate context window usage.
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool,
where annotations.title should be given precedence over using name,
if present).
The URI of this resource.
A template description for resources available on the server.
See General fields: \_meta for notes on \_meta usage.
Optional annotations for the client.
A description of what this template is for.
This can be used by clients to improve the LLM's understanding of available resources. It can be thought of like a "hint" to the model.
The MIME type for all resources that match this template. This should only be included if all resources matching this template have the same type.
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn't present).
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool,
where annotations.title should be given precedence over using name,
if present).
A URI template (according to RFC 6570) that can be used to construct resource URIs.
A reference to a resource or resource template definition.
The URI or URI template of the resource.
See General fields: \_meta for notes on \_meta usage.
The sender or recipient of messages and data in a conversation.
Represents a root directory or file that the server can operate on.
See General fields: \_meta for notes on \_meta usage.
An optional name for the root. This can be used to provide a human-readable identifier for the root, which may be useful for display purposes or for referencing the root in other parts of the application.
The URI identifying the root. This must start with file:// for now. This restriction may be relaxed in future versions of the protocol to allow other URI schemes.
Describes a message issued to or received from an LLM API.
Capabilities that a server may support. Known capabilities are defined here, in this schema, but this is not a closed set: any server can define its own, additional capabilities.
Present if the server supports argument autocompletion suggestions.
Experimental, non-standard capabilities that the server supports.
Present if the server supports sending log messages to the client.
Present if the server offers any prompt templates.
OptionallistChanged?: booleanWhether this server supports notifications for changes to the prompt list.
Present if the server offers any resources to read.
OptionallistChanged?: booleanWhether this server supports notifications for changes to the resource list.
Optionalsubscribe?: booleanWhether this server supports subscribing to resource updates.
Present if the server offers any tools to call.
OptionallistChanged?: booleanWhether this server supports notifications for changes to the tool list.
Text provided to or from an LLM.
See General fields: \_meta for notes on \_meta usage.
Optional annotations for the client.
The text content of the message.
The contents of a specific resource or sub-resource.
See General fields: \_meta for notes on \_meta usage.
The MIME type of this resource, if known.
The text of the item. This must only be set if the item can actually be represented as text (not binary data).
The URI of this resource.
Definition for a tool the client can call.
See General fields: \_meta for notes on \_meta usage.
Optional additional tool information.
Display name precedence order is: title, annotations.title, then name.
A human-readable description of the tool.
This can be used by clients to improve the LLM's understanding of available tools. It can be thought of like a "hint" to the model.
A JSON Schema object defining the expected parameters for the tool.
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn't present).
An optional JSON Schema object defining the structure of the tool's output returned in the structuredContent field of a CallToolResult.
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool,
where annotations.title should be given precedence over using name,
if present).
Additional properties describing a Tool to clients.
NOTE: all properties in ToolAnnotations are hints.
They are not guaranteed to provide a faithful description of
tool behavior (including descriptive properties like title).
Clients should never make tool use decisions based on ToolAnnotations received from untrusted servers.
If true, the tool may perform destructive updates to its environment. If false, the tool performs only additive updates.
(This property is meaningful only when readOnlyHint == false)
Default: true
If true, calling the tool repeatedly with the same arguments will have no additional effect on the its environment.
(This property is meaningful only when readOnlyHint == false)
Default: false
If true, this tool may interact with an "open world" of external entities. If false, the tool's domain of interaction is closed. For example, the world of a web search tool is open, whereas that of a memory tool is not.
Default: true
If true, the tool does not modify its environment.
Default: false
A human-readable title for the tool.
A request from the client to the server, to ask for completion options.
The argument's information
The name of the argument
The value of the argument to use for completion matching.
Optionalcontext?: \{ arguments?: \{ \[key: string]: string } }Additional, optional context for completions
Optionalarguments?: \{ \[key: string]: string }Previously-resolved variables in a URI template or prompt.
The server's response to a completion/complete request
See General fields: \_meta for notes on \_meta usage.
OptionalhasMore?: booleanIndicates whether there are additional completion options beyond those provided in the current response, even if the exact total is unknown.
Optionaltotal?: numberThe total number of completion options available. This can exceed the number of values actually sent in the response.
An array of completion values. Must not exceed 100 items.
A request from the server to elicit additional information from the user via the client.
The message to present to the user.
A restricted subset of JSON Schema. Only top-level properties are allowed, without nesting.
The client's response to an elicitation request.
See General fields: \_meta for notes on \_meta usage.
The user action in response to the elicitation.
The submitted form data, only present when action is "accept". Contains values matching the requested schema.
This request is sent from the client to the server when it first connects, asking it to begin initialization.
The latest version of the Model Context Protocol that the client supports. The client MAY decide to support older versions as well.
After receiving an initialize request from the client, the server sends this response.
See General fields: \_meta for notes on \_meta usage.
Instructions describing how to use the server and its features.
This can be used by clients to improve the LLM's understanding of available tools, resources, etc. It can be thought of like a "hint" to the model. For example, this information MAY be added to the system prompt.
The version of the Model Context Protocol that the server wants to use. This may not match the version that the client requested. If the client cannot support this version, it MUST disconnect.
A request from the client to the server, to enable or adjust logging.
The level of logging that the client wants to receive from the server. The server should send all logs at this level and higher (i.e., more severe) to the client as notifications/message.
This notification can be sent by either side to indicate that it is cancelling a previously-issued request.
The request SHOULD still be in-flight, but due to communication latency, it is always possible that this notification MAY arrive after the request has already finished.
This notification indicates that the result will be unused, so any associated processing SHOULD cease.
A client MUST NOT attempt to cancel its initialize request.
Optionalreason?: stringAn optional string describing the reason for the cancellation. This MAY be logged or presented to the user.
The ID of the request to cancel.
This MUST correspond to the ID of a request previously issued in the same direction.
This notification is sent from the client to the server after initialization has finished.
Optional\_meta?: \{ \[key: string]: unknown }See General fields: \_meta for notes on \_meta usage.
Notification of a log message passed from server to client. If no logging/setLevel request has been sent from the client, the server MAY decide which messages to send automatically.
The data to be logged, such as a string message or an object. Any JSON serializable type is allowed here.
The severity of this log message.
Optionallogger?: stringAn optional name of the logger issuing this message.
An out-of-band notification used to inform the receiver of a progress update for a long-running request.
Optionalmessage?: stringAn optional message describing the current progress.
The progress thus far. This should increase every time progress is made, even if the total is unknown.
The progress token which was given in the initial request, used to associate this notification with the request that is proceeding.
Optionaltotal?: numberTotal number of items to process (or total progress required), if known.
An optional notification from the server to the client, informing it that the list of prompts it offers has changed. This may be issued by servers without any previous subscription from the client.
Optional\_meta?: \{ \[key: string]: unknown }See General fields: \_meta for notes on \_meta usage.
An optional notification from the server to the client, informing it that the list of resources it can read from has changed. This may be issued by servers without any previous subscription from the client.
Optional\_meta?: \{ \[key: string]: unknown }See General fields: \_meta for notes on \_meta usage.
A notification from the server to the client, informing it that a resource has changed and may need to be read again. This should only be sent if the client previously sent a resources/subscribe request.
The URI of the resource that has been updated. This might be a sub-resource of the one that the client actually subscribed to.
A notification from the client to the server, informing it that the list of roots has changed. This notification should be sent whenever the client adds, removes, or modifies any root. The server should then request an updated list of roots using the ListRootsRequest.
Optional\_meta?: \{ \[key: string]: unknown }See General fields: \_meta for notes on \_meta usage.
An optional notification from the server to the client, informing it that the list of tools it offers has changed. This may be issued by servers without any previous subscription from the client.
Optional\_meta?: \{ \[key: string]: unknown }See General fields: \_meta for notes on \_meta usage.
A ping, issued by either the server or the client, to check that the other party is still alive. The receiver must promptly respond, or else may be disconnected.
See General fields: \_meta for notes on \_meta usage.
If specified, the caller is requesting out-of-band progress notifications for this request (as represented by notifications/progress). The value of this parameter is an opaque token that will be attached to any subsequent notifications. The receiver is not obligated to provide these notifications.
Used by the client to get a prompt provided by the server.
Optionalarguments?: \{ \[key: string]: string }Arguments to use for templating the prompt.
The name of the prompt or prompt template.
The server's response to a prompts/get request from the client.
See General fields: \_meta for notes on \_meta usage.
An optional description for the prompt.
Sent from the client to request a list of prompts and prompt templates the server has.
Optionalcursor?: stringAn opaque token representing the current pagination position. If provided, the server should return results starting after this cursor.
The server's response to a prompts/list request from the client.
See General fields: \_meta for notes on \_meta usage.
An opaque token representing the pagination position after the last returned result. If present, there may be more results available.
Sent from the client to request a list of resources the server has.
Optionalcursor?: stringAn opaque token representing the current pagination position. If provided, the server should return results starting after this cursor.
The server's response to a resources/list request from the client.
See General fields: \_meta for notes on \_meta usage.
An opaque token representing the pagination position after the last returned result. If present, there may be more results available.
Sent from the client to the server, to read a specific resource URI.
The URI of the resource to read. The URI can use any protocol; it is up to the server how to interpret it.
The server's response to a resources/read request from the client.
See General fields: \_meta for notes on \_meta usage.
Sent from the client to request resources/updated notifications from the server whenever a particular resource changes.
The URI of the resource to subscribe to. The URI can use any protocol; it is up to the server how to interpret it.
Sent from the client to request a list of resource templates the server has.
Optionalcursor?: stringAn opaque token representing the current pagination position. If provided, the server should return results starting after this cursor.
The server's response to a resources/templates/list request from the client.
See General fields: \_meta for notes on \_meta usage.
An opaque token representing the pagination position after the last returned result. If present, there may be more results available.
Sent from the client to request cancellation of resources/updated notifications from the server. This should follow a previous resources/subscribe request.
The URI of the resource to unsubscribe from.
Sent from the server to request a list of root URIs from the client. Roots allow servers to ask for specific directories or files to operate on. A common example for roots is providing a set of repositories or directories a server should operate on.
This request is typically used when the server needs to understand the file system structure or access specific locations that the client has permission to read from.
See General fields: \_meta for notes on \_meta usage.
If specified, the caller is requesting out-of-band progress notifications for this request (as represented by notifications/progress). The value of this parameter is an opaque token that will be attached to any subsequent notifications. The receiver is not obligated to provide these notifications.
The client's response to a roots/list request from the server. This result contains an array of Root objects, each representing a root directory or file that the server can operate on.
See General fields: \_meta for notes on \_meta usage.
A request from the server to sample an LLM via the client. The client has full discretion over which model to select. The client should also inform the user before beginning sampling, to allow them to inspect the request (human in the loop) and decide whether to approve it.
OptionalincludeContext?: "none" | "thisServer" | "allServers"A request to include context from one or more MCP servers (including the caller), to be attached to the prompt. The client MAY ignore this request.
The maximum number of tokens to sample, as requested by the server. The client MAY choose to sample fewer tokens than requested.
Optionalmetadata?: objectOptional metadata to pass through to the LLM provider. The format of this metadata is provider-specific.
The server's preferences for which model to select. The client MAY ignore these preferences.
OptionalstopSequences?: string\[]OptionalsystemPrompt?: stringAn optional system prompt the server wants to use for sampling. The client MAY modify or omit this prompt.
Optionaltemperature?: numberThe client's response to a sampling/create\_message request from the server. The client should inform the user before returning the sampled message, to allow them to inspect the response (human in the loop) and decide whether to allow the server to see it.
See General fields: \_meta for notes on \_meta usage.
The name of the model that generated the message.
The reason why sampling stopped, if known.
Used by the client to invoke a tool provided by the server.
The server's response to a tool call.
See General fields: \_meta for notes on \_meta usage.
A list of content objects that represent the unstructured result of the tool call.
Whether the tool call ended in an error.
If not set, this is assumed to be false (the call was successful).
Any errors that originate from the tool SHOULD be reported inside the result
object, with isError set to true, not as an MCP protocol-level error
response. Otherwise, the LLM would not be able to see that an error occurred
and self-correct.
However, any errors in finding the tool, an error indicating that the server does not support tool calls, or any other exceptional conditions, should be reported as an MCP error response.
An optional JSON object that represents the structured result of the tool call.
Sent from the client to request a list of tools the server has.
Optionalcursor?: stringAn opaque token representing the current pagination position. If provided, the server should return results starting after this cursor.
The server's response to a tools/list request from the client.
See General fields: \_meta for notes on \_meta usage.
An opaque token representing the pagination position after the last returned result. If present, there may be more results available.
However, implementors are free to expose prompts through any interface pattern that suits
their needs—the protocol itself does not mandate any specific user interaction
model.
## Capabilities
Servers that support prompts **MUST** declare the `prompts` capability during
[initialization](/specification/2025-06-18/basic/lifecycle#initialization):
```json
{
"capabilities": {
"prompts": {
"listChanged": true
}
}
}
```
`listChanged` indicates whether the server will emit notifications when the list of
available prompts changes.
## Protocol Messages
### Listing Prompts
To retrieve available prompts, clients send a `prompts/list` request. This operation
supports [pagination](/specification/2025-06-18/server/utilities/pagination).
**Request:**
```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "prompts/list",
"params": {
"cursor": "optional-cursor-value"
}
}
```
**Response:**
```json
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"prompts": [
{
"name": "code_review",
"title": "Request Code Review",
"description": "Asks the LLM to analyze code quality and suggest improvements",
"arguments": [
{
"name": "code",
"description": "The code to review",
"required": true
}
]
}
],
"nextCursor": "next-page-cursor"
}
}
```
### Getting a Prompt
To retrieve a specific prompt, clients send a `prompts/get` request. Arguments may be
auto-completed through [the completion API](/specification/2025-06-18/server/utilities/completion).
**Request:**
```json
{
"jsonrpc": "2.0",
"id": 2,
"method": "prompts/get",
"params": {
"name": "code_review",
"arguments": {
"code": "def hello():\n print('world')"
}
}
}
```
**Response:**
```json
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"description": "Code review prompt",
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "Please review this Python code:\ndef hello():\n print('world')"
}
}
]
}
}
```
### List Changed Notification
When the list of available prompts changes, servers that declared the `listChanged`
capability **SHOULD** send a notification:
```json
{
"jsonrpc": "2.0",
"method": "notifications/prompts/list_changed"
}
```
## Message Flow
```mermaid
sequenceDiagram
participant Client
participant Server
Note over Client,Server: Discovery
Client->>Server: prompts/list
Server-->>Client: List of prompts
Note over Client,Server: Usage
Client->>Server: prompts/get
Server-->>Client: Prompt content
opt listChanged
Note over Client,Server: Changes
Server--)Client: prompts/list_changed
Client->>Server: prompts/list
Server-->>Client: Updated prompts
end
```
## Data Types
### Prompt
A prompt definition includes:
* `name`: Unique identifier for the prompt
* `title`: Optional human-readable name of the prompt for display purposes.
* `description`: Optional human-readable description
* `arguments`: Optional list of arguments for customization
### PromptMessage
Messages in a prompt can contain:
* `role`: Either "user" or "assistant" to indicate the speaker
* `content`: One of the following content types:
However, implementations are free to expose resources through any interface pattern that
suits their needs—the protocol itself does not mandate any specific user
interaction model.
## Capabilities
Servers that support resources **MUST** declare the `resources` capability:
```json
{
"capabilities": {
"resources": {
"subscribe": true,
"listChanged": true
}
}
}
```
The capability supports two optional features:
* `subscribe`: whether the client can subscribe to be notified of changes to individual
resources.
* `listChanged`: whether the server will emit notifications when the list of available
resources changes.
Both `subscribe` and `listChanged` are optional—servers can support neither,
either, or both:
```json
{
"capabilities": {
"resources": {} // Neither feature supported
}
}
```
```json
{
"capabilities": {
"resources": {
"subscribe": true // Only subscriptions supported
}
}
}
```
```json
{
"capabilities": {
"resources": {
"listChanged": true // Only list change notifications supported
}
}
}
```
## Protocol Messages
### Listing Resources
To discover available resources, clients send a `resources/list` request. This operation
supports [pagination](/specification/2025-06-18/server/utilities/pagination).
**Request:**
```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "resources/list",
"params": {
"cursor": "optional-cursor-value"
}
}
```
**Response:**
```json
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"resources": [
{
"uri": "file:///project/src/main.rs",
"name": "main.rs",
"title": "Rust Software Application Main File",
"description": "Primary application entry point",
"mimeType": "text/x-rust"
}
],
"nextCursor": "next-page-cursor"
}
}
```
### Reading Resources
To retrieve resource contents, clients send a `resources/read` request:
**Request:**
```json
{
"jsonrpc": "2.0",
"id": 2,
"method": "resources/read",
"params": {
"uri": "file:///project/src/main.rs"
}
}
```
**Response:**
```json
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"contents": [
{
"uri": "file:///project/src/main.rs",
"name": "main.rs",
"title": "Rust Software Application Main File",
"mimeType": "text/x-rust",
"text": "fn main() {\n println!(\"Hello world!\");\n}"
}
]
}
}
```
### Resource Templates
Resource templates allow servers to expose parameterized resources using
[URI templates](https://datatracker.ietf.org/doc/html/rfc6570). Arguments may be
auto-completed through [the completion API](/specification/2025-06-18/server/utilities/completion).
**Request:**
```json
{
"jsonrpc": "2.0",
"id": 3,
"method": "resources/templates/list"
}
```
**Response:**
```json
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"resourceTemplates": [
{
"uriTemplate": "file:///{path}",
"name": "Project Files",
"title": "📁 Project Files",
"description": "Access files in the project directory",
"mimeType": "application/octet-stream"
}
]
}
}
```
### List Changed Notification
When the list of available resources changes, servers that declared the `listChanged`
capability **SHOULD** send a notification:
```json
{
"jsonrpc": "2.0",
"method": "notifications/resources/list_changed"
}
```
### Subscriptions
The protocol supports optional subscriptions to resource changes. Clients can subscribe
to specific resources and receive notifications when they change:
**Subscribe Request:**
```json
{
"jsonrpc": "2.0",
"id": 4,
"method": "resources/subscribe",
"params": {
"uri": "file:///project/src/main.rs"
}
}
```
**Update Notification:**
```json
{
"jsonrpc": "2.0",
"method": "notifications/resources/updated",
"params": {
"uri": "file:///project/src/main.rs",
"title": "Rust Software Application Main File"
}
}
```
## Message Flow
```mermaid
sequenceDiagram
participant Client
participant Server
Note over Client,Server: Resource Discovery
Client->>Server: resources/list
Server-->>Client: List of resources
Note over Client,Server: Resource Access
Client->>Server: resources/read
Server-->>Client: Resource contents
Note over Client,Server: Subscriptions
Client->>Server: resources/subscribe
Server-->>Client: Subscription confirmed
Note over Client,Server: Updates
Server--)Client: notifications/resources/updated
Client->>Server: resources/read
Server-->>Client: Updated contents
```
## Data Types
### Resource
A resource definition includes:
* `uri`: Unique identifier for the resource
* `name`: The name of the resource.
* `title`: Optional human-readable name of the resource for display purposes.
* `description`: Optional description
* `mimeType`: Optional MIME type
* `size`: Optional size in bytes
### Resource Contents
Resources can contain either text or binary data:
#### Text Content
```json
{
"uri": "file:///example.txt",
"name": "example.txt",
"title": "Example Text File",
"mimeType": "text/plain",
"text": "Resource content"
}
```
#### Binary Content
```json
{
"uri": "file:///example.png",
"name": "example.png",
"title": "Example Image",
"mimeType": "image/png",
"blob": "base64-encoded-data"
}
```
### Annotations
Resources, resource templates and content blocks support optional annotations that provide hints to clients about how to use or display the resource:
* **`audience`**: An array indicating the intended audience(s) for this resource. Valid values are `"user"` and `"assistant"`. For example, `["user", "assistant"]` indicates content useful for both.
* **`priority`**: A number from 0.0 to 1.0 indicating the importance of this resource. A value of 1 means "most important" (effectively required), while 0 means "least important" (entirely optional).
* **`lastModified`**: An ISO 8601 formatted timestamp indicating when the resource was last modified (e.g., `"2025-01-12T15:00:58Z"`).
Example resource with annotations:
```json
{
"uri": "file:///project/README.md",
"name": "README.md",
"title": "Project Documentation",
"mimeType": "text/markdown",
"annotations": {
"audience": ["user"],
"priority": 0.8,
"lastModified": "2025-01-12T15:00:58Z"
}
}
```
Clients can use these annotations to:
* Filter resources based on their intended audience
* Prioritize which resources to include in context
* Display modification times or sort by recency
## Common URI Schemes
The protocol defines several standard URI schemes. This list not
exhaustive—implementations are always free to use additional, custom URI schemes.
### https\://
Used to represent a resource available on the web.
Servers **SHOULD** use this scheme only when the client is able to fetch and load the
resource directly from the web on its own—that is, it doesn’t need to read the resource
via the MCP server.
For other use cases, servers **SHOULD** prefer to use another URI scheme, or define a
custom one, even if the server will itself be downloading resource contents over the
internet.
### file://
Used to identify resources that behave like a filesystem. However, the resources do not
need to map to an actual physical filesystem.
MCP servers **MAY** identify file:// resources with an
[XDG MIME type](https://specifications.freedesktop.org/shared-mime-info-spec/0.14/ar01s02.html#id-1.3.14),
like `inode/directory`, to represent non-regular files (such as directories) that don’t
otherwise have a standard MIME type.
### git://
Git version control integration.
### Custom URI Schemes
Custom URI schemes **MUST** be in accordance with [RFC3986](https://datatracker.ietf.org/doc/html/rfc3986),
taking the above guidance in to account.
## Error Handling
Servers **SHOULD** return standard JSON-RPC errors for common failure cases:
* Resource not found: `-32002`
* Internal errors: `-32603`
Example error:
```json
{
"jsonrpc": "2.0",
"id": 5,
"error": {
"code": -32002,
"message": "Resource not found",
"data": {
"uri": "file:///nonexistent.txt"
}
}
}
```
## Security Considerations
1. Servers **MUST** validate all resource URIs
2. Access controls **SHOULD** be implemented for sensitive resources
3. Binary data **MUST** be properly encoded
4. Resource permissions **SHOULD** be checked before operations
# Tools
Source: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
Optional annotations for the client. The client can use annotations to inform how objects are used or displayed