Whatever message this page gives is out now! Go check it out!
Managing MCP requests
Last update:
May 18, 2026
MCP requests use JSON-RPC 2.0 and standardized method names, covering tools, resources, prompts, and initialization.
Overview
MCP requests are structured using JSON-RPC 2.0 and standardized method names. They fall into a few main categories:
- Tools –
tools/list,tools/call - Resources –
resources/list,resources/read - Prompts –
prompts/list,prompts/get - Initialization –
initializeand capability negotiation
Request types and behavior
Tool requests (tools/call)
- Used for actions and computations (e.g.,
get_weather,create_ticket,summarize_document). - Include tool name and arguments.
- May read data, write data, or orchestrate external services.
Resource requests (resources/list, resources/read)
- Used for read-only access to context such as logs, reports, or documents.
- Bound by roots and custom URI schemes that control scope (e.g.,
logs://today).
Prompt requests (prompts/list, prompts/get)
- Used to retrieve named prompt templates with arguments.
- Help standardize instructions for common tasks.
Best practices for managing MCP requests
Validate inputs early
- Enforce tooling schemas for arguments and resource URIs.
- Reject malformed or incomplete requests with clear error messages.
- Prevent invalid data from reaching downstream systems.
Apply authorization at MCP boundaries
- Decide which tools and resources each client or user can access.
- Hide restricted tools from
tools/listwhen appropriate. - Block
resources/readrequests for URIs outside allowed roots or scopes.
Limit concurrency and duration
- Configure reasonable limits on how many tool calls can run at once.
- Set maximum execution time per request.
- For long-running operations, consider asynchronous workflows and polling rather than single blocking calls.
Log and trace meaningfully
- For each MCP request, log at least:
- Which MCP server and tool or resource was called
- Who called it (user or service identity)
- Whether it succeeded or failed
- Latency (how long it took)
- Avoid logging sensitive payloads; log IDs and metadata instead of full content where possible.
Handle errors explicitly
- Use MCP’s structured responses:
isError: truefor tool-level failures- Clear, user-friendly error messages
- Optional error codes or categories for automation
- Decide whether errors should:
- Be shown directly to users
- Be masked with generic messages and logged internally
- Trigger retries (for transient issues) or not (for validation errors)
Managing tool vs resource vs prompt requests
As you design workflows:
- Use tools when you need to perform work (create, update, compute).
- Use resources when you want to give the model context without side effects.
- Use prompts when you want consistent, reusable instructions for a repeated task.
From a request-management perspective:
- Tools are high-impact; treat them as such (authorization, rate limiting).
- Resources are read-only; they still need access control but usually lower risk.
- Prompts are control plane; they influence behavior but do not directly access data.
We're glad. Tell us how this page helped.
We're sorry. Can you tell us what didn't work for you?
Share additional feedback to help us improve.
0/255
|
