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

With no annotations, the description carries the full behavioral burden. It usefully discloses a verification pass ('every output is reopened and checked') and partial-fidelity reporting, which is real value beyond the schema. But it omits write-side behavior: overwrite semantics when the output exists, whether the 'password' parameter is for encrypted inputs or outputs, and permission requirements.

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?

Terse, front-loaded, and every sentence carries information: the capability matrix first, then the special multi-input rule, then the validation/reporting behavior. No filler or restatement of the title.

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 9-parameter mutation tool with no output schema and no annotations, the description covers the conversion routes, multi-input bundling, and result reporting. Remaining gaps are the return shape beyond 'reports what could not be carried over' and output-overwrite behavior.

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 already 89%, so the baseline is 3, but the description adds routing meaning the schema lacks: which parameters apply to which conversion (dpi/pages for PDF→images, pageSize for images→pdf, sheet for table export) and that 'paths' bundles multiple images in order with 'path' first.

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

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

States a specific verb ('Convert') plus resource ('file formats') and then enumerates the exact supported conversion routes (PDF→jpg/png, images→pdf, XLSX/CSV→csv/json, HWP/HWPX→pdf/hwp/hwpx). This clearly separates it from siblings like pdf_edit, image_edit, and doc_read.

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

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

The conversion matrix effectively tells the agent when this tool applies versus editing siblings, and it clarifies the special multi-input case ('several paths become one PDF'). It does not, however, state exclusions (e.g., when to prefer pdf_edit or image_edit for in-place changes) or prerequisites such as the absolute-path requirement.

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 present, so the description carries the full behavioral burden. It discloses that HWP/HWPX work without Hancom Office (a useful environmental fact) and that markdown preserves structure where available, but it doesn't mention error behavior (e.g., unsupported formats, encrypted files without a password) or output size limits.

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

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

Two compact sentences that front-load the supported formats and end with a usage cue. No filler, though the parenthetical about Hancom Office is a tangent that slightly dilutes 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?

For a 3-parameter read tool with no output schema, the description covers the essential purpose, supported formats, and a basic usage condition. It could be more complete by mentioning what the extracted output looks like or how errors are handled, but it's adequate 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 100%, so the schema already documents all three parameters with useful details (absolute path requirement, markdown vs text semantics, password usage). The description adds no parameter-specific information beyond what the schema provides; baseline 3 is appropriate.

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

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

States a specific verb (extract text) and the exact resource types it handles, including a clarifying parenthetical about Korean word processors. The scope is instantly distinguishable from sibling tools like doc_convert and image_edit.

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 second sentence, 'Use when the model needs to read what a file says,' implies a read context but doesn't contrast with siblings like doc_convert (which likely transforms or outputs a new file) or pdf_info (which likely extracts metadata). No explicit when-not or alternative guidance is provided.

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

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

With no annotations, the description carries the full burden and does well: it discloses that strip_metadata never re-encodes pixels (lossless), that remove_background triggers a one-time 4.4MB model download and always emits PNG, and what the tool returns. It does not say whether the source file is overwritten or how `out` defaults, which keeps it short of a 5.

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

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

Four tight sentences, front-loaded with the operation taxonomy, then the highest-value caveats (lossless strip, model download, PNG output, return values). No filler.

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

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

No output schema exists, and the description compensates by describing the return values (real dimensions and byte size). Operations and key side effects are covered; minor gaps remain around overwrite behavior and how `out` interacts with the source path for an 8-parameter mutation 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 coverage is 63%, with the schema itself already documenting width, height, format, quality, and background. The description adds no parameter-level detail beyond restating the formats and the ops, so it neither compensates for the coverage gap nor exceeds the schema's baseline.

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?

Names the specific verb (edit) and enumerates all five operations (resize, compress, convert, strip_metadata, remove_background), with formats spelled out. This clearly separates it from the document/pdf siblings (doc_convert, pdf_edit) that share the editing domain.

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

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

Usage is implied by the operation list, but there is no explicit when-to-use/when-not guidance, nor advice on choosing among the five ops (e.g. compress vs convert). With no competing image sibling, the routing need is lower, but the op-selection decision is left to inference.

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

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

With no annotations, the description carries the full disclosure burden. It usefully discloses that compress is lossless and clarifies protect/unlock password semantics, but it omits mutation hazards (overwriting outputs, encrypting existing files) and any permission or error behavior. It adds real but partial behavioral context.

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

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

Two short sentences, front-loaded with the operation list, with the indexing caveat placed at the end. No filler.

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

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

For an 11-parameter multi-verb tool with no output schema, the description covers the operation set and indexing convention but never maps which parameters belong to which op (beyond a few schema hints) or describes output/overwrite behavior, leaving gaps an agent must infer from the schema.

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

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

Schema description coverage is already 91%, so the baseline is 3. The statement 'Page numbers are 1-based' is a genuine addition that applies across at/order/pages and is not documented anywhere in the schema, which lifts it above baseline.

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?

Names a specific verb and resource ('Edit PDF files') and enumerates all nine supported operations, so an agent can immediately tell it apart from pdf_info and doc_convert without opening the schema.

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

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

The op list implies when each mode applies, but there is no explicit when-to-use guidance relative to siblings (pdf_info, doc_convert) and no note that non-merge ops take exactly one input file (that fact lives only in the schema). Usage is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It implicitly conveys a read-only inspection operation and discloses what is returned, which is helpful, but it says nothing about permissions, failure modes on encrypted files, or whether it mutates anything. Adequate but with real gaps.

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 terse sentences that front-load the returned fields before the usage hint. Nothing is wasted, though the second sentence is so brief it borders on a fragment rather than substantive guidance.

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

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

For a simple one-parameter inspection tool with no output schema, the description usefully enumerates the return fields so the agent knows what to expect. Given the low complexity, this is close to complete, with only error/edge-case behavior 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?

There is a single parameter, path, and the schema already documents it fully (absolute path required, relative refused) at 100% coverage. The description adds no parameter-level information, so the baseline of 3 for high schema coverage applies.

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

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

The description names the resource (PDF) and enumerates the specific fields returned (page count, page sizes, encryption flag, metadata), which is more informative than a bare restatement of the title. However, it does nothing to distinguish itself from siblings like doc_read or pdf_edit, so a 4 rather than 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?

It offers one usage context, 'Use to verify a conversion,' which implies when the tool is useful. But it names no alternatives and gives no when-not guidance, leaving the agent to infer that doc_read or pdf_edit are the wrong choices for metadata inspection.

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 provided, so description must carry full behavioral burden. It states output formats (PNG/SVG) and security ('Nothing leaves the machine'), which are useful beyond schema. However, it omits important details like permission requirements, error handling, or whether it's idempotent. The security note is a valuable addition.

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 sentences, highly concise, with key facts front-loaded: action, output formats, source, and security. No waste.

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

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

Complete for a generation tool with no output schema; annotations are absent but the description covers core behavior. It lacks details on error cases or required permissions, but these are minor for a self-contained 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 coverage is 100%, so all parameters are fully documented in the schema. The description adds no parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

Clearly states the specific action (generate QR code) and resources (as PNG or SVG from link or text). An agent can instantly understand this creates QR codes, distinct from all sibling document/image 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?

Usage is implied from the clear purpose, but no explicit when-to-use or when-not-to-use guidance relative to alternatives. Given the domain is distinct from siblings, guidance would be minimal anyway.

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