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

With no annotations, the description carries the transparency burden. It discloses important behaviors: upfront validation of the entire PMID list and propagation of language, output size, and output directory into every request. These are meaningful operational details beyond the tool's basic purpose, though it omits potential error behavior or return specifics.

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 core purpose, followed by a concise behavioral qualifier. Every word contributes value; no filler or redundancy.

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 batch tool with an output schema, the description covers the key contextual aspects: what it does, sequential processing, validation, and parameter propagation. It does not mention scalability limits or failure handling, but the presence of an output schema partially fills the return-value gap, making this adequate though not exhaustive.

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 adds context for three parameters (language, output size, output directory) by explaining they are propagated to all generations, which helps clarify their role. However, it says nothing about the remaining parameters (pmids, figure_type), leaving some gaps in semantics.

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 purpose: 'Generate academic figures for multiple PMIDs in sequence.' It uses a specific verb ('Generate'), identifies the resource ('academic figures'), and distinguishes this batch tool from single-generation siblings by emphasizing 'multiple PMIDs' and 'batch mode.'

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 the primary use case: when multiple PMIDs need figure generation. It says 'Batch mode validates the full PMID list up front...' which signals this is the batch counterpart to a single-PMID tool. However, it does not explicitly name alternatives or state exclusions, so it stops short of full guidelines.

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 mention whether input images are modified, what output format is produced, or any side effects, offering minimal 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 single sentence is concise and front-loaded with the core purpose, earning its place. However, it is under-specified for the tool's complexity, making the length inappropriate for the richness of available 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 six parameters, no annotations, and an output schema, the description is severely incomplete. It does not describe how panels correspond to labels, the nature of the output, or any processing details, making it inadequate for correct tool 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%, and the description adds no information about the six parameters. It fails to explain the roles of panels, labels, title, caption, citation, or output_path, leaving the agent without semantic context beyond 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 clearly states the tool's function: compositing multiple panel images into a publication-ready figure. The verb 'composite' and resource 'multiple panel images' specify the action and target, distinguishing it from siblings like generate_figure or edit_figure.

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 alternatives. It does not mention any prerequisites, typical use cases, or exclusions, leaving the agent to infer usage solely from the tool name.

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. It discloses the output_format parameter and gives examples of feedback, which is helpful, but it does not explain whether the original image is preserved, what prerequisites exist (e.g., existing image_path accessibility), or what the return value is. The description is not misleading but omits key behavioral traits.

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, with the core purpose stated in the first sentence, followed by one relevant parameter detail and practical examples. Every sentence earns its place, and the structure is front-loaded with the most important information. No fluff 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?

The tool has moderate complexity (4 params, no annotations, and an output schema is indicated but not detailed). The description covers the basic purpose and a key parameter, but it does not explain how this tool differs from multi_turn_edit, what image types are supported, or any operational constraints. It is adequate for a simple tool but not fully complete for an agent to confidently select it.

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 no descriptions (0% coverage), so the description must compensate. It does provide valuable detail for output_format ('Optional final raster delivery type such as png, gif, jpeg, or webp') and uses examples to illustrate the feedback format. However, the other three parameters (image_path, output_path, feedback) rely on self-explanatory names and receive no explicit clarification, leaving the compensation incomplete.

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 a specific action ('Refine an academic figure') and the method ('using natural language feedback'). This distinguishes it from sibling tools like generate_figure (creation), verify_figure (validation), and composite_figure (combination), all of which have different verbs and resources.

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 this tool is for refining existing figures with feedback, and the examples show the kind of natural language input expected. However, it does not explicitly state when to use this over siblings like multi_turn_edit, nor does it mention any exclusions or alternative tools. Usage context is present but not fully persuasive.

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 full behavioral context. It lists the eight evaluation domains, which gives insight into what aspects are assessed. However, it does not disclose whether the tool is read-only, whether it writes any files, or what the output schema represents beyond what might be in the external output 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?

The description is extremely concise, with one main sentence and a list of domains. It is front-loaded with the verb and resource, and every word contributes to understanding the tool's purpose. There is no fluff 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?

Given the tool has three parameters and a nontrivial evaluation process (8 domains), the description is too thin. It does not explain how the checklist is applied, what inputs are used, or any constraints. Although an output schema exists, it is not included here, and the description alone leaves the agent under-informed 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% and the description provides no explanation of the parameters (image_path, figure_type, reference_pmid). The parameter names are self-explanatory to some degree, but the description fails to add any meaning or clarify defaults or formats, making the tool ambiguous for an 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 tool evaluates an academic figure using a specific 8-domain quality checklist and lists the domains. It identifies the resource type (academic figure) and the action (evaluate), but it does not explicitly distinguish itself from the sibling tool 'verify_figure' which may also assess figures.

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 provided on when to use this tool versus alternatives. The description implies its use for figure evaluation but fails to mention prerequisites, exclusions, or comparison to the similar 'verify_figure' tool. There is no explicit 'when to use' or 'when not to use' 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 adds some behavioral context: internal planning when a source brief is provided, and internal output_format conversion 'when possible.' However, it omits side effects like file overwriting, permission needs, or failure modes, which are important for a generation 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 under 100 words and front-loaded with the core purpose. The phrase 'Single high-level entrypoint' is slightly redundant with 'let the use case plan internally,' but overall 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 high-level workflow is clear, and the output schema exists so return values need not be described. However, many input parameters remain unexplained, and the relationship to sibling tools like plan_figure or edit_figure is only implicit, leaving room for more guidance.

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 are 12 parameters with 0% schema description coverage, so the description must compensate. It explains output_format and figure_type in some detail and mentions planned_payload/source brief, but leaves most parameters (language, output_dir, output_size, source_kind, target_journal, etc.) undocumented, providing only partial 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 clearly states the tool generates a publication-ready visual asset, with a specific verb and resource. It distinguishes itself as the 'single high-level entrypoint' among siblings, and lists supported figure types, giving clear scope.

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 explains when to use the tool: as a high-level entrypoint where callers can provide a planned_payload or a source brief. It implicitly differentiates from more granular siblings like plan_figure and edit_figure, but does not explicitly state when not to use it or name alternatives.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states the return context (review history, lineage) but does not explicitly confirm read-only behavior or mention any side effects, permissions, or limitations. The mention of 'load' hints at a safe read operation, but it is not explicitly 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 a single, front-loaded sentence that conveys the core purpose without any fluff. Every word adds value.

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 an output schema, so return values need not be explained. The description covers the main action and key context. It lacks mention of the include_lineage toggle and usage distinctions from siblings, but overall it is reasonably complete for a fetch-detail tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to include_lineage via 'lineage context' and implies manifest_id as the target manifest. However, it does not explain the boolean's toggle capability or provide additional syntax detail. The schema's default true and field names offer some inherent clarity.

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 specifies a single manifest load with full review history and lineage context, distinguishing it from list_manifests and other sibling tools. The verb 'load' and the qualifiers make the tool's scope 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 explicit guidance on when to use this tool versus alternatives like list_manifests or replay_manifest is provided. The description implies use for detailed single-manifest inspection but does not state exclusions or alternative scenarios.

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 burden. 'List' implies a read-only operation and 'recent' suggests a time-ordered subset, but there is no explicit statement about side effects, ordering, or pagination. For a simple list tool, this is adequate but not rich.

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 wasted words. It states the action, object, and purpose efficiently.

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 low-complexity list operation with an output schema present, the description adequately conveys purpose and scope. The term 'recent' is somewhat vague, but given the optional limit parameter and domain context from siblings, no critical information is missing.

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

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

Schema coverage is 0%, but the only parameter 'limit' is self-explanatory with a default of 20. The description does not mention the parameter, but the schema's property name and default provide sufficient semantic clarity; little compensation is needed.

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 specific verb 'List' with resource 'manifests' and adds purpose 'for replay or retargeting'. This clearly distinguishes it from siblings like replay_manifest, retarget_journal, and get_manifest_detail.

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

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

It provides clear context by indicating the tool is for viewing recent manifests in preparation for replay or retargeting operations. It does not explicitly name alternatives or exclusions, but the sibling tool names make the intended use obvious.

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

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

With no annotations, the description carries the burden of disclosing behavior. It mentions that each turn builds on the previous result and instructions are applied in order, which is valuable. However, it omits details like whether the original figure is modified or a new file is produced, limits on turns (max_turns), and error handling.

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 and front-loaded, stating the core purpose first, then adding useful details and examples. The parameter explanation is included inline, which is acceptable given the schema lacks descriptions, but it could be tightened.

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 covers the core behavior and gives examples, and an output schema exists so return values need not be detailed. However, it lacks explicit guidance on max_turns semantics, path requirements, and how to compare with single-turn edit_figure, making it only partially complete for an agent.

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 explain all parameters. It only explains 'instructions' with examples, while 'image_path' and 'max_turns' are left unspecified. Although 'image_path' is self-explanatory, 'max_turns' is not described at all, leaving a significant 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?

The description clearly states the tool's purpose: iteratively refine a figure via multi-turn editing. It uses specific verbs ('refine', 'edit') and identifies the resource ('figure'), while distinguishing from siblings like edit_figure by emphasizing the multi-turn, sequential nature.

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 conveys when to use the tool (for iterative corrections needing multiple dependent edits) and provides concrete examples. It doesn't explicitly name alternatives or state when not to use it, but the multi-turn framing implies a preference over single-turn alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the tool returns a structured plan, stores the output_format preference in planned_payload, and enables CJK text fidelity guardrails and model escalation. It does not mention any side effects or state changes, but the planning nature and the explicit 'before generation' phrasing imply a non-destructive 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?

The description is well-structured with a clear opening purpose and separates key parameter guidance into labeled paragraphs. It is appropriately sized for a planning tool with many optional inputs, though some sentences could be tightened. Overall, it earns its place without being 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?

With 12 parameters, an output schema, and no annotations, the description provides essential context for the tool's core decision-making but leaves several parameters unexplored. It covers the main input modes and two critical guardrail/format options, but does not fully explain how to set figure_type, output_size, style_preset, or source_kind. The existence of an output schema reduces the need to describe return values, but the input-side completeness is only partial.

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 12 parameters exist, so the description must add meaning. It explains output_format and expected_labels in detail, and clarifies the interaction between pmid and the generic source fields (source_title, source_summary, source_identifier). However, it omits semantics for many other parameters (figure_type, output_size, style_preset, target_journal, etc.), leaving their meaning to rely on schema titles and defaults.

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 'Plan the best figure type, route, and guardrails before generation', which states a specific verb and resource. It clearly distinguishes the tool from siblings by emphasizing its pre-generation planning role and its output of a structured plan for choosing among direct image generation, SVG-style rendering, or chart routes.

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 usage context: it is meant to be used 'before generation' and explicitly describes the two input modes ('Provide either pmid or a generic source brief'). It also explains when generic planning is appropriate. However, it does not explicitly name alternative tools or state when to prefer them, so it stops short of full exclusion guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses major behavioral traits: local code-only operation, no provider calls, and the difference between resizing vs metadata-only when print dimensions are omitted. However, it does not state whether the original file is overwritten, where the output goes, or if existing files are modified, which is important for a tool that resizes images.

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 clear first sentence followed by only the most essential caveats and a terse parameter note. No sentence is wasted, and the layout makes key behavior easy to scan.

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

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

Despite having an output schema, the tool has 8 parameters, no annotations, and missing descriptions for half of them. The description does not explain output_path behavior, upscaling implications, aspect ratio handling, or explicit selection criteria versus sibling tools, leaving notable gaps for an agent to operate reliably.

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 adds meaning for width_mm/height_mm (final print size), target_dpi (metadata value), and output_format (raster delivery type). But schema coverage is 0%, and parameters like image_path, output_path, allow_upscale, and preserve_aspect_ratio receive no explanation beyond their titles/defaults, leaving the agent to infer their semantics.

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

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

The opening sentence uses a specific verb and object: 'Resize a raster image and write publication DPI metadata using code only.' It clearly distinguishes from sibling generation tools by stating it 'never calls image-generation providers,' so the agent knows this is a local post-processing operation.

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 concrete usage direction: pass width_mm and/or height_mm to truly meet 600 DPI, and explains the fallback behavior without print size. It does not explicitly name alternative tools, but the 'code only' and 'never calls image-generation providers' context helps disambiguate from generation-focused 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?

No annotations are provided, so the description must carry the full burden. It discloses that this is a write operation, but it doesn't explain side effects like whether it overwrites existing reviews, manifest existence requirements, idempotency, or any potential errors. The description adds minimal behavioral context beyond the operation itself.

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 action, and every sentence provides useful context. It is efficiently written without unnecessary detail, making it both concise and well-structured.

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 five parameters, no annotations, and a 0% parameter coverage, the description is too sparse to be fully self-contained. It explains the high-level purpose but omits critical context like prerequisites (e.g., the manifest must exist), behavior on duplicate reviews, and the shape of the output, despite the presence of an output schema. The tool is simple enough that the description might suffice for a basic agent, but it leaves several 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?

The schema has 0% description coverage, and the description does not explain any of the five parameters (manifest_id, passed, summary, reviewer, critical_issues). It does not clarify the meaning of 'passed', the content of 'summary', or how 'critical_issues' relates to the verdict, leaving the agent to rely solely on parameter 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 clearly states a specific verb ('Record') and resource ('a host-side visual review' into 'a persisted manifest'), and explicitly distinguishes the use case from siblings by focusing on host-model inspection. It also mentions 'review harness' which adds context, making the 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?

The description says 'Use this when Copilot or another host model inspects the generated image directly and needs to write its verdict back into the review harness,' providing explicit conditions for use. However, it doesn't name alternatives or give when-not-to-use guidance, so it stops short of fully covering the dimension.

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 only describes the basic action, but does not mention what happens during replay (e.g., overwriting outputs, network access, required permissions) or any side effects. The phrase 'using the same prompt' adds a small detail but is insufficient.

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 unnecessary words, earning a perfect score for conciseness and structure. Every word contributes to the core message.

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 too sparse for a tool with an optional output_dir parameter and no annotation context. It does not explain the replay behavior's relationship to other tools or the effect of output_dir, making it incomplete despite the output schema covering return values.

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 two parameters (manifest_id, output_dir) but the description mentions neither, and schema coverage is 0%. The description fails to add meaning to the parameters, leaving users to infer from names alone. No compensation for the lack of schema documentation.

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

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

The description uses a specific verb 'Replay' and identifies the resource as 'previously saved manifest' with the qualifier 'using the same prompt,' which clearly distinguishes it from listing or fetching manifest details. It names the action and the target resource effectively.

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 explicit guidance on when to use this tool versus alternatives like list_manifests or get_manifest_detail. It only states the action, leaving usage entirely implied and offering no exclusion criteria or recommended contexts.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions 'regenerate the figure,' indicating a side effect, but does not disclose whether the manifest is modified in-place, if permissions are required, or if the operation is reversible. This is minimal but not entirely absent.

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 that directly states the action and its effect, containing no redundant information. It is front-loaded with the key verb and resource, making it highly 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?

The output schema provides return value details, so the description need not cover that. However, the tool has three parameters and no annotations; the description lacks guidance on when to use it versus siblings and does not explain potential side effects. It is adequate for a straightforward operation but not fully comprehensive.

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 clarifies that target_journal is a 'journal profile' and manifest_id refers to an 'existing manifest,' but it does not address output_dir. The parameter names are somewhat self-explanatory, but the lack of output_dir explanation leaves a 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?

The description clearly states the tool's specific action: applying a new journal profile to an existing manifest and regenerating the figure. This distinguishes it from sibling tools like generate_figure or edit_figure, making the 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?

The description implies usage when a journal profile needs to be applied to an existing manifest, but it does not explicitly state when to use this tool over alternatives. No exclusions or alternatives are mentioned, so the guidance is only implied.

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

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

With no annotations provided, the description carries the full burden. It discloses the method (vision self-check, 8 quality domains) and the return values (pass/fail, domain scores, missing/garbled labels). It does not mention side effects, but as a verification tool, non-mutating behavior is strongly implied. This is adequate disclosure given the tool's nature.

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: the first sentence states the purpose, the second details method and returns, and the last defines the key parameter. Every sentence earns its place with no fluff or redundancy.

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 covers the tool's purpose, method, and return values, and it explains one parameter. But with four parameters and 0% schema coverage, missing details about image_path, language, and figure_type make it incomplete. The existence of an output schema covers returns, but the input side remains 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 coverage is 0%, so the description must compensate. Only 'expected_labels' is explained in prose ('Exact text strings (e.g. CJK labels) the figure should contain'). The other three parameters—image_path, language, and figure_type—are left to their names and defaults, with no additional meaning provided. This is a significant gap for a tool with four parameters.

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 and resource ('Run the automated quality gate on a generated figure') and adds detail about vision self-check and CJK verification. It is clear, but it does not explicitly distinguish itself from the sibling tool 'evaluate_figure', which likely has overlapping functionality.

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 'automated quality gate' implies it is used after figure generation for validation, and the focus on CJK labels suggests a specific use case. However, there is no explicit guidance on when to use this tool versus alternatives like 'evaluate_figure', nor any stated prerequisites or exclusion criteria.

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