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 load and does so well: it discloses that failures are explicit, that the tool is purely read-only and will not mutate evidence or reports, and what the return content consists of (added/removed content, source dates, existing claim/report locations). Missing only edge-case behavior such as what happens when the registered source has no dated evidence.

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, then preconditions, then exclusions. Sentences are dense but each carries distinct information; no filler or restatement of the name.

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 output schema covers return values, and the description still summarizes return content and explicitly disclaims side effects and link-following, which is the important part for a read tool. The remaining hole is parameter meaning, which is a real gap for a two-required-parameter tool but not disqualifying.

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 explain 'task' and 'source_id' and it does not. 'One registered public release log' faintly implies source_id is a registered source identifier, but 'task' is never mentioned and neither parameter's format, valid values, or constraints are given.

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 chain (read a registered release log, compare latest saved date against newer entries) and names the resource precisely, which is distinguishable from the research_* siblings that save, review, or report. It stops short of naming which sibling to use instead, but the operation 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?

Gives concrete preconditions ('Requires official_release/release_notes/changelog and saved evidence with dated version entries') and a termination rule ('unchanged ends the check'). It also lists what it will not do (follow links, change evidence/reading status, revise reports), which effectively routes the agent elsewhere, though no sibling is named explicitly.

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 real weight: it discloses that publishing is conditional on checks passing, that it does not send messages or publish externally, that historical checklist receipts stay readable but cannot substitute for current work, and that an author's own disposition cannot clear audit findings. These are genuine behavioral constraints an agent could not get from the schema.

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?

Length is appropriate and the gating condition is front-loaded, but several sentences are compressed into near-opaque noun stacks ('audit and acceptance bound to the current full artifact'), which costs comprehension without saving much 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?

The output schema means return values need not be described, and the preconditions are covered. But for a 4-parameter, zero-coverage schema with no annotations, leaving `task` and `artifact` undefined and the checklist contract only alluded to is a meaningful gap.

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% across 4 parameters, so the description must compensate and only partly does. It defines `message` ('intended user-visible delivery text') and gestures at `checklist` via receipt language, but `task` is never explained and `artifact` is only obliquely referenced through 'current full artifact', with its default of final.md unmentioned.

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 first sentence gives a specific verb pair ('verify report delivery and publish its receipt/terminal state'), which tells an agent this is a completion/gate tool. But 'publish' is later negated ('does not send messages or publish externally'), so the core action is muddied, and nothing distinguishes it explicitly from research_review or research_save beyond a passing reference to evaluation_complete.

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 implies preconditions for success ('requires completed independent perspectives, audit and acceptance bound to the current full artifact') and names research_review as the source of evaluation_complete for evaluation tasks. However, it never states plainly when to call this instead of research_review or research_save, leaving the routing decision to inference.

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. "Read" implies non-mutating and "No additional step is required" implies idempotence, but it never explicitly states there are no side effects, no auth requirements, or what happens on repeated calls. The note that profile is "legacy" is a useful deprecation signal that goes beyond structured fields.

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?

Sentence count is reasonable, but the prose is run-on and loosely ordered: the stage list, language, profile deprecation, task contrast, and methods all interleave. "No additional step is required." is filler, and "available_methods lists choices" points to a tool not present among the named siblings, which adds noise.

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 description does cover all four parameters at least implicitly. Still, for a tool with zero annotation coverage and zero schema descriptions, it should state explicitly whether the call is read-only and confirm the full set of legal stage values rather than embedding them in a slash-separated phrase.

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 largely does: it enumerates accepted language codes ('en', 'zh'/'zh-CN'), explains methods as named capabilities with examples, tells the caller to omit the legacy profile argument, and effectively lists the stage values. Only the stage parameter's meaning is conveyed indirectly rather than stated outright.

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 states a specific verb and resource ("Read ... methods") scoped to a stage, and later implicitly contrasts itself with research_status for existing tasks. The purpose is discernible but the phrase "Read brief/collect/analyze/draft/review/revise/final methods" is dense enough that an agent must parse a stage list to get at the actual action.

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 alternative for an existing task ("use research_status to preserve its recorded completion requirements") and gives conditional guidance for the optional parameter ("Omit methods to keep stage defaults"). It does not, however, say when this tool is preferable to research_start or research_check_updates beyond that single contrast.

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 add substantial behavioral context: no API setup needed, host dispatches distinct non-author agents, an enabled audit cannot be removed, main drafts must have a registered producer, negative reviews are retained, and reviewer=self is a legacy path that cannot complete current review. Gaps remain around return/error behavior, but the operational profile is unusually detailed.

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 dense and largely earns its place, but it arrives as an unstructured block with no front-loaded summary and several cryptic sentences (e.g., 'these are reading aids, not current PASS'). Size is defensible given complexity, but readability and ordering suffer.

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 13-parameter, annotation-free orchestration tool with an output schema, the description covers the dispatch/audit/revision/reviewer behavior and most parameters adequately. The main omissions are the meaning of 'task' and 'purpose', though return values are covered by the output schema.

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 largely does, explaining host_result fields, assignment_ref, include_assignment, scope, artifact, perspectives, domains, audit, revision, reviewer, self_review, and evidence_paths. The required 'task' and 'purpose' parameters are never explained, and the mappings are scattered rather than systematic.

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 identifies the resource and pipeline clearly: it prepares independent review assignments (seven whole-report perspectives, domain review, independent audit, final acceptance) or receives the host's completed result. The dual verb ('prepare ... or receive') muddies the one-line purpose, but the subject matter is specific and distinct from siblings like research_check_reviewer or research_finish.

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?

