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 – initialize and 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/list when appropriate.
  • Block resources/read requests 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: true for 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.

Share this page

Was this page helpful?
We're glad. Tell us how this page helped.
We're sorry. Can you tell us what didn't work for you?
Thank you for your feedback. Your response will help improve this page.

On this page