cmcp

by DeveshB-1

Overview Schema Source Related Servers Discussions Admin

Python

Local

Utilities/Delay Response

utilities_delay_response

Read-only

Delays server responses by a specified number of seconds, up to 10, so you can test timeout and latency behavior.

Instructions

Using this endpoint one can configure how long it takes for the server to come back with a response. Appending a number to the URL defines the time (in seconds) the server will wait before responding.

Note that a maximum delay of 10 seconds is accepted by the server.

(Postman request: Utilities/Delay Response | GET https://postman-echo.com/delay/3)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "utilities_delay_response"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 1, 2026

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating the maximum delay is 10 seconds, but it does not explain what happens when the limit is exceeded or how the delay value is supplied given the empty input schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loads the core behavior, then adds the maximum delay constraint and a concrete request example. It is slightly repetitive but contains no major filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple utility with no input parameters and no output schema, the description covers the endpoint purpose and the 10-second limit. It remains incomplete because it does not resolve how an agent should specify the delay when the tool offers no parameter for it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the schema baseline would normally be 4. However, the description refers to appending a number to the URL to define the delay, while the input schema exposes no such parameter or URL field, leaving the agent unsure how to set the delay value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the endpoint controls how long the server waits before responding, with a specific resource and action. It is distinguishable from sibling utilities such as response_status_code or streamed_response, though it never explicitly contrasts them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the endpoint does but gives no guidance on when to use it versus alternatives like utilities_response_status_code or utilities_streamed_response. There are no exclusions, prerequisites, or use-case cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.