Pause execution for 0–300 seconds to wait between actions, such as polling jobs, rate-limiting requests, or letting external systems settle.
Pause for the given number of seconds and then return. Useful when you need to wait between actions (e.g. polling a job, rate-limiting, giving an external system time to settle). Range: 0–300 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| seconds | Yes | How long to wait, in seconds (0–300). |
Changes observed during successful MCP inspections.
v2.6.17Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the genuinely useful behavioral facts: the call blocks until the interval elapses and the interval is capped at 300 seconds, which the annotations cannot convey. It does not mention any cost or concurrency implications of blocking, so a small gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the behavior comes first, then the use cases and the bound. Nothing is redundant and nothing is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output, fully annotated utility tool, the description covers behavior, use cases and limits. There is nothing else an agent needs in order to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents type and the 0–300 bounds. The description only restates that same range, adding no syntax or edge-case meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and its exact effect: 'Pause for the given number of seconds and then return.' The action, the unit, and the return behavior are all explicit, so an agent knows precisely what calling it produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives three concrete usage contexts (polling a job, rate-limiting, letting an external system settle), which is exactly the guidance needed to decide when to insert a wait. No sibling tool competes with this behavior, so no exclusion clause is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.