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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so safety and repeat-call behavior are covered. The description adds the interrupt semantics and the fact that it returns an accepted status, but omits behavior for already-finished runs and does not reinforce idempotency in prose.

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 short sentences, front-loaded with the action and scope, with no filler. Every clause earns its place.

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 an output schema present, the return value needn't be detailed beyond the brief 'accepted status' note, and the parameters are fully described in the schema. The only gap is the absence of edge-case behavior for non-in-flight runs, which is minor given the low-complexity two-parameter signature.

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 both parameters (run_id, thread_id) are documented in the schema, so baseline 3 applies. The description adds no format, source, or relationship detail (e.g., where thread_id comes from) beyond the schema.

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 verb (Cancel) and resource (an in-flight DeerFlow run) and clarifies scope with 'interrupts it', which helpfully separates it from status/progress siblings. It stops short of naming a sibling or contrasting explicitly, but the action is unambiguous.

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?

Usage is implied: cancel a run that is in flight. There is no guidance on when-not-to-cancel (e.g., run already completed/failed) or how this relates to siblings like deerflow_wait_activity or deerflow_run_status, so an agent must infer the context.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds genuinely useful behavior beyond them: the call is asynchronous and 'returns immediately' with thread/run ids plus a web URL. It does not mention auth requirements or rate limits, keeping it short of a 5.

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, front-loaded with the action and followed by the branching condition and the next-step workflow. No redundant or filler text.

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?

An output schema exists, yet the description still succinctly characterizes the immediate return (ids and URL) and the async polling pattern, which is the key behavioral fact an agent needs. Nothing essential is missing.

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%, so model, message, thread_id, and recursion_limit are all documented in the schema itself. The description restates the thread_id omit-vs-continue semantics but adds no syntax or default detail beyond what the schema already provides, so the 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 verb and resource ('Send a message to a DeerFlow thread and start a run') and immediately differentiates the two modes of operation via the thread_id parameter, so an agent can distinguish it from siblings like deerflow_run_status or deerflow_research.

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?

Explicitly names when to omit vs. pass thread_id and routes the agent through the follow-up workflow ('poll deerflow_run_status, then deerflow_get_report'), naming the sibling tools to use next. This is exactly the when/how guidance an agent needs.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely non-structured context: text-like files come back inline while binary files return a URL, and a Personal Access Token will not work because this route is not in the PAT allowlist. That auth constraint is exactly the kind of operational detail annotations cannot convey.

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?

Three sentences, front-loaded with the core action, followed by return-format behavior and then the auth caveat. No filler, no restatement of the title, and each sentence carries distinct 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?

An output schema exists, so return values need not be explained, yet the description still usefully summarizes the inline-vs-URL split. Purpose, response shape, and the auth prerequisite are all covered; only failure modes (missing thread or path) are left unaddressed.

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%, so both parameters are fully documented in the schema, including an example path format and the pointer to deerflow_list_artifacts. The description adds no syntax, format, or validation detail beyond that, which is the expected baseline when the schema does the heavy lifting.

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 verb and resource ('Fetch a single artifact file from a DeerFlow thread') with a scope qualifier ('single') that implicitly distinguishes it from the listing sibling. It stops short of naming deerflow_list_artifacts as the alternative, so the differentiation is inferable rather than explicit.

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 schema's path description points the agent to deerflow_list_artifacts as the source of valid paths, which implies the intended workflow, and the PAT note flags an authentication precondition. However, the description never states when to choose this tool over siblings or when it is not applicable.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds critical behavioral detail beyond annotations: the fallback resolution chain (run messages → thread state → summary), the auto-inline of the first text artifact (≤256 KB) when no assistant message exists, and the reporting of terminal status and report_source. This is exactly the kind of runtime behavior an agent needs.

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?

Three sentences, front-loaded with the core purpose, then behavioral details, then usage timing. Every sentence carries useful information, though the fallback-chain and auto-inline details could be slightly condensed. 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 tool's complexity (fallback logic, artifact handling, status reporting), the description covers all the key behavioral aspects an agent would need to interpret the output correctly. An output schema exists, so return value structure needn't be explained, and the description correctly focuses on the resolution process and conditions. Nothing essential is missing.

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%, so both parameters are already documented in the schema with clear descriptions. The description's mention of run_id scoping adds only slight emphasis beyond the schema, and it doesn't explain thread_id at all. Baseline 3 is appropriate when the schema fully handles parameter documentation.

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 and resource ('Fetch the synthesized report for a DeerFlow thread') and enumerates exactly what is returned (assistant message, title, artifact file paths). It's clearly distinguishable from deerflow_run_status and deerflow_get_artifact because it explicitly says it returns the synthesized report and artifact paths, not raw status or artifact content.

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?

