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

Annotations already declare readOnlyHint=false and openWorldHint=false, so the write-and-local nature is known. The description usefully adds that a dedicated folder is created and that data is hidden, but omits key mutation behavior such as what happens on a name collision, idempotency, or required permissions.

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 with no filler; the core action leads. The parenthetical '(hidden)' is slightly cryptic but carries real behavioral 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?

With an output schema present, return values need not be described, and annotations cover the safety profile. However, for a creation tool with a default-derived path, the description should say something about collision/overwrite behavior or naming constraints — that gap keeps it at minimum-viable.

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%: both 'name' (review topic, 1-80 chars) and 'path' (default ~/med-lit/<name>) are fully documented in the schema. The description adds nothing about parameters, 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 (Create) and resource (project) and adds structural context — 'one folder per review, holding its wiki and (hidden) its data' — which tells the agent the side effect and layout. It does not explicitly name sibling tools like open_project or list_projects, so differentiation is implied rather than stated.

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 no guidance on when to create a new project versus opening an existing one (open_project) or listing them (list_projects). No prerequisites or conditions are given, so the agent must infer selection from the tool name alone.

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 and openWorldHint=false, so the agent knows this mutates state locally. The description usefully adds that it is a whole-wiki operation ('every Markdown page') across four page categories, but it never says the files are overwritten or where they are written, so the destructive/overwrite nature is only implied.

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 states the scope and the page categories with no filler. It could be tightened because 'from its database' is slightly ambiguous about the direction of the operation.

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. However, for a mutating whole-wiki export the description omits where pages are written and when to invoke it, leaving the operational context only partially covered.

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 schema has 100% description coverage for the single 'project' parameter, including the note that it may be omitted when only one project exists. The description adds nothing about the parameter, so the schema does the heavy lifting and the baseline of 3 is appropriate.

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 names a concrete verb+resource: 'Rewrite every Markdown page of a project's wiki' and enumerates the affected page types (entities, sources, index, log). It is clear enough to distinguish an agent's intent, though it never contrasts itself with sibling wiki tools like wiki_tasks or next_wiki_article, and the name 'export' versus the verb 'rewrite' creates minor tension.

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 no when-to-use guidance: nothing says when to run this versus wiki_tasks, next_wiki_article, or get_article_page, nor any prerequisites such as needing a populated database or an open project. The agent must infer timing entirely.

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 and openWorldHint=true, so the external/state-mutating nature is partly covered. The description adds real value by disclosing the free-full-text-first fallback strategy and the loop-until-exhausted behavior, but it doesn't explain why it is non-read-only (that results are stored) or mention rate limits against the open-access sources.

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 that lead with the main action and the source strategy, with no padding. The trailing "Rules: guide('fetch')" is slightly cryptic but is a useful pointer rather than waste.

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, and annotations carry the safety profile. The description supplies the pipeline context (source waterfall, repeated invocation until remaining hits zero) and routes to guide for rules, which is sufficient for an agent to call it correctly; only the run_id dependency chain is left implicit.

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 80%, so the schema already documents uids, run_id, and the retry flags well. The description adds nothing about parameters (it never mentions run_id, max_items, or the retry semantics), so the baseline 3 is appropriate.

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 full text of included articles") and even explains the source waterfall (PMC, Unpaywall open access, else abstract), so the agent knows exactly what content it returns. It does not, however, distinguish itself from the related read tools (get_article_page, list_articles), so sibling differentiation is missing.

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 a workflow cue ("repeat while remaining > 0") and defers rules to a sibling via "guide('fetch')", which implies usage context. But it never states when this tool should be chosen over get_article_page or list_articles and gives no explicit exclusions or prerequisites beyond the run_id hint.

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 and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — lookup is fuzzy across aliases, acronyms, and spelling variants — but says nothing about result capping or ordering despite a limit parameter.

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 sentence that front-loads the verb and resource with zero filler. Nothing redundant or padded.

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, and annotations cover safety. However, for a 4-parameter search tool with a 10-value entity_type enum and a 1-50 limit, the description is too thin to let an agent 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 description coverage is only 25%: only 'project' is documented in the schema, and the description adds nothing about query, limit, or entity_type. Since the description must compensate for the coverage gap and instead repeats only the query notion, it leaves entity_type filtering and limit behavior entirely opaque.

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 (search) and resource (project's wiki entities) and even enumerates the match modes (name, alias, acronym, spelling variant), which is unusually informative. It is distinguishable from merge_entities and wiki_tasks, though it never names a sibling explicitly, so it falls short of a 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?

There is no when-to-use guidance, no exclusion criteria, and no mention of alternatives such as merge_entities or resolve_duplicates, which also operate on entities. The reader can infer this is the lookup entry point, but nothing routes them 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description contributes the genuinely useful 0-indexed paging convention, but says nothing about what a 'page' contains, whether it re-fetches from the network or reads from cache, or what the response looks like.

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 tight sentence with zero waste; the core action comes first and the paging convention follows immediately.

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 output schema and three required parameters, the description should carry more weight. It covers the paging model adequately for a simple read, but leaves 'uid' and the nature of a page undefined, which an agent needs in order to call this 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 only 33% — only run_id is documented in the schema. The description compensates for exactly one gap by explaining that pages are numbered from 0, which is real added meaning for 'page', but 'uid' remains completely unexplained in both the schema and the description.

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: re-reading one page of an already-fetched article. It distinguishes itself from fetch_articles and list_articles via the word 're-read,' but it never names a sibling or clarifies the relationship, so the differentiation is implied 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?

'Re-read' implies the usage context (after an article has already been fetched), which is useful but inferred rather than stated. There are no explicit when-to-use/when-not conditions and no naming of alternatives such as fetch_articles for a first read.

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 and openWorldHint=false, so the safety profile is covered by structured data rather than the prose. The description adds a modest behavioral signal by indicating the response contains per-stage progress and next-step guidance, but says nothing about freshness, blocking behavior, or errors for unknown run IDs.

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 stating what is shown first (progress by stage) and then what else is returned (next steps). No filler, no restatement of the tool 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?

With an output schema present, the description does not need to enumerate return fields, and the read-only annotation covers risk. For a one-parameter status lookup it is nearly sufficient, missing only a pointer on how it relates to list_runs and resume_search.

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?

There is a single required parameter with 100% schema description coverage, so the schema already documents run_id, its format constraint, and its origin ("Run ID from start_search"). The description contributes nothing further about the parameter, 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?

The description names a specific verb and resource ("Show a run's progress") and scopes it to stages plus next steps, which is meaningfully more specific than the bare tool name. It does not, however, differentiate itself from siblings like list_runs or resume_search, so an agent still has to infer which run-oriented tool applies.

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 only implied: the agent can guess this is called with a run_id to inspect progress, and the phrase "available next steps" hints the output guides what to do next. There is no explicit when-to-use, when-not-to-use, or named alternative such as list_runs for enumerating runs.

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 and openWorldHint=false, so the agent knows this is a safe, local, side-effect-free read. The description adds that the content is prescriptive rules/how-to rather than data, which is mild extra context. It doesn't describe the shape or breadth of the returned guidance, but the output schema covers return values, so a 3 is appropriate.

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 sentence with the purpose front-loaded followed by the enumerated stages. It is tight and wastes little, though restating the enum values is somewhat redundant with the schema. Efficient overall.

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 annotations covering safety and an output schema defining the return, the main missing piece is usage context — when in the workflow to consult this guide relative to the sibling action tools. For a meta/reference tool in a large workflow suite, that gap keeps it from being complete.

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%, but the single parameter carries an enum of nine values that the description reproduces verbatim. It confirms the valid topics but adds no per-topic meaning (e.g., what 'duplicates' or 'ontology' guidance contains). It partially compensates for the coverage gap by surfacing the options but adds nothing beyond the enum itself.

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 conveys that this is a reference/guidance tool that returns rules and how-to material scoped to a named stage, and it enumerates those stages (workflow, question, screening, etc.). However, the verb is nominal ('Rules and how-to for a stage') rather than an explicit action, so the agent must infer that the tool retrieves documentation. It is understandable but not sharply stated.

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 no guidance on when to call this tool versus the many action siblings (validate_question, start_search, set_screening_criteria, etc.). It never says 'call this first to learn how a stage works' or gives any precondition or workflow context. The agent is left to infer usage entirely from the topic enum.

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 and openWorldHint=false, so the safety profile is covered. The description adds that results include screening/fetch/wiki status fields, but omits any pagination or filter behavior despite limit/offset existing in 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?

One sentence, front-loaded, no filler. It is efficient, though arguably too terse for a six-parameter tool with filterable enums.

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, but with 6 parameters, low schema coverage, and undocumented filter enums, the description leaves the agent guessing about filterability and pagination of this list operation.

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 only 17% – just run_id is documented. The description hints that screening (decision), fetch_status, and wiki_status appear in results but never states they can be used as filters, and limit/offset are wholly unexplained 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?

The description gives a specific verb (list), resource (articles), scope (a run's), and states the returned status dimensions (screening, fetch, wiki). It does not differentiate itself from fetch_articles, 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?

No when-to-use guidance and no named alternative (e.g., fetch_articles for full text). The agent must infer that this is a browsing/listing operation versus a fetching one.

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 and openWorldHint=false, so the safety profile is covered. The description adds that each pair comes with an example mention, a small behavioral detail, but says nothing about scoring, confidence, ordering, or pagination behavior.

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 efficient sentence that front-loads the resource. It is appropriately sized, though it carries almost no additional information beyond 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?

An output schema exists, so return values need not be described, and annotations cover safety. However, for a discovery tool that feeds merge/resolve siblings, the missing usage guidance and parameter explanation leave the definition merely adequate.

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 only 67% (limit is undocumented), and the description adds no parameter meaning at all. It never explains that run_id scopes results to a search run or that project may be omitted in single-project setups, leaving the two most consequential filters under-explained.

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 ('List') and resource ('entity pairs that may be the same thing'), which is clearly the duplicate-candidate detection concept. It does not differentiate itself from the closely related sibling resolve_duplicates or merge_entities, 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?

No guidance on when to use this versus resolve_duplicates or merge_entities, no mention of prerequisites or workflow position. The agent must infer that this is a discovery step feeding the resolution tools.

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 and openWorldHint=false, so safety is covered. The description adds genuine context beyond that by explaining how to interpret the returned `available` flag (folder moved or missing), which affects how an agent acts on results.

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 interpretive caveat 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?

For a zero-param read-only list tool with an output schema, the essentials are covered: what is returned and the one non-obvious field semantic. Slightly thin on ordering/pagination and where projects come from, but nothing required 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 there is nothing for the description to disambiguate; the baseline for a no-param tool applies. The `available` semantic it explains is an output field, not an input, so it does not inflate this dimension.

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 ("List known projects with their folders"), which cleanly separates it from write-oriented siblings like create_project and open_project. It does not explicitly name or contrast with those siblings, so it stays short of a 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?

Usage is only implied: an agent can infer this is the discovery step for projects/folders before calling open_project. There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives among the 24 siblings.

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 and openWorldHint=false, so safety is covered. The description adds the newest-first ordering, which is useful behavioral context, but says nothing about pagination or how limit interacts with results.

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 with zero filler; the scope and ordering are conveyed compactly with no wasted words.

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 ordering is covered. However, for choosing among the many sibling tools the agent gets no guidance, and the limit parameter's semantics are left to inference.

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 only 50%: the project parameter is documented but limit has no description at all. The description offers no parameter meaning and does not compensate for the undocumented limit beyond what its name/default imply.

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 (List), resource (a project's searches/runs), and result ordering (newest first), which lets an agent understand the operation immediately. It does not explicitly distinguish itself from related siblings like get_run_status or list_projects, so it stops short of a 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?

There is no explicit when-to-use guidance, no conditions for choosing this over get_run_status, and no prerequisites stated. Usage is only implied by the phrase 'a project's searches'.

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 flag destructiveHint=true and openWorldHint=false, so the safety profile is covered structurally; the description adds nothing about irreversibility, what happens to the folded entities' data, or permission requirements. For a destructive merge with no extra behavioral context, this is thin.

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 tight sentence with the primary action front-loaded and the optional capability trailing. It is not padded or repetitive, though it is arguably too terse given the tool's complexity.

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 destructive, 6-parameter mutation tool with a required reason field and partial schema coverage, the description omits the merge-vs-rename distinction mechanism, the required reason, and any warning about data loss. An output schema exists, so return values need not be explained, but the input-side gaps remain serious.

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 only 33%, leaving keep_id, reason, entity_type, and canonical_name undocumented. The description's 'rename or retype' weakly maps to canonical_name/entity_type but gives no syntax, no mention that reason is required or capped at 400 chars, and no note that merge_ids is capped at 10.

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 ('Merge entities into one') and adds the secondary capability of rename/retype. However, it does not distinguish itself from close siblings such as resolve_duplicates or list_duplicate_candidates, so an agent cannot tell which to pick from the description 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?

There is no statement of when to use this tool versus resolve_duplicates or list_duplicate_candidates, and no prerequisites (such as being in the right project). The 'and/or' phrasing is the only usage hint, and it is implicit at best.

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 declare readOnlyHint=false and openWorldHint=false. The description says 'Get', which reads like a passive read, yet it never explains that calling it advances/consumes the screening queue, whether items can be re-fetched, or what happens if the batch is not recorded. For a state-advancing 'next' tool this is a notable disclosure gap.

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 with no filler; the verb and scope come first. It is efficient, though very terse given the workflow it participates in.

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. However, for a two-parameter, non-read-only queue tool, the description omits prerequisite sequencing, iteration behavior, and batch_size semantics, leaving the agent with a minimum-viable picture.

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 50%: run_id is documented only as 'Run ID from start_search', and batch_size carries no description at all in the schema. The description does not compensate by explaining batch_size limits/semantics or how run_id links to start_search, so the undocumented parameter remains opaque.

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 ('Get') and resource ('next unscreened titles/abstracts'), plus the payload detail that screening criteria are returned alongside. That distinguishes it reasonably well from fetch_articles/list_articles, though it doesn't name any sibling explicitly to route the agent.

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 only implied: mentioning 'unscreened' and 'criteria to judge them against' signals it belongs inside the screening loop, but there is no explicit when-to-use, no prerequisite (start_search/set_screening_criteria first), and no pointer to record_screening_decisions as the follow-up.

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 are sparse (readOnlyHint=false, openWorldHint=false) and the description does not fill the gap. Critically, it does not say whether calling this advances a queue or reserves/locks the returned entity, despite readOnlyHint=false implying a state-affecting operation. No mention of auth, ordering, or what happens when no entity needs writing.

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 tight sentence with the key payload front-loaded after the verb. No filler, though it is terse enough that a bit more procedural framing could have been added without bloat.

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 in prose. However, for a workflow-step tool sitting among next_wiki_article and next_screening_batch, the description omits the state-advancing/queue behavior that an agent needs to call it safely, leaving a real 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 description coverage is 100%, so run_id, project, and min_sources are already documented in the schema, and the description adds nothing about their semantics. Baseline 3 is appropriate when structured fields carry the parameter meaning.

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 ('Get') and resource ('the next entity whose wiki page needs writing') plus the payload ('its evidence'), so the agent knows exactly what comes back. It is distinguishable from list_articles or find_entities, but it never contrasts itself with the closely named sibling next_wiki_article or next_screening_batch, so sibling differentiation is incomplete.

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 no statement of when to call this versus alternatives such as next_wiki_article or a batch flow, nor when not to call it. The agent must infer that this is a step in the synthesis workflow and has no explicit cue about sequencing or preconditions.

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=false, consistent with 'next page' implying a stateful cursor advance. The description adds a return-format hint (JSON header plus page), which is useful, but does not confirm that pages are consumed or what happens after the last page. Adequate but thin for a stateful iterator.

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 states the action and the extraction context with no filler. Slightly dense parenthetical, but nothing wasted.

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 no output schema and only two annotations, the description leaves open iteration termination, page-size defaults, and how the returned header relates to run state. It is enough to attempt a call but not enough to confidently drive the pagination loop.

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 uid, run_id, and max_pages are already documented in the schema (including the subagent ownership case for uid and the run_id pattern). The description adds no parameter-level detail beyond the schema, which is the baseline 3 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 concrete verb and resource: 'Get the next page of article text.' The purpose of feeding entity extraction is clear. It does not, however, differentiate itself from the sibling get_article_page, which an agent could plausibly confuse it 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?

The description implies a pagination loop ('the next page') but never says when to call this versus get_article_page, what ends the iteration, or what run state is required. Usage must be inferred from the schema and the sibling list.

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 and openWorldHint=false, and the word 'Register' is consistent with that state-changing profile, so there is no contradiction. The description adds the notion of re-registering a relocated folder but stays silent on error behavior (e.g. missing/invalid path) or what the registration actually changes.

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 tight sentence with the action front-loaded and the qualifying scenario trailing it. Nothing is wasted, though the brevity is close to under-specification rather than optimal conciseness.

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, return values need no explanation, and one fully documented parameter plus annotations cover most of the surface. Still, for a state-mutating tool the description omits failure conditions and any distinction from create_project, which an agent needs to choose 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 single 'path' parameter is fully documented in the schema itself. The description only restates that the path is a folder of an existing project, adding no format, validation, or relative-vs-absolute detail beyond the schema, so the baseline of 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 (Register) and resource (an existing project folder), which is more precise than the bare name. The phrase 'existing project folder' implicitly distinguishes it from create_project, though it never names that sibling 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?

The clause 'for example after it was moved or copied from elsewhere' gives a motivating scenario, which implies when to use it. However, it gives no explicit when-not guidance and does not point to create_project as the alternative for new projects, leaving the agent to infer the routing.

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 idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing that re-recording a page replaces the prior record, which explains the overwrite semantics the agent must understand. It does not cover auth, rate limits, or partial-failure behavior, 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 compact sentences, front-loaded with the core action and the overwrite caveat, then the rules pointer. No waste, though the guide reference is terse enough to feel like a pointer rather than guidance.

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 unnecessary, and the overwrite behavior is stated. However, for a 6-required-parameter mutation tool with 17% schema coverage, the meaning of uid, content_sha256, and the run linkage is left undocumented, which 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?

Top-level schema description coverage is only 17%: uid, content_sha256, page, entities, and relationships carry no schema descriptions, and the description does not explain them either. It only implies a per-page scope; the run linkage and hashing parameters remain opaque.

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 ('Record') and resource (entities and relationships extracted from one page), and the parenthetical clarifies scope. It does not name a contrasting sibling like find_entities or merge_entities, so it is clear but not fully differentiated.

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 only usage directive is 'Rules: guide("extraction")', which routes the agent to a rules source rather than stating when to call this versus alternatives. It implies this is part of the extraction workflow but leaves conditions and prerequisites 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?

Annotations declare readOnlyHint=false and openWorldHint=false, so safety profile is partly covered. The description adds a genuine behavioral constraint beyond the schema — include/exclude require a verbatim quote — which is useful. It omits mutation consequences, revision/conflict behavior, and the 25-item batch cap.

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 tight sentence with the key constraint front-loaded. It is appropriately sized and wastes no words, though the terse phrasing leaves room for more structure.

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. However, for a mutating batch tool in a multi-step screening pipeline, the description omits revision/conflict semantics, batch limits, and workflow ordering that an agent needs to invoke it 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 67%, so the schema already documents run_id, revision, and the evidence field. The description reinforces the evidence rule but adds no meaning for run_id, revision, uid, or the decision enum that the schema does not already supply. 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?

The description states a specific verb and resource ('Record screening decisions'), which is a clear write operation distinct from read-oriented siblings like next_screening_batch or review_article. It does not, however, explicitly name or contrast itself against those siblings.

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 no when-to-use or when-not-to-use guidance. The description never references the workflow position (e.g., call after next_screening_batch, before the next batch/revision), nor does it mention alternatives. The agent must infer ordering from parameter names alone.

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 this is a write operation (readOnlyHint=false) in a closed world, so the safety profile is covered. The description adds a genuine behavioral constraint not in the annotations — the page must be synthesized only from next_synthesis evidence — but says nothing about validation failures, length limits, or overwrite/merge behavior for an existing entity page.

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 with no filler, and the core action plus its source constraint is front-loaded. The trailing 'Rules: guide("synthesis")' fragment is terse and slightly cryptic but costs little 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 described, but this is a 7-parameter write tool with 6 required fields and the description conveys almost none of their intent or the constraints (maxLength/minLength, required evidence). For a complex mutation tool it is under-specified.

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 only 43%, so the description is expected to compensate for undocumented parameters, yet it explains none of them. Opaque required fields like entity_id and input_digest are left entirely unaddressed in the description, adding no meaning 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 (Save) and resource (an entity page), and constrains the source material to next_synthesis evidence, which distinguishes it from the read-side sibling next_synthesis. It stops short of explicitly naming an alternative tool to use instead, so sibling differentiation is implied rather than stated.

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 'written only from next_synthesis evidence' implies the workflow prerequisite (gather evidence via next_synthesis first) and the pointer 'guide("synthesis")' routes the agent to rules. However, no explicit when-not-to-use conditions or step sequencing are given, so usage must be partly inferred.

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 destructiveHint=true and openWorldHint=false, so the safety profile is partly covered. The description adds nothing about irreversibility of merges, what happens to the losing entity, or the 50-decision cap, which matters for a destructive write operation.

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 tightly worded sentences with the operation front-loaded and no filler. The 'guide("duplicates")' pointer is terse but functional rather than padded.

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 destructive, batch-write tool with a nested decision object and no annotation-independent detail, the description is too thin. It omits the decision structure, the merge consequences, and any eligibility or ordering constraints, even though an output schema does exist.

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 only 50%. The phrase 'merge or keep distinct' loosely maps to the action enum, but the 'keep' field (entity vs candidate), entity_id/candidate_id, and reason are unexplained, so the description does not compensate for the coverage gap.

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 pair ('merge or keep distinct') and resource ('pairs of possible duplicate entities'), so an agent knows exactly what operation this performs. However, it does not differentiate from siblings like merge_entities or list_duplicate_candidates, which also touch duplicate entities.

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 no when-to-use guidance and no comparison to alternatives such as merge_entities. The only pointer is 'Rules: guide("duplicates")', which tells the agent where rules live but not when this tool is the right choice versus its siblings.

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=false and openWorldHint=true, so the agent already knows this mutates and reaches an external/open world; the description is consistent with that. It adds that retrying a completed run adds new records, but does not disclose auth needs, rate limits, or what wait_seconds actually does behaviorally.

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, well-formed sentence that front-loads the primary action and lists the three modes without filler. It is appropriately sized, though the three modes could be slightly more clearly delimited.

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 covers the main invocation modes. It is adequate but thin for a mutating, open-world tool with a wait parameter whose blocking behavior is never mentioned.

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 67%: run_id and retry_failed_sources are described in the schema, while wait_seconds has only a default/min/max. The description adds conceptual meaning to retry modes but explains none of the parameters beyond what the schema already states, 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?

The description states three specific operations (check a running search, retry a failed one, retry failed sources of a completed run) with the resource clearly being a 'search'. It is distinguishable from start_search (which initiates) and get_run_status (status read-only), though the 'check a running search' clause overlaps somewhat with get_run_status and no sibling is named 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?

The three modes imply when to use the tool (running, failed, completed-with-failures), giving useful context. However, it never names an alternative tool or states when NOT to use it, and the boundary with get_run_status for the 'check a running search' case is left 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?

Annotations declare readOnlyHint=false and openWorldHint=false, consistent with the implied write, so there is no contradiction. Beyond that, the description discloses nothing about whether a decision can be overwritten, idempotency on re-review, permission requirements, or the effect of recording a decision on downstream workflow 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?

A single efficient sentence with the key noun (include/exclude decision) front-loaded and no filler. Nothing is wasted, though there is also nothing extra offered.

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 fully-required four-parameter mutation tool with low schema coverage, the description is too thin: it omits the relationship to batch screening siblings, the consequence of the recorded decision, and any workflow prerequisites. The presence of an output schema excuses it from explaining return values, but not from the remaining 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 low at 25% (only run_id is documented in the schema). The description names the decision and reason fields and implies the article via 'one article', partially compensating, but adds no detail on the include/exclude enum, reason length limits, or the uid reference.

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 ('Record') and resource (an include/exclude decision plus reason for one article), so the agent knows exactly what operation this performs. It does not, however, distinguish itself from the sibling record_screening_decisions, which appears to cover the same conceptual space.

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 no guidance on when to call this versus next_screening_batch, record_screening_decisions, or set_screening_criteria, nor any stated precondition such as requiring an active search run. The agent must infer its place in the workflow from the name alone.

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=false/openWorldHint=false, and 'Save' implies mutation, so the direction is consistent. However, the description omits the significant behavioral trait that supplying replace=true starts a new revision and re-screens everything (only present in the schema), and says nothing about overwrite semantics or required run state. Minimal value added beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short and front-loaded, with the purpose stated first. The second sentence ('Rules: guide("screening")') is cryptic internal shorthand that spends a sentence without conveying actionable meaning to an outside agent.

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 and schema coverage is complete, so return values and parameter details are handled elsewhere. What is missing is the usage context (where this fits relative to start_search and record_screening_decisions) for a mutation tool whose replace flag is destructive to prior screening work.

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 run_id, include, exclude and replace are all documented in the schema, including the consequential replace behavior. The description adds no parameter-level meaning of its own, which matches the baseline 3 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+resource: save inclusion/exclusion criteria for screening. This clearly separates it from screening-execution siblings like next_screening_batch and record_screening_decisions. It stops short of naming any sibling explicitly, 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 only usage signal is the opaque 'Rules: guide("screening")' line, which does not state when to call this versus alternatives such as record_screening_decisions, nor any prerequisites or sequencing. An agent can infer this is a setup step but gets no explicit when/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?

Annotations declare readOnlyHint=false and openWorldHint=true, so the write/external nature is known; the description reinforces this by stating it creates a run. It also discloses the running-state behavior that triggers resume_search rather than a second start_search, which is genuine context beyond the annotations. It doesn't say what happens on re-invocation or failure, so 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?

Two tightly written sentences, front-loaded with the core action and side effect, with the conditional follow-up second. No wasted words.

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 mutation/routing behavior is covered. The only shortfall is the undocumented wait_seconds and limit_per_source, which leaves an agent guessing on latency and result volume.

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 only 50%: project and question_id are documented, but wait_seconds and limit_per_source have no description anywhere. The description only hints at the 'approved question' notion and says nothing about the wait/limit tuning knobs, so it fails to compensate for the coverage gap.

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 (search) and resource (literature databases) and adds the important side effect that it creates a run in the project. It does not name sibling boundaries beyond resume_search, but an agent can distinguish it from list_articles/fetch_articles. Clear but not fully differentiated from the broader sibling set.

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 precondition (an approved question) and an explicit alternative path: when search_status is 'running', call resume_search(run_id) instead. That is concrete when-to-use guidance, though it lacks explicit when-not-to-use conditions or rate/cost caveats.

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait: it is a human-in-the-loop gate where the agent must present the result and pause for researcher approval before proceeding, plus a pointer to the governing ruleset guide('question').

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 purpose and output, then the approval step and rules pointer. No filler, though 'Rules: guide("question").' is telegraphic enough that its intent is slightly opaque.

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, and the HITL step is covered. However, for a tool whose input is a deeply nested ResearchQuestion (framework, components, filters), the description offers only a guide reference and no orientation on constructing or when to reject a question, leaving meaningful gaps at this complexity level.

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?

Top-level schema description coverage is 0%, so the description must compensate for the 'sources' and 'question' parameters, but it says nothing about their format, defaults, or the framework/component structure beyond a terse 'guide("question")' pointer. The only parameter-relevant help is delegated to another tool rather than explained 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?

States a specific verb and resource ('Check a drafted PICO/PCC search question') and names the downstream consumer ('return a question_id for start_search'), which distinguishes it from siblings like start_search. An agent knows exactly what this tool produces and where that artifact goes.

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 mention of returning a question_id 'for start_search' implies this runs before search, and 'Show the result to the researcher and wait for approval' adds a workflow step, but there is no explicit when-to-use clause or exclusion relative to siblings such as start_search or guide. Usage is inferred rather than stated.

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 and openWorldHint=false, so the safety profile is covered structurally. The description adds useful consumption context ('each sized for one fresh subagent') but says nothing about rate limits, task ordering, or what happens across steps; the cryptic 'Rules: guide("wiki")' adds little.

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 the entry-point instruction front-loaded. The trailing 'Rules: guide("wiki")' is terse to the point of ambiguity but cheap in length.

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 one parameter is fully documented. However, for a workflow-orchestration tool competing with many wiki/synthesis siblings, the description leaves the relationship to next_wiki_article and next_synthesis unclear.

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 there is a single run_id parameter already documented in the schema ('Run ID from start_search'). The description adds no further parameter meaning, 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?

The description states a specific action (fetch the current step as self-contained tasks) tied to a resource (the wiki build/update workflow) and marks itself as the entry point. It is distinguishable from siblings like next_wiki_article or guide, though the phrasing 'the current step as self-contained tasks' is slightly abstract.

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?

'Start here to build or update the wiki' gives a clear entry-point cue, implying use at the beginning of a wiki workflow. It does not name alternatives (e.g., next_wiki_article, guide) or state when-not to use it, so guidance is 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.