Strong conditional guidance is present: when to use revision=True (after correcting a draft, not to reroll for a pass), when audit becomes required, and how omitted vs explicit perspectives/domains change selection. It stops short of explicitly contrasting this tool against siblings, leaving some inference required.

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 provided, the description carries the full burden and does so extensively: it discloses file writes, partial-update retention, automatic backups, ownership transfer through handoff.to, retention of timestamps and failures, and that claims are recorded as supplied without inferring truth. It also clarifies that requirements are not closed automatically and that identical bytes are not rewritten.

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 purpose is front-loaded and many sentences convey non-obvious operational rules, but the description is a dense wall of text with no headings, grouping, or examples beyond one bracketed ID example. It is information-rich rather than padded, yet the lack of structure makes it harder than necessary to scan.

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 complex, has no annotations, zero schema description coverage, and only a partial output schema, so the description needs to be rich; it covers most high-risk semantics around updates, ownership, dependencies, backups, and evidence handling. It still leaves gaps around the required task field, claims object structure, and brief fields, preventing 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 0%, so the description must compensate, and it provides substantial meaning for nested fields such as requirements.reading_requirement, sources.read_scope, read_evidence, draft.main, based_on, depends_on, handoff, and replace. However, the required top-level task parameter is never explained, and the claims object semantics are only mentioned in passing.

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 first sentence clearly states a specific verb and set of resources: save/update sources, claims, and requirements by stable ID, and writes CSV/JSONL. It is broad because it also handles drafts, briefs, handoffs, and contributions, and it does not explicitly differentiate itself from siblings such as research_review or research_finish.

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 throughout by detailed conditions such as 'For an active mandatory-reading requirement...' and 'For a contribution use kind=analysis...', but these are field-level rules rather than tool-selection guidance. There is no explicit statement of when to use research_save versus research_review, research_finish, or other siblings, and no when-not guidance.

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 well: it notes language is checked before records are written, that clarification_questions should guide the agent rather than be forwarded, that profile is ignored, and that review_readiness defaults to host_native. Some phrasing ('complete shared research methods', 'historical receipts remain unchanged') is opaque rather than informative.

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 purpose is front-loaded, but the body is a series of terse fragments with uneven flow; several sentences ('Use the complete shared research methods') are cryptic rather than economical. Moderate cleanup would improve it.

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 described. Given a nested brief object and 4 params, the description covers the brief structure, language, profile deprecation and reviewer behavior reasonably; the only real gap is the undocumented 'task' param.

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. It does well for language (en/zh/zh-CN) and the nested brief fields (question, audience, scope, output, depth, evidence_standard) and deprecates profile, but the required 'task' parameter gets no explanation at all.

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 first sentence gives a specific verb and resource ('Create a research task or complete its missing brief') and adds a return-value note ('Returns its directory and stage guidance'). It is distinguishable from research_status for resuming, though it doesn't sharply differentiate from research_save or research_guide.

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 routes one clear case ('Resume saved materials through research_status') and deprecates profile, but most sibling relationships (research_review, research_save, research_finish) are left implicit. The agent must infer which tool handles mid-task steps.

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 so well: it states 'ordinary status remains read-only', 'No host agent is launched by this read', that stage changes are gated on prerequisite records, and that language is validated before any stage change. These are substantive behavioral facts an agent could not get elsewhere, though the delivery is buried in jargon.

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?

Roughly 300 dense words of run-on, jargon-heavy sentences that hop between topics (status reads, stage gating, work preparation, host delegation, file discovery) with no headings or front-loading. Key operational facts are buried mid-paragraph, and many clauses could be trimmed or reordered for scanability.

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-value explanation is not required, and the description covers the read-only nature and stage-change prerequisites. But for a 5-parameter tool with 0% schema coverage, the unexplained required 'task' parameter and the tangled work/delegation semantics leave the agent under-equipped to invoke it confidently.

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 does describe stage values (collect/analyze/draft/revise), language codes ('en', 'zh'/'zh-CN'), methods (selecting from research_guide.available_methods), and work's subfields (question, unit_id, depends_on, requirement_ids, claim_ids, source_ids, paths). The required 'task' parameter is never explained at all, leaving a notable gap for the one mandatory argument.

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 'Read progress and stage methods' states a specific verb+resource, but the description then extends into advancing stages, preparing work input, and opening reading views without ever reconciling these apparently different functions into a single purpose statement. An agent can grasp it's a status/read entry point but must reconstruct the overall job from scattered clauses.

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 real conditional guidance ('Omit stage to prepare independent work without changing global progress', 'stage advances ... only after prerequisite records exist'), which implies when to use it. However, no sibling is named or contrasted (research_guide, research_save, research_review all overlap conceptually), so the agent must infer routing itself.

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