Recommends Direct vs agent surface and Trace-Class based on intent, QPS, and LLM requirement to guide scaffolding decisions. Does not call Zeus.
Pick Direct vs agent surface + Trace-Class (ZDH-18). Does not call Zeus.
| Name | Required | Description | Default |
|---|---|---|---|
| qps | No | ||
| intent | Yes | ||
| needs_llm | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.7.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a meaningful external behavior—'Does not call Zeus'—which is not in the annotations, but it omits other behavioral context like prerequisites or side effects. Given the annotation coverage, the added value is modest.
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 two short sentences with no padding, and the core purpose is front-loaded. Each sentence earns its place, though the terseness borders on under-specification. Overall, it is well-structured and efficient.
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?
With three parameters, no schema descriptions, and only this terse description, the tool is under-specified for an agent to call it correctly. The presence of an output schema helps with return values but does not compensate for missing parameter semantics. The description reads as an internal note rather than a complete tool contract.
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%, and the tool description provides no explanation of the three parameters (qps, intent, needs_llm). An agent cannot infer how to set 'intent' or when to supply 'qps' or 'needs_llm' from either source. This is a critical gap for a tool with a required parameter.
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 states a specific verb ('Pick') and resource ('Direct vs agent surface'), and names a trace class, which gives a clear sense of the tool's decision-making role. It also explicitly notes 'Does not call Zeus,' differentiating it from Zeus-related siblings. However, 'Trace-Class (ZDH-18)' is unexplained and may confuse an agent unfamiliar with the domain.
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?
There is no explicit guidance on when to use this tool versus alternatives. The only hint is 'Does not call Zeus,' which implies it is not for workflows requiring Zeus, but it does not name sibling tools or provide selection criteria. This is insufficient for effective routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.