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

No annotations are provided, so the description carries the full burden. It adds the behavioral trait of determinism and says a next-step packet is returned, but it does not disclose whether the tool mutates state, whether prior claim registration is required, or any other side effects. Calling this tool could be read-only or could change claim status; the agent cannot tell.

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

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

The description is a single sentence with no filler, but it is under-specified and uses jargon ('complete next-step packet') without elaboration. It is concise but not well-structured for decision-making.

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?

Although an output schema exists, the description still leaves critical context unclear: when this tool should run relative to register_claims, judge_evidence, or finalize_research, and what state it expects. For a workflow tool with no annotations and minimal parameter guidance, this is not complete enough.

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 only parameter, research_id, has no schema description (0% coverage) and the tool description does not explain what it refers to, how to obtain it, or any constraints. The name and title give minimal context, but the description adds no semantic value beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific operation—'compute deterministic claim resolution'—and an output, but it does not clarify what 'claim resolution' entails or how this differs from sibling tools like judge_evidence, review_claim_tensions, or revise_claim. It is a clear high-level purpose but lacks sibling differentiation.

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 assess_claims versus alternatives, no prerequisites, and no workflow context. The sibling tool names imply distinct roles in a research pipeline, but the description gives the agent no help choosing among them.

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 add meaningful behavioral context: it rejects semantic stance, enforces a bounded operation, and explains the rationale (preventing topical attachment from becoming support). However, it does not disclose what happens when quote verification fails, whether state is mutated, or what the response shape is, so transparency is incomplete.

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

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

The description is compact: the first sentence states the action and scope immediately, and the second justifies the design constraint without excessive padding. The rationale sentence earns its place because it clarifies an otherwise easy-to-miss boundary, though it is slightly longer than strictly necessary.

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 fairly simple and has an output schema, so the description does not need to explain return values. Still, it leaves gaps around the meaning of 'verify quote presence,' the expected format of quotes, and the behavior when a quote is not present in the source. An agent could probably invoke it correctly but might not handle verification failures appropriately without more detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the schema. It only indirectly hints at parameters: 'quotations' implies quote, 'existing claims' implies claim_id, and 'source quotations' implies source_id. It does not explain research_id, bindings as a batch, or constraints on the quote string, leaving the agent to infer most parameter semantics from names alone.

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 opens with a specific verb and resource: 'Bind direct source quotations to existing claims and verify quote presence.' It also explicitly disclaims semantic stance, which clearly separates it from entailment-judgment sibling tools like judge_evidence. This leaves little doubt about what the tool does.

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 provides clear context: use this tool for verbatim quote binding against existing claims, and do not use it for semantic stance or entailment judgment. It does not name the alternative tool explicitly, and it only implies that claims must already exist, but the exclusion is strong and actionable.

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?

Because there are no annotations, the description must carry the full behavioral burden. It discloses the scope of the checks and implies network interactions, but does not mention failure behavior, timeouts, or side effects. Adequate but shallow.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, making it appropriately concise.

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 parameterless tool with an output schema, the description fully covers what the tool does. No return-value explanation is needed because the output schema exists, and the behavior is simple enough that nothing important 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 has zero parameters, so there is nothing for the description to add beyond what the schema already trivially covers. Per calibration guidance, a 0-parameter tool receives a baseline 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Check' and names the exact resources: API key, DNS, and TinyFish Search/Fetch endpoint health. This makes the tool's function immediately clear and distinguishes it from the sibling research tools.

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 provides no guidance on when to use this tool or conditions that would call for alternative tools. While the sibling list is unrelated, the description still lacks any context about when this check should be run.

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 of behavioral disclosure. It does mention that later waves consume a global budget, which is a useful behavioral trait, but it omits any other effects: whether it modifies research state, whether it can be called multiple times, what happens to existing results, or any side effects. The budget note is a small positive, but overall it is far from transparent.

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

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

