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

With no annotations, the description carries the full burden and does so well: no model calls, no inference of limits from prose, no mutation of progress/reports/reviews/receipts, and use of a shared local task lock. It also scopes the 'ok' signal explicitly to mechanical checks rather than semantic quality or delivery approval, which prevents misuse. Remaining gap: it does not characterize failure/error modes beyond 'returns errors'.

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 action in the first clause, and each following line adds a distinct constraint (no model calls, no mutation, ok semantics) with no filler. The telegraphic fragments and undefined shorthand like 'ok' cost some readability but do not waste space.

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 fully explained; the description still signals that counts, range-check results and errors come back. Combined with the non-mutation and locking disclosures, this is nearly complete for a 2-parameter, low-risk check tool, with parameter meaning as the main omission.

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 description never names or explains the two parameters ('task' and 'artifact', the latter defaulting to final.md). 'Whole-artifact length' hints at the artifact parameter but does not state its format, path semantics, or what 'task' must identify.

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 object (check draft records and declared whole-artifact length) and pins a scope boundary (no model calls, mechanical only). It is distinguishable from research_check_reviewer and research_review, though the phrase 'declared whole-artifact length' is jargon that takes a second read.

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 names the workflow point at which to call it ('before review or finish') and gives a directional rule for which drafts to apply it to ('Correct ordinary drafts and recheck; preserve frozen evaluation originals'). It does not name the sibling check tool it is an alternative to, but the usage context is clear.

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?

No annotations are provided, so the description carries the full behavioral burden, and it does disclose the two traits that matter most: no report data leaves the machine and no paid model calls are made. What it does not disclose is whether it mutates anything or what a failed check looks like, though the output schema covers the return value.

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?

A single front-loaded sentence that communicates action, resource, and the two most decision-relevant constraints. No 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?

With no parameters and an output schema present, the description needs only to convey purpose and behavioral constraints, which it does. It is slightly thin on what 'trusted reviewer configuration' actually consists of, but that is a minor gap for a zero-arg, schema-backed 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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 ('Check') and resource ('trusted reviewer configuration'), plus a scope qualifier ('locally'). It is distinguishable from the sibling research_review because it explicitly frames itself as a local, no-cost verification rather than an actual review. It stops short of naming a sibling, so 4 rather than 5.

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 phrase 'without sending report data or paid model calls' implies this is the cheap pre-flight check to run before invoking the paid review path, but the guidance is implied rather than stated. No alternative tool is named and no explicit when-not condition is 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?

With no annotations, the description carries the full burden and does substantial work: it states the operation publishes only when checks pass, that it does not send messages or publish externally, that length_constraint rows are measured but no prose limit is inferred, and that new ordinary-review attempts require schema_version 2 plus decision_actor and hashes. Auth/permission and reversibility are still unstated, keeping it below 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?

The text is a dense cluster of run-on statements referencing internal paths (state/requirements.jsonl, logs/review.jsonl) and undefined modes (Lite/Full), with low-signal lines like the evidence_files sentence. Only the first sentence is well front-loaded; the rest is hard to parse in a single read.

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 described, which helps. Still, for a 4-parameter finishing/mutation tool with zero schema coverage and no annotations, the description omits what the terminal state actually emits, what artifact/task mean, and how the Lite checklist maps to submission, leaving real gaps despite the volume of text.

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 explains message (intended user-visible delivery text) and checklist semantics well (template when omitted; submit passed/evidence items), but leaves task and artifact undescribed, and references an evidence_files field that does not exist in the schema, which misleads more than it clarifies.

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 opening sentence gives a specific verb and resource: verify report delivery and publish its receipt/terminal state when checks pass. That distinguishes it from research_status (read state) and research_start/save. However, terms like 'Lite', 'Full', and 'terminal state' are undefined and assume prior context, so the precise scope is not fully self-evident.

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 offers some when-to-use cues: omit checklist to get a template, submit passed/evidence items, append finding_disposition rows for evidenced no-change decisions, and evaluation tasks end via research_review. But these are tangled across internal file references rather than stated as a clean decision rule, and no explicit exclusion tells the agent when NOT to call this versus research_review/research_check_draft.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose useful traits: the API default profile is 'full,' 'lite' returns compact guidance, and profiles can be inherited from an existing task. It does not state whether this is purely read-only, whether it has side effects, or anything about auth, which a no-annotation tool would ideally cover.

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 short sentences, front-loaded with the core action and immediately followed by the key parameter and the alternative tool. No filler, though the opening stage list is terse to the point of being cryptic.

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-format explanation is not required. The stage parameter is only implied by a slash-separated list rather than defined, and 'language' has no semantics anywhere. Adequate for a 3-param tool but with visible gaps.

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 across three params. It partially does: 'profile' gets real semantics (explicit vs API default, lite = compact), and 'stage' is enumerated via the stage list. 'language' is never mentioned in the description or schema, leaving one parameter undocumented.

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: read methodology/guidance for named research stages (brief/collect/analyze/draft/review/revise/final) and explicitly scopes it as 'without a task.' The 'without a task' clause cleanly separates it from task-bound siblings like research_status and research_start, though the phrase 'methods' is jargon-y and takes a moment to parse.

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 a clear when-not: for an existing task, use research_status to inherit its saved profile. Also tells the agent to pass the profile explicitly and notes the API default of 'full.' Missing explicit guidance versus research_review, research_check_draft, and research_check_reviewer, but the task-bound vs task-free split is well covered.

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?