Explicitly says 'Call after a run reaches a terminal status,' giving a clear condition for invocation. It also explains the optional run_id scoping. However, it doesn't explicitly contrast with sibling tools like deerflow_run_status or deerflow_list_artifacts, leaving some ambiguity about when to use this versus those alternatives.

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

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

Annotations already declare readOnly/idempotent/destructive=false, so the safety profile is covered. The description adds useful non-annotation context: the output is file paths (metadata only), and reading requires a separate call to deerflow_get_artifact. It does not cover failure cases (e.g. no artifacts produced, thread not found).

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 short sentences, zero filler, with the core action front-loaded and the follow-up workflow second. Every clause earns its place.

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?

An output schema exists, so return values need not be enumerated; the description still helpfully characterizes the result as file paths. Combined with the sibling routing to deerflow_get_artifact, an agent has enough to invoke and chain this 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 the single thread_id parameter, so the schema already carries the parameter documentation. The description adds nothing about the thread id's format or origin, which is adequate given the high coverage — baseline 3.

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 specific verb+resource ("List the artifact file paths produced by a DeerFlow thread") and immediately disambiguates from the sibling deerflow_get_artifact by noting the latter reads content rather than listing it. An agent can select this tool correctly without opening any schema.

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?

It provides clear usage context and an explicit follow-up route ("Pass a path to deerflow_get_artifact to read its content"), which establishes the list-then-read workflow. It does not state exclusions or when listing is unnecessary, so it stops short of a full when/when-not treatment.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds non-obvious context the annotations cannot convey: the auth/token requirement (no PAT, internal token needed) and what the response contains. No pagination or rate-limit detail, hence not a 5.

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?

Three tight sentences with no filler, front-loaded with what it does, then how to use the result, then the auth caveat. Every sentence earns its place.

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 zero-param, read-only listing tool with an output schema and full annotation coverage, the description covers the remaining gaps: consumer tools, returned field meaning, and the auth constraint. Nothing an agent needs to call it correctly is missing.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description instead clarifies the output field semantics (name vs display name vs capability flags), which is the only meaningful 'argument' concept here.

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?

Specific verb+resource ('List the models configured on the DeerFlow instance') plus the returned fields (name, display name, capability flags). It distinguishes itself from siblings by naming deerflow_research/deerflow_chat and explaining the relationship (this tool supplies their model argument).

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?

Explicitly states the use case — resolve a model name to pass into deerflow_research or deerflow_chat — and adds a hard prerequisite caveat that this endpoint is not in the PAT route allowlist and needs an internal token. Both when-to-use and a blocking condition are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is well covered. The description adds useful lifecycle context (that thread_id can be used to continue a conversation or read a report) and implies default filtering, which goes beyond the structured fields. It is not rich enough for a 5 since it doesn't discuss pagination or archival behavior beyond the parameter names.

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 compact sentences with zero filler. The core purpose is front-loaded, and the second sentence efficiently connects the output to downstream actions.

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?

An output schema exists, so the description need not explain return values, but it still does so briefly. With annotations covering the safety profile and full schema coverage, the definition is nearly complete. A minor gap is the lack of explicit usage boundaries against sibling listers, which prevents a perfect score.

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%, so the schema already fully documents 'limit' and 'include_archived'. The description adds no extra syntax or format details for these parameters, so it stays at the baseline 3.

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 provides a clear verb+resource: 'List recent DeerFlow threads' and even enumerates the returned fields (id, title, status, timestamps). It does not explicitly differentiate from siblings like deerflow_run_status or deerflow_get_report, but the purpose is unambiguous.

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 gives implied usage by naming follow-up tools (deerflow_chat, deerflow_get_report) and the thread_id role, but it does not state when to choose this tool over alternatives such as deerflow_run_status or deerflow_list_artifacts. The guidance is suggestive rather than explicit.

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

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

Annotations declare this is not read-only, is open-world, and not idempotent, but don't convey timing. The description adds crucial behavior: it returns immediately, never blocks, can take minutes to ~45 minutes, and yields thread/run ids plus a web URL. It doesn't state auth requirements or what happens on failure, keeping it just short of a 5.

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?

Three sentences, front-loaded with the action, then the async lifecycle, then the timing guarantee. No filler; each sentence earns its place.

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?

Output schema exists so return values needn't be explained, yet the description still tells the agent what ids/URL come back and which siblings to call next. The full lifecycle is covered for an async launch 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 description coverage is 100%, so all four parameters (topic, focus, model, recursion_limit) are already documented inline. The description adds no parameter-level detail beyond the schema, which is the expected baseline when the schema does the work.

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 verb and resource ('kick off a long-running deep-research run on a fresh DeerFlow thread'), distinguishing it from deerflow_chat and the polling/report siblings. An agent can immediately tell this is the entry point that starts a run.

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?

Explicitly lays out the workflow chain: this call returns ids, then poll deerflow_run_status until terminal, then call deerflow_get_report. It also names when to expect it to be used (deep research, minutes to ~45 min) versus a blocking call. Alternatives are named directly.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the auth constraint (session or internal-token; event stream and thread state unreachable with a PAT), the semantics of stalled vs quiet, and delta-mode behavior via since_seq. This is substantive behavioral context the annotations cannot convey.

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 content is front-loaded (purpose first, then return payload, then delta mode, then auth) and every clause carries information. It is dense in a single block rather than broken into scannable segments, which costs it a point.

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?

An output schema exists so return values need not be spelled out, yet the description still gives the agent the auth prerequisite, the polling/delta mechanics, and how to interpret stalled/quiet/next_step. Nothing needed to invoke or interpret the tool correctly is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning for since_seq by tying it to last_event_seq from a previous response and framing it as delta mode, beyond the schema's 'only include events with seq greater than this'. activity_limit and the ids are left to the schema.

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 gives a precise verb+resource ('Get live progress for a DeerFlow run') and enumerates exactly what is returned: status, live counters, recent activity, todo checklist, and stall/quiet detection. It is highly specific, but it never names or contrasts itself against close siblings like deerflow_run_status or deerflow_wait_activity, so an agent must infer the boundary from wording alone.

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?

Usage context is implied rather than stated: since_seq is described for delta polling and next_step points at the web UI and deerflow_cancel_run, but there is no explicit 'use this instead of deerflow_run_status when...' guidance. The alternative tools are referenced only in passing.

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

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

Annotations only cover the safety profile (read-only, idempotent), so the description adds real behavioral value: the wait_seconds cap of 30s, the exact terminal statuses, the fact that counters advance live, and a stall heuristic (counters frozen for several minutes). It does not mention auth requirements or rate limits, but the operational semantics it does disclose are substantive.

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?

Front-loaded with the core purpose in the first sentence, then behavior, then the routing hint. Three dense sentences with no filler, though the stall/counter discussion is lengthy relative to the primary use case.

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?

An output schema exists, so return values need not be spelled out, yet the description still explains how to interpret the counters and when movement indicates a stall. Combined with the terminal-status list and the alternative-tool pointers, an agent has everything needed to call and read this tool 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%, so the schema already documents run_id, thread_id, and wait_seconds including the 0-30 range. The description reinforces the wait_seconds cap and its purpose (wait for terminal status), which is mildly useful but largely repeats the schema; 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 verb+resource ('Check the status of a DeerFlow run') and goes on to enumerate the terminal statuses and live counters returned, so the agent knows exactly what the tool answers. It also names the sibling tools (deerflow_run_progress, deerflow_wait_activity) that provide the event-level detail this tool does not, distinguishing it from them explicitly.

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 concrete usage context: set wait_seconds to avoid polling round-trips, and switch to deerflow_run_progress or deerflow_wait_activity when event-level detail is needed. It does not state exclusions (e.g. when not to use this versus deerflow_wait_activity as a full substitute), so it falls short of an explicit when/when-not pair.

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

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

Adds substantial behavior beyond the annotations: server-side blocking with live event-stream join and polling fallback, immediate return on activity rather than fixed ticks, cancellation semantics (stop_reason 'cancelled_by_client'), MCP progress notifications, and the auth requirement. Annotations only cover the read-only/idempotent profile, so this extra detail is genuinely valuable.

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?

Dense but front-loaded: the core purpose and replacement-for-polling claim come first, followed by return shape, continuation, notifications, and auth. Long, but nearly every sentence carries behavioral information; minor packing could trim the enumeration of return fields.

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?

An output schema exists so return values needn't be explained, yet the description still enumerates the key fields (reason, waited_seconds, last_event_seq) an agent needs to chain calls. Auth, cancellation, and fallback behavior are all covered, leaving no gaps for a long-polling 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%, so the baseline is 3. The description goes beyond it by explaining the continuation workflow for since_seq (feed back last_event_seq) and the timeout framing, adding meaning the schema alone does not convey.

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?

Names a specific verb+resource ('block server-side until the run produces new activity') and immediately differentiates itself from the sibling status tools by stating it 'replaces many status polls.' An agent can distinguish this from deerflow_run_status and deerflow_run_progress without opening schemas.

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?

Clearly states the context of use (use instead of repeated status polling) and gives the continuation pattern: 'Pass the returned last_event_seq as since_seq on the next call.' It does not name a specific alternative tool or state when-not to use it, but the usage context is unambiguous.

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