The description is one short sentence, but it is under-specified rather than concise. It packs no information about the tool's purpose or parameters, so the brevity is not an asset. The single sentence does not front-load any useful content; it is cryptic and leaves too much implicit.

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 has four parameters, including a nested retrieval specification, and an output schema is present. However, the description gives no indication of what queries should look like, what purpose means, how the retrieval spec is used, or what the output contains. For a tool of this complexity, the description is severely inadequate.

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%, meaning the description adds no explanation for any of the four parameters (research_id, queries, purpose, retrieval). The schema itself has minimal descriptions (only for a couple of nested fields), but the top-level parameters are undocumented. The description does not mention any parameter names or their roles, so it fails to compensate for the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'run' and the resource 'retrieval wave', but 'retrieval wave' is jargon and doesn't clarify what the tool actually retrieves or searches for. It does not distinguish this tool from siblings like plan_research or screen_sources, and the name 'discovery_search' is not echoed in the description. It is not a tautology, but it is vague enough that an agent could not infer the tool's core function.

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 'additional retrieval wave' implies this is for follow-up retrievals, and the mention of 'global follow-up budget' hints at a cost. However, there is no explicit guidance on when to use this versus siblings like research_unknowns or review_candidates, and no exclusions or alternatives are named. The agent is left to guess the intended trigger.

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 disclose two meaningful behaviors: execution is concurrent, and only a compact shortlist is returned rather than full results. It does not mention costs, side effects on research state, error behavior, or whether details are discarded, so transparency is partial.

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 wasted words. It communicates the core action, the parallelism, and the output reduction in one compact statement.

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 complex orchestration tool with nested SubagentTask definitions, two required conceptual elements, and many sibling research tools, this description is too thin. It does not explain how research_id relates to tasks, what happens if tasks is null, or how to construct useful subagent tasks, leaving the agent with significant ambiguity.

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 adds almost no parameter-level meaning: it does not explain research_id, tasks, or how tasks map to 'retrieval tracks'. The only indirect hint is that tasks correspond to independent retrieval tracks, which is too weak to compensate for the undocumented research_id and optional tasks parameter.

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 — executing independent retrieval tracks concurrently — and names the output artifact, a compact review shortlist. It is clear at a surface level, though it relies somewhat on the tool name 'subagents' and the vague phrase 'retrieval tracks' to convey what is being dispatched.

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 'independent retrieval tracks' implies this tool is appropriate when sub-tasks can run in parallel, which gives some usage context. However, there is no explicit when-to-use guidance, no comparison to siblings like discovery_search or screen_sources, and no mention of when NOT to use it.

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 absent, so the description must disclose behavior. It mentions 'do not generate prose inside the MCP,' which is a specific behavioral trait, but it does not clarify side effects (e.g., whether it modifies research state, locks it, or creates a new record). The term 'auditable synthesis manifest' hints at output but not mutation or 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?

The description is extremely brief, a single sentence with two clauses, and the primary action is front-loaded. It avoids fluff and is easy to scan. However, the brevity borders on under-specification, preventing a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's likely terminal role in a research workflow, the description is incomplete. It does not mention when in the pipeline to call it, what happens to the research data, or how the output manifest relates to other steps. The output schema exists, but the description itself lacks essential context for correct invocation.

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%, and the description does not explain the 'research_id' parameter beyond its name. There is no guidance on where to obtain it or what format it expects. The description adds zero meaning beyond the schema's basic type declaration.

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 ('Finalize into an auditable synthesis manifest') with a clear resource. It distinguishes itself from other research tools by implying a terminal step. However, it does not explicitly contrast with siblings, 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 guidance on when to use this tool versus the many sibling tools (e.g., plan_research, init_research, assess_claims). The phrase 'do not generate prose inside the MCP' is a behavioral constraint, not usage context. No prerequisites or conditions are given.

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

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

With no annotations, the description carries full behavioral burden. It discloses that the return is a compact protocol state rather than full text, which is useful, but it does not explicitly state read-only behavior, permissions, or side effects. For a get/inspection tool, this is partial coverage.

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 with no filler. The first sentence labels the tool's category and the second states its core output constraint. It is appropriately sized, though it could add parameter context without becoming bloated.

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 description is incomplete for a one-parameter tool with no annotations. It fails to explain the research_id parameter or provide usage context. While the output schema covers the return shape, the missing parameter semantics and no guidance make the overall definition inadequate.

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 does not mention research_id at all. The single required parameter is completely undocumented in both the description and schema, leaving the agent without guidance on what value to provide.

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: 'Returns compact protocol state.' It also distinguishes itself from siblings by explicitly saying 'not full source text,' which differentiates it from get_source_context. The 'Debug/inspection tool' label further clarifies its role.

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 'Debug/inspection tool' label implies it is meant for troubleshooting and inspecting state, but no explicit when-to-use or alternative conditions are given. An agent must infer usage from this context, with no exclusion or sibling comparison.

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 full weight. It usefully reveals that the tool operates on persisted content and does not re-fetch the URL, but it does not mention side effects, failure modes, or any limits on the returned passages. This is adequate but not deeply transparent.

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

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

The description is only two sentences, front-loaded with the action and resource, and every sentence adds useful context. There is no filler or repetition.

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 simple retrieval tool with an output schema present, the description covers purpose and usage context well. However, the missing parameter semantics, especially for research_id, and the lack of guidance on edge cases like an empty query make it only minimally complete for an agent to invoke 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 0%, so the description must compensate for parameter meaning. It hints that 'query' relates to relevance and 'source_id' selects the persisted source, but it never mentions 'research_id' or explains how the optional query behaves when empty. This leaves important gaps for the agent.

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 clearly states the action ('Return'), the resource ('persisted full source content'), and the result ('a few relevant passages'). It also distinguishes itself from re-fetching the URL, making its role clear among the sibling tools.

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 explicitly says 'Use when the client needs a better direct quote without re-fetching the URL,' providing a concrete trigger condition. It does not name alternative sibling tools or give when-not-to-use conditions, so it stops short of a 5.

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 of behavioral disclosure. It usefully explains that FAST preserves hard evidence gates while fetching/reviewing fewer candidates and stopping resolved claims early. But it omits side effects of starting a session, the behavior of BALANCED/EXHAUSTIVE modes, and any persistence or idempotency caveats.

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

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

The description is short, front-loaded with the core action, and every sentence adds useful information. The FAST clarification earns its place without filler or repetition.

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?

Even with an output schema available, this four-parameter initialization tool lacks essential context. The agent cannot safely infer the meanings of contested and max_rounds, the differences between modes, or what state changes occur when a research session is started.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only clarifies the mode parameter by identifying FAST as the default and its tradeoff; topic, contested, and max_rounds are left unexplained, and the BALANCED and EXHAUSTIVE modes are not characterized 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 clearly states the action ('Start') and the resource ('a research session'), with a specific qualifier about latency/coverage profile. It is distinguishable from sibling tools like plan_research and get_research_state, though it never explicitly names or contrasts a sibling.

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 that this tool is the entry point for a research session, and the FAST default gives some call-time guidance. However, it provides no explicit when-to-use guidance, prerequisites, or contrast with plan_research or later research-phase 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?

With no annotations, the description must disclose behavioral traits. It reveals that the server handles evidence integrity, but it does not state whether the operation is read-only or mutating, whether it overwrites existing judgments, or what side effects occur. The phrase 'assign labels' suggests a write operation, but the description is silent on persistence, idempotency, or permission requirements. This is a significant gap for a tool without annotation coverage.

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

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

The description is two sentences, front-loaded with the primary purpose and then clarifying role separation. Every word earns its place; there is no fluff or redundancy. It is compact while still delivering essential scope 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?

Despite having an output schema, its content is unknown. The description lacks details on how to construct the judgments array, the meaning of strength, whether research_id must correspond to an existing research, and what the response contains. The tool is moderately complex (nested array, multiple fields), and with no annotations, the description does not provide enough for an agent to call it correctly without additional 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 0%, so the description must compensate for parameter meaning. The description does not mention research_id, judgments, or any field within EvidenceRelationJudgment. It only vaguely references 'relationship' and 'labels,' which does not clarify how to fill the required parameters or interpret strength. The schema itself provides the enum and default, but the description adds no additional semantic value.

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 clearly states the tool's function: 'Assign bounded semantic relation labels to quote-verified evidence.' It identifies the specific verb ('assign'), the resource ('evidence'), and the scope ('bounded semantic relation labels'). It also distinguishes itself by clarifying the client's sole responsibility (classify relationship between quote and claim), which separates it from siblings like bind_evidence or assess_claims.

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 provides context about division of labor ('The server owns evidence IDs and quote integrity. The client does exactly one semantic task here'), implying when this tool is appropriate. However, it does not explicitly state when to use this tool versus alternatives, nor does it name any sibling or provide exclusion criteria. The guidance is implicit rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action ('explicitly override') without describing effects: persistence, reversibility, downstream validation impact, or whether overriding bypasses safety checks. This is a state-changing operation, yet the consequences are undisclosed.

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

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

The description is appropriately terse and front-loaded with the governing verb. But it is so brief that it borders on under-specification for a tool with three opaque parameters and a state-changing effect.

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, but the description omits essential workflow context: what an atomicity warning is, when it arises, prerequisites for the override, and the effect on downstream stages such as assess_claims or finalize_research. For an override action with governance implications, this is a significant 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 0% and the description names none of the three parameters, leaving 'reason', 'claim_id', and 'research_id' semantically opaque. The description is the only place that could compensate for the empty schema, and it does not.

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 clear action (override) and a clear object (atomicity warning for a maximally atomic claim), distinguishing it from mutation siblings like split_claim and revise_claim. However, it relies on unexplained domain jargon ('maximally atomic claim') and does not explicitly contrast with the closest 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?

No guidance is given about when overriding an atomicity warning is appropriate or required, nor are any exclusions stated. The agent must infer prerequisites (that a warning exists, that an override is justified) from the tool name and surrounding context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Validate and store' implies state changes and validation, but it does not explain what validation entails, whether storage is persistent, whether the tool is idempotent, or what failure conditions might arise.

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

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

The description is a single, front-loaded sentence with no filler. It conveys the action, object, and timing efficiently, though it could offer more context without becoming bloated.

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 and detailed nested schema help an agent construct the call, and the description gives the key timing cue. However, with no annotations and many related sibling tools, it does not fully clarify validation behavior, prerequisites, or how this step relates to init_research and dispatch_parallel_subagents.

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 only mentions 'the research plan.' It does not clarify the semantics of research_id or what qualifies as a valid plan. The nested schema has some field-level descriptions, but the tool description itself adds minimal 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?

The description states a specific verb ('Validate and store') and a clear resource ('the research plan'), with a temporal constraint ('before any retrieval'). This is more specific than a tautology and distinguishes the tool from later retrieval or dispatch operations, though it does not explicitly name a sibling alternative.

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 provides a clear usage condition: call this tool before any retrieval. It does not explicitly mention alternatives or when not to use it, but the 'before any retrieval' phrasing gives enough context to place it in the workflow.

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?

There are no annotations, so the description carries the behavioral burden. It usefully discloses that the server generates every claim_id and that evidence is not accepted, but it does not mention side effects, duplicate handling, validation behavior, or batch-failure semantics. This is adequate but incomplete for a resource-creating tool.

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

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

The description is two concise sentences with the core action and exclusion front-loaded. The second sentence adds a meaningful rationale rather than filler, so every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema and nested ClaimDraft definitions gives the agent some structural grounding, but top-level parameters remain undocumented and there is no guidance on how to construct a valid claims batch. The description is sufficient for tool selection but thin for correct invocation.

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 should compensate by explaining parameters like research_id and claims. It does not: it only implicitly references claims through the tool's purpose and mentions claim_id, but leaves research_id, temporal_mode, atomicity_override, and client_ref semantics to the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('register') and resource ('new claims'), and explicitly excludes evidence, which distinguishes it from the bind_evidence and judge_evidence siblings. The phrase 'Register new claims only; does not accept evidence' makes the tool's scope immediately unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states when not to use this tool: 'does not accept evidence' and explains why claim creation is separated from evidence judgment. It provides a clear boundary but does not explicitly name alternative tools such as bind_evidence or judge_evidence, so it stops short of full alternative 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description says 'Run targeted retrieval' but does not detail side effects, such as whether it modifies research state, requires prerequisites (e.g., research must be initialized), or if it performs destructive actions. It also doesn't explain what happens to the research data after retrieval, or if this is a read-only operation. The output schema is present but the description doesn't clarify the behavior beyond the basic action.

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

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

The description is a single sentence, which is concise and to the point. It front-loads the action ('Run targeted retrieval') and the purpose ('for claims that still need work'). No wasted words. However, it is so vague that conciseness works against it, but structurally it is well-formed. A score of 4 reflects efficiency, but not necessarily clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool—with nested objects, multiple retrieval settings, and a large set of sibling tools—the description is insufficient. It does not explain the expected input format for 'gaps', how the tool integrates with the research pipeline, or what the output packet contains. The output schema is present, but the description's lack of context leaves the agent uncertain about how to prepare inputs. With no annotations and 0% schema coverage, the description fails to provide the necessary context for correct invocation.

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%, meaning the description must compensate for the schema's lack of explanation. The description does not explain any parameters, but the parameter names and structure are somewhat self-explanatory (e.g., 'research_id' and 'gaps' with nested GapPlan). However, the nested objects like RetrievalSpec have default values and some descriptions for fields like domain_type, but this is in the schema, not the description. The description adds no value beyond what the schema implies, so a score of 3 is appropriate as a baseline for minimal compensation.

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 general verb phrase ('Run targeted retrieval') and a resource ('claims that still need work'), but it is vague. It does not specify what 'unknowns' means, how the tool relates to the research pipeline, or what 'compact review packet' contains. It lacks the specificity needed to distinguish it from similar tools like discovery_search or dispatch_parallel_subagents. The title 'research_unknowns' is not elaborated, so the purpose remains ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus alternatives. It mentions 'claims that still need work' but does not explain how this tool fits in the research workflow (e.g., after assess_claims, before finalize_research). With many sibling tools, the lack of when-to-use or when-not-to-use guidance is a significant gap. No alternatives are named.

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 must disclose behavioral traits. It only says this is the preferred path and describes it as a review, but does not state whether it mutates state, has side effects, or returns anything. The agent is left to infer the tool's impact on the research 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?

Two short paragraphs, front-loaded with the purpose, and no filler. Every sentence contributes to scoping or usage, making it easy to parse and understand quickly.

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 description does not explain the expected format of reviews, what happens after submission, or how to fill the many fields like strength or reason. Although an output schema is signaled, it is not shown, and no behavioral context is provided. This is insufficient for a tool that accepts a batch of complex review objects.

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 0% description coverage, so the description should compensate, but it only vaguely maps 'relevance', 'direct quote', and 'semantic relation' to the fields. It does not explain the meaning of verdict, relation enums, strength, or how to set them. The description adds minimal value over the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a unified claim/source review covering relevance, direct quote, and semantic relation. It also differentiates from siblings by naming screen_sources as the pre-claim path and bind_evidence/judge_evidence as low-level alternatives, making the tool's purpose 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?

Explicitly explains when to use this tool: after claim IDs exist, and for both initial evidence and targeted gap evidence. It also names alternatives and deprecates bind_evidence/judge_evidence, giving the agent clear routing logic.

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. It explains the tool's purpose and clarifies that tensions may represent genuine disagreement even when claims are accurate, which is useful. However, it does not disclose any side effects (e.g., whether it modifies claims, idempotency, or constraints on repeated calls). Since this is a record-keeping tool with no obvious destructive behavior, the description is adequate but not rich. A score of 3 reflects the missing details on what happens when called.

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

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

The description is concise: two sentences, front-loaded with the primary action and a usage condition. No wasted words, and the key information is easy to scan. It earns a 5 for efficiency and clarity.

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 relatively simple (two parameters, one nested). The description covers the main purpose and the mandatory condition, but it does not explain the meaning of the parameters or any edge cases like what happens if tensions already exist. The mention of 'after the claim graph is stable' is helpful for ordering, but it could be more explicit about prerequisites or interactions with sibling tools. Given the output schema exists (per signal), return values may be covered there, so this is acceptable but not fully 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%, so the description must compensate. It does not explain the parameters at all. 'research_id' and 'tensions' are not described beyond the schema's field titles. The description implies that tensions are the main payload but does not clarify the structure of ClaimTension (e.g., required fields, purpose of resolution). The agent would have to infer parameter meanings from names alone. This is insufficient for a tool with a nested object.

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 clearly states the verb 'Record' and the resource 'cross-claim tensions', with a temporal condition 'after the claim graph is stable'. It also adds the mandatory condition for contested sessions, which distinguishes it from sibling tools like register_claims or assess_claims. This is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Mandatory once for contested sessions', which gives a clear condition for when to use it. It also implies it is not for non-contested sessions, though it doesn't name alternatives. The phrase 'after the claim graph is stable' provides context on sequencing relative to other steps. However, it could be more explicit about when not to use it or list alternatives, so a 4 is appropriate.

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 transparency burden and does disclose a key side effect: 'The old claim is superseded automatically.' It also adds that the parent is not left unresolved. It does not detail permissions or reversibility, but the core behavioral trait is clearly stated.

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

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

The description is compact, front-loaded with the main action, and every sentence earns its place. The behavioral note and the split_claim contrast are both useful and not redundant.

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 description captures the core operation and distinguishes the sibling, but it leaves domain-specific terms like 'parent unresolved' unexplained and provides no guidance on the replacement draft fields. Since there is no annotation coverage and top-level schema descriptions are absent, a bit more context about expected inputs would make it 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%, so the description should compensate for parameter meaning. It only implies that replacement should be a corrected/narrower version of the claim; it does not explain research_id, claim_id, or how to construct the nested ClaimDraft. Some semantic meaning is added, but it is minimal.

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 ('Replace an incorrect/overbroad active claim') on a clear resource, and immediately distinguishes itself from split_claim. An agent can tell what this tool does and what it does not do.

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 explicitly says 'Use this for semantic revision' and names the alternative 'use split_claim when one claim must become multiple children.' This gives clear when-to-use and when-not-to-use 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state whether the tool is read-only or mutates state, what side effects it has, whether it returns results or just records them, or any permission requirements. The word 'gate' implies filtering but gives no concrete 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?

The description is a single short sentence, so it is concise. However, it is not front-loaded with actionable information; the metaphor obscures rather than clarifies. It is under-specified, which is not effective conciseness. The structure is minimal but at the expense of clarity.

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 tool with a nested object schema, enums, and no output schema, the description is severely incomplete. It does not explain the tool's purpose, inputs, expected outputs, or relationship to the broader research workflow. An agent would have to guess at nearly every aspect of how to call it correctly. The description is inadequate for the tool's complexity.

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 provides zero explanation of the two parameters. It does not mention research_id or screenings, nor the nested structure with source_id, verdict, and reason. The enum values (RELEVANT, PARTIAL, IRRELEVANT) are unexplained. The description adds no semantic value beyond the raw schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the vague metaphor 'semantic source gate' without defining what it means or stating the tool's actual function. It does not explicitly say that it screens sources against a research question and assigns verdicts (RELEVANT/PARTIAL/IRRELEVANT). The purpose is only loosely inferable from the tool name, and it does not differentiate from siblings like review_candidates or get_source_context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. It hints that it operates on a 'server-provided review shortlist' but does not state prerequisites, conditions, or exclusions. There is no mention of when this should be called relative to other steps in the workflow, such as after discovery_search or before judge_evidence.

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 available, the description carries the full burden of behavioral disclosure. It does add a meaningful side effect: 'The parent is superseded automatically,' which is non-obvious and valuable. However, it does not clarify whether this is destructive, whether children are persisted before the parent is superseded, or what validation occurs.

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

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

The description is only two short sentences and every word earns its place. The primary action and the automatic supersession behavior are front-loaded with no filler or repetition. This is appropriately concise for the amount of information it presents.

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 three required parameters, a nested children array, no annotations, and only a minimal tool description, the definition is under-specified for safe agent invocation. The description omits prerequisites such as the parent claim existing, how research_id should be resolved, what constitutes a valid split, and what outcome the caller should expect beyond an output-schema flag.

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 description provides zero parameter-level information for research_id, parent_claim_id, or children. Schema description coverage is reported as 0%, so the description does not compensate for the schema's lack of top-level parameter documentation. An agent gets no guidance on how to construct the children array or what the parent/child semantics are beyond what the raw schema types convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the core operation with a clear verb and object: 'Split a compound claim.' It avoids pure tautology by adding the 'compound' qualifier and the parent-supersession side effect lexically. However, it does not explicitly distinguish itself from siblings like revise_claim or override_atomicity, so it is clear but undifferentiated.

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 or when-not-to-use guidance is provided. The description never names alternatives such as register_claims or revise_claim, and gives no indication of prerequisites or exclusion criteria. The only implied usage context is the vague notion of a 'compound claim,' leaving the agent to infer when this tool is appropriate.

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 behavioral disclosure burden. It meaningfully discloses that the server automatically selects the strongest quote-verified evidence and that provided citations are treated as overrides, not additive suggestions. It does not mention side effects or mutation, but the audit framing plus the override semantics provide useful transparency.

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

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

The description is compact and front-loaded with a one-line summary, followed by a normal-use instruction and the override caveat. Every sentence earns its place; there is no redundant repetition of schema 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?

Given the output schema exists and the parameter semantics are covered, the description provides enough for an agent to call the tool correctly in the normal case and to understand override behavior. It could add prerequisites or state whether this is read-only, but the core workflow is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does: 'research_id only' clarifies the primary input, and 'optional citations are accepted only as explicit client overrides' adds real semantics to the citations parameter beyond the raw schema. The nested CitationCheck fields remain self-explanatory from their names.

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 labels the tool as a 'citation integrity + coverage audit' and clarifies that the server chooses evidence automatically, which distinguishes it from lower-level evidence tools like bind_evidence and judge_evidence. The verb+resource combination is reasonably clear, though 'Server-owned' is slightly jargon-heavy and the difference from sibling tools 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?

It explicitly states the normal call pattern ('pass research_id only') and explains when the optional citations parameter is appropriate ('only as explicit client overrides'). This gives clear context for the common case, though it does not name alternative tools or say when not to use this tool.

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