With no annotations, the description carries the full behavioral burden and discloses important side effects: external calls send the full task/report/evidence to the configured model account and may consume usage. It also documents non-obvious policies such as no silent downgrade, explicit skip logs, retained evidence, and retry limits.

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 front-loaded with purpose and contains little outright fluff, but it is a dense block of operational rules without grouping or headings. The final sentence about reading the assignment locally is awkwardly placed and the overall structure makes the guidance harder to scan than it needs to be.

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 complex review workflow, missing annotations, and 0% schema description coverage, the description supplies substantial operational context. It is not fully complete because some parameters remain vague and output behavior is not explained, though the presence of an output schema reduces the need for return-value detail.

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 usefully explains evidence_paths format, purpose=evaluation, revision=True, include_assignment=False, and self_review usage, but leaves other parameters such as artifact and task format largely undocumented.

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: run configured content reviews and declared audits while retaining original evidence. It is clear enough to distinguish from generic workflow tools, but it does not explicitly distinguish itself from sibling tools such as research_check_draft or research_check_reviewer.

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 many conditional usage rules: submit self_review when no backend is configured, use purpose=evaluation to preserve defects, resume incomplete assignments, avoid retrying valid negatives, and pass revision=True after corrections. It covers when to do many things, though it does not name sibling 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?

With no annotations the description carries the full burden and does well: it discloses that writes go to CSV/JSONL, that partial updates retain other fields/rows, that original bytes are automatically backed up, that assigned IDs and field errors are returned, and that it 'never infers truth or closes requirements automatically'. Only permissions/auth and concurrency behavior are left unstated, so it falls 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?

The core action is correctly front-loaded, but the body is a dense semicolon-chained block of seven sentences blending parameter guidance, safety notes, return behavior and a status-tool aside. Little is wasted, but the run-on structure makes it harder to scan than a bulleted or sectioned layout would.

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 documented, yet the description still adds useful write/read semantics, backup safety and ID-matching rules for a 6-parameter mutation tool with nested anyOf objects. Remaining gaps ('task' meaning, object field shapes, auth) keep it below a 5.

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 and it only partly does: it clarifies 'draft' (path + optional content + complete=true) and 'replace' (names complete collections, matched by URL/claim/summary) and gives matching semantics for omitted IDs. The required 'task' parameter is never explained, and the internal shape of the sources/claims/requirements objects is left to the caller.

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 opening sentence gives a specific verb+resource: 'Save/update source, claim and requirement objects by stable ID', plus the storage side effect (writes CSV/JSONL). It distinguishes itself from research_status by noting that status 'exposes activity', but it never names the check_draft/check_reviewer siblings it could be confused with.

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 gives concrete operational guidance for the main modes: use 'draft' with path/content/complete=true, omit content to register an existing file, and use 'replace' to repair complete collections from recovered rows. It does not, however, say when NOT to save or how this relates to research_check_draft/research_check_reviewer as 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?

With no annotations, the description carries the burden and does well: it discloses that clarification_questions should guide rather than be forwarded, that profile=full is the API default, that lite skips review and delivery gates but requires a final checklist, and that local checks do not verify quota. It stops short of stating permissions/idempotency or whether it mutates persisted state.

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?

Purpose and return value are front-loaded, and most sentences earn their place by adding distinct operational guidance. It is dense and fragmentary in places (e.g. 'full remains the API default'), which slightly taxes readability for a 9-line block.

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, and the description instead supplies workflow context across siblings (research_status resume, review_readiness pre-check). The only real gap is the undocumented 'language' parameter and absent safety/mutation disclosure.

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 0%, so the description must compensate, and it largely does: it names the brief keys (question, audience, scope, output, depth, evidence_standard) and explains the profile enum (lite vs full, default full). The 'language' parameter is left entirely unexplained, which keeps it from a 5.

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 opening sentence states a specific verb+resource ('Create a research task'), plus a second mode ('complete its missing brief') and a return value ('its directory and stage guidance'). It routes one alternative (research_status for resume) but does not distinguish itself from the other research_* siblings it sits among.

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?

Explicit routing is given: resume existing tasks via research_status, inspect review_readiness before collection, and choose profile from the task's purpose. The when-to-use and when-to-use-something-else conditions are stated rather than implied.

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?

With no annotations, the description carries the full burden: it discloses the allowed stage values (collect/analyze/draft/revise) and that advancement is gated on existing prerequisite records, which is meaningful behavioral context. It does not address permissions, error behavior, or what happens on an illegal stage transition, so gaps remain for a tool that can mutate state.

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 short sentences, front-loaded with what the tool does, then the stage semantics, then the boundary against siblings. Nearly zero waste, though 'Read progress and stage methods' is slightly awkward phrasing.

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 no explanation, and the stage-mutation rules are covered. However, the undefined 'prerequisite records' and the undocumented task/language parameters leave an agent with avoidable uncertainty when composing a call.

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 help for task, stage, or language. The description partially compensates by enumerating the valid stage values and the condition for using stage, but task and language are left entirely undefined in both places.

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 verb+resource pairing (read progress and stage methods) and explicitly carves out review/final completion as belonging to sibling tools. The phrase 'stage methods' is somewhat opaque, but an agent can tell this apart from research_review and research_finish without opening a 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?

Gives a clear usage condition (advance stage only after prerequisite records exist) and names the alternatives for other operations ('Review and final completion use their dedicated tools'). It stops short of naming which record types count as prerequisites or when a read-only call is preferred over advancing.

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