deepseek_wait

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the blocking nature (wait until newer event or finishes) and mentions that afterSequence prevents repeated output, but it omits critical behaviors such as timeout handling (e.g., does it throw or return partial results?), what happens if the task is already finished, and whether it returns event data or just a signal. This leaves major behavioral unknowns for a wait-based tool.

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 sentences and front-loaded with the primary purpose. The second sentence adds a concise usage tip. Every word earns its place with no redundancy or filler.

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?

Given the lack of annotations, output schema, and complete parameter descriptions, this description is insufficiently complete. It does not cover return values, timeout behavior, error cases, or how this tool fits with sibling tools. For a blocking/long-poll operation, many essential aspects are unaddressed, leaving the agent with significant uncertainty.

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 description must compensate. It explicitly clarifies afterSequence ('to avoid repeated output'), adding meaning beyond the schema. taskId and timeoutMs are not described, but their names and schema constraints (minimum/maximum) make their basic semantics inferable. The description partially compensates but does not fully explain parameter behavior, especially timeoutMs's role in blocking behavior.

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 action: 'Wait until a task emits a newer event or finishes.' This clearly describes the tool's core function and distinguishes it from sibling tools like deepseek_status (which likely checks status without blocking) and deepseek_run (which starts tasks). The focus on waiting for newer events or completion is a unique, well-defined purpose.

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 implies when to use the tool ('Wait until a task emits a newer event or finishes') and provides a specific usage tip: 'Use afterSequence to avoid repeated output.' However, it does not explicitly contrast with alternatives like deepseek_status or deepseek_cancel, nor does it state when not to use this tool. Usage guidance is present but implied rather than explicit.

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