Read running versus waiting requests to detect backpressure on a specified inference target or default, helping diagnose overload in vLLM and Ray clusters.
[READ] Running vs waiting requests — the leading backpressure signal.
Args: target: Inference target name from config; omit for the default.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No |
Changes observed during successful MCP inspections.
v0.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds some behavioral context by labeling the metric as the 'leading backpressure signal' and clarifying the [READ] nature, but it does not describe data freshness, units, return shape, or any operational caveats. With annotations carrying the main burden, this is a modest but non-zero addition.
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?
The description is short and front-loaded, with the leading sentence summarizing the metric and the Args block adding grounded parameter context. It is efficiently sized, though the dash-separated clause is slightly telegraphic.
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 read tool with no output schema, the description is adequate but incomplete: it does not mention when to prefer it over engine_queue_depth or other metrics, and it offers no return-value expectations. Given the busy sibling set of metrics and diagnostic tools, more routing context would help.
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 0%, so the schema gives no per-parameter documentation. The description compensates by explaining that the single 'target' parameter is an 'Inference target name from config' and that omitting it selects the default. That is useful semantic guidance above the bare schema, though the format or valid names are not specified.
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?
The description uses a clear verb-less but specific noun phrase: it reports 'Running vs waiting requests' for an inference target. It distinguishes itself from siblings like engine_queue_depth and request_metrics by framing the metric as a 'backpressure signal', though it does not explicitly name an alternative. The [READ] tag and metrics focus make the purpose legible.
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?
The description states what the metric is but gives no guidance on when to use this tool versus alternatives such as engine_queue_depth, engine_request_metrics, or request_metrics. The only usage-like hint is 'leading backpressure signal', which implies diagnostic context but does not say when to select queue_depth over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.