Simulate Research Query

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

Since annotations are all false and provide no safety profile, the description carries the behavioral disclosure burden. It discloses that the tool simulates rather than performs real research, mentions multi-stage progress, and specifies the conditional elicitation behavior contingent on the 'ambiguous' flag and client support. No contradiction with annotations.

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 concise sentences: the first front-loads the core purpose, the second adds a conditional detail. No redundant information.

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?

The tool is a simulation with no output schema and no meaningful annotations. The description covers the key aspects: simulation purpose, multi-stage progress, and ambiguity handling. It could provide slightly more detail on what the progress stages look like or what the final output represents, but it is sufficient for a demonstration tool.

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 coverage is 100% for both parameters, so baseline is 3. The description adds value by explaining how 'ambiguous' triggers an elicitation request when the client supports it, which goes beyond the schema's note about triggering input_required status. It also links the parameter to the simulation flow.

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 the specific verb 'simulates' to identify the action, names the resource as 'a deep research operation,' and clarifies it demonstrates MCP task-based operations, distinguishing it from sibling getter tools like echo and get-env.

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 explicitly states the tool demonstrates MCP task-based operations with progress through stages, giving clear context for when to use it (for demonstration). It does not explicitly exclude alternative uses or name sibling alternatives, but the simulation nature implies it is for testing/demo, not actual research.

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