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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context by disclosing that the comparison is both textual (word-by-word) and visual, which is not in the annotations. It stops short of noting format compatibility, ordering effects, or size/rate 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?

A single front-loaded sentence with no filler; the core action and its two comparison modes come first. It is efficient, though the brevity is partly under-specification rather than true conciseness given the undocumented parameters.

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

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

An output schema exists, so return values need not be described. However, with 0% schema coverage, no usage guidance, and no indication of supported file types or the meaning of the two required paths, the description leaves significant gaps for a two-parameter 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% – the two required parameters carry only titles ('Path A', 'Path B'). The description implies both are document versions being compared but never states whether these are file paths, relative paths, or document IDs, nor whether path_a/path_b order affects the diff output. It does not compensate for the coverage gap.

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

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

The description names a specific verb (compare) and resource (two versions of a document) and even specifies the comparison modes: word-by-word and visual. That is enough for an agent to know exactly what the tool produces. It does not, however, contrast itself with any sibling, though none of the listed siblings appear to offer document diffing.

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

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

There is no when-to-use statement, no prerequisites (e.g. both documents must be readable/parsed), and no mention of alternatives such as read_text for extracting a single document. The agent must infer all routing decisions from the one-line purpose.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is clear without description support. The description adds preset tradeoffs (size vs. quality), but does not explain overwrite behavior, output handling, or whether compression is lossy.

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 definition is two short sentences, front-loaded with the core action and then the preset meanings. Every sentence adds useful information without 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?

An output schema exists, so return values need not be described, and annotations cover safety. Still, for a four-parameter mutation tool, the description leaves path/output/overwrite semantics and sibling distinction unexplained.

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 carry parameter meaning, but it only documents the 'preset' values. The required 'path' and 'output' parameters and the 'overwrite' flag receive no explanation in either schema or description.

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

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

The description states a clear action ('Make the file smaller') and lists preset behaviors, so the general purpose is immediately understandable. However, it does not specify the file type or distinguish this tool from nearby PDF siblings such as merge, split, or export.

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 offers no guidance on when to choose this tool over alternatives like export or create_pdf. Preset contexts (email, archivage, impression) help choose a mode, but they do not address tool selection.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the write/safety profile is covered. The description adds a real environmental prerequisite (LibreOffice required for office formats), but says nothing about how 'overwrite' behaves, whether the output path's directory must exist, or what happens on partial failure.

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: the action and artifact come first, the accepted formats follow, and the LibreOffice caveat is tucked into a parenthetical. No filler, nothing that could be dropped without losing 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?

An output schema exists, so return values need not be described. Given that, the description covers the essential contract for this tool: what it produces, what it accepts, and the one blocking environment dependency. The remaining gap is parameter-level detail, which is scored separately under parameter semantics.

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 carries the full burden for three parameters, yet it names none of them. It partially compensates for 'sources' by listing accepted input formats (implying a list of file paths), but 'output' and 'overwrite' are left entirely undefined in both schema and prose.

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

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

States a specific verb and artifact ('Build one PDF') plus the exact source types it accepts, which cleanly separates it from PDF-only siblings like merge and split. It doesn't explicitly name which sibling to prefer, so it stops short of a 5, but an agent can still tell what this tool produces.

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 enumeration of Word/Excel/PowerPoint/ODF/image/text sources implicitly frames this as the cross-format conversion tool, distinguishing it from merge (PDF-in, PDF-out) and export. However, there is no explicit when-to-use statement, no mention of the alternative tools, and no note on limits such as how many sources may be combined.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile (safe, local, non-mutating read) is covered. The description adds the inspection heuristics, which is useful, but says nothing about limits, cost, or how findings are surfaced, so it adds only modest context beyond the annotations.

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

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

One front-loaded sentence with a colon-separated list of concrete signals; every clause earns its place and there is no filler.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile, so the description is nearly sufficient for a simple one-parameter tool. The only real gap is the undocumented 'path' parameter and lack of any usage routing.

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% for the single 'path' parameter, so the description carries the full burden of documenting it and adds nothing – no format, no constraint on what document types are accepted. The description does not compensate for the coverage gap.

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

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

The description states a specific verb ('Look for signs') and resource ('document was altered after it was issued') and enumerates concrete detection heuristics: earlier revisions, hidden text, mismatched dates/producers. This clearly distinguishes it from siblings like compare or pdf_info, which don't frame the task as forgery detection.

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 its use case (checking whether a document was tampered with) but gives no explicit 'use when/when not' guidance and never names alternatives such as compare or pdf_info. An agent can infer the context but gets no routing help.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is known. The description adds one genuine behavioral detail not present in structured fields: the output format is derived from the `output` extension. However, it never says that a file is written, where it lands, or that an existing file is only replaced under some condition, which is exactly the context a write tool needs.

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

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

One sentence, no filler, with the conversion scope front-loaded and the format-selection rule attached. Every clause earns its place.

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

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

An output schema exists, so return values need no explanation. What is missing is input-side completeness: the roles of `path` (source) and `output` (destination) and the effect of `overwrite` are never resolved, so an agent must guess the file-writing contract for a mutation-flagged 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 carry the burden, and it does partially: it enumerates the accepted extensions for `output` and explains that the extension drives behavior, which the schema does not. But `path` and `overwrite` receive no semantic treatment at all, so half the parameter meaning is left undocumented.

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 precise verb (Convert) and resource (a PDF) with the full set of target formats, and explains the selection mechanism (the extension of `output`). It is clearly distinguishable from siblings like create_pdf, merge, or render_page, which do not convert formats. An agent can identify this tool without opening any 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?

Usage is implied rather than stated: the agent can infer 'use this when you need a non-PDF format,' but there is no explicit when-to-use, no exclusions, and no named alternative. With 22 siblings, a sentence on when export is preferable to something like read_text or ocr would be valuable and is absent.

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 readOnlyHint=false already signaling a possible write, the description adds real clarity: rows are written out only when `output` ends in .xlsx or .csv. This conditional-write disclosure is valuable context beyond the annotations. It does not cover overwrite behavior, keeping it short of a 5.

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

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

Two compact sentences, no filler, with the core action front-loaded and the conditional write behavior stated second. 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?

An output schema exists, so return values need not be described, and the conditional write is covered. The gap is the `overwrite` parameter, whose semantics (behavior when the target exists) are undocumented anywhere, leaving a mutation-adjacent behavior ambiguous.

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 across three parameters. It meaningfully explains `output` (extension-driven file write) and implies `path` is the source document, but `overwrite` is left entirely undocumented in both schema and description.

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

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

States a specific verb ('Read') and resource (bank statement / invoice list) plus the produced structure (rows of date / label / amount). It clearly distinguishes this extraction tool from generic siblings like read_text or ocr, though it doesn't explicitly name them.

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?

Naming 'bank statement or an invoice list' implies the document types this tool is meant for, giving implied usage. However, no when-not conditions or explicit alternatives (e.g., ocr, read_text) are provided, leaving the agent to infer the boundary.

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

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

Annotations already declare that this is not read-only, not open-world, and not destructive. The description adds a useful behavioral detail about checkbox values ('yes'/'no'), but it does not explain output behavior, overwrite behavior, or 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?

The description is two short, front-loaded sentences with no wasted words. It is concise, though its brevity contributes to the lack of parameter and usage detail elsewhere.

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 write tool with four parameters, nested values, and no schema descriptions, the definition is too thin. It does not explain the roles of 'path', 'output', or 'overwrite', nor does it provide sufficient context for correct invocation beyond the checkbox encoding convention.

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 carry parameter semantics. It partially explains the 'values' parameter by saying fields are filled by name and checkboxes use 'yes'/'no', but it leaves 'path', 'output', and 'overwrite' entirely undocumented.

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

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

The description gives a specific verb and resource: 'Fill form fields by name.' It clearly distinguishes this from generic PDF operations and implies form-field population, though it does not explicitly name or differentiate against the sibling tool 'list_form_fields'.

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 such as list_form_fields, nor any prerequisites or exclusions. The checkbox value convention is the only usage-oriented detail, but it does not address tool selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: control-digit validation for IBANs, cards and register numbers, and the fact that returned values are masked. It does not mention performance or file-format 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?

Three short sentences, front-loaded with the detected data types and followed by validation and masking behavior. No filler, though the first sentence could have stated scope (whole document vs. page range) more explicitly.

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

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

An output schema exists, so return-value documentation is unnecessary. However, with a required 'path' and an optional 'kinds' parameter completely undocumented, an agent lacks the information needed to invoke the tool correctly, leaving a real completeness 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% for two parameters. The description never mentions the 'path' argument or the 'kinds' selector, so it does not compensate for the schema gap. The list of detectable kinds hints at what 'kinds' might accept but gives no syntax or allowed values.

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 (Find) and resource (sensitive data) and enumerates the exact patterns detected: IBANs, card numbers, national register numbers, VAT numbers, e-mails, phone numbers, birth dates. The purpose is unmistakable and clearly distinct from read_text or redact, though no sibling is named explicitly.

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

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

The use case is implied by the enumeration of detectable data types, but there is no explicit guidance on when to use this versus alternatives like redact (which acts on such data) or read_text. No prerequisites or exclusions are stated.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that it returns field names, types, current values, and page locations, which is useful output context. It does not mention behavior on PDFs without form fields (empty result vs error) or password requirements, leaving a gap.

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

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

The description is a single compact line with no filler, front-loading the returned fields. It is appropriately sized, though the fragment style ('Fillable fields of the form:') is slightly terse rather than a complete sentence.

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 read-only two-parameter tool with an output schema documenting return values, the description covers the essentials of what is returned. However, it omits authentication context for the password parameter, behavior on non-form PDFs, and any connection to the fill_form workflow, leaving it adequate but not 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 schema provides only parameter names and types, not meaning. The description does not explain that 'path' is the PDF file location or that 'password' unlocks encrypted PDFs. However, with only two parameters and an output schema present, the baseline of 3 is appropriate.

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

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

The description states a specific action and resource: listing the fillable fields of a form. Given the sibling list, no other tool provides form field enumeration, so the purpose is unambiguous. It stops just short of an explicit verb phrase ('Lists...') but the intent is clear.

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 versus alternatives. The sibling 'fill_form' clearly depends on knowing field names, but the description does not make that relationship explicit or state any preconditions (e.g., the PDF must contain interactive form fields).

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds a genuine behavioral detail beyond that — 'Each source becomes a bookmark' tells the agent how the merged output is structured. However it omits key behavioral questions: what happens if the output file already exists (the overwrite default of false is never explained) and whether it errors, appends, or clobbers.

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 core action and zero filler. Every clause earns its place.

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

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

An output schema exists, so return-value explanation is not required, but for a file-mutating tool with a 0%-documented schema and a defaulted overwrite flag, the description leaves the agent guessing about destination handling and collision behavior — gaps it should have closed.

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 three undocumented parameters and largely does not. 'In order' usefully implies that the sources array order determines merge order, but output (destination path/format) and overwrite (whether an existing file is replaced) receive no explanation at all.

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

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

States a specific verb (join) and resource (several PDFs) with the scope 'into one, in order.' The operation is unambiguous and distinguishable from the closest sibling (split). It stops short of naming any alternative tool, so it lands at 4.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no reference to alternatives. The only hint is the implied context of combining PDFs, which the agent must infer.

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

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

Annotations declare a write operation (readOnlyHint=false) that is non-destructive and closed-world, and the description meaningfully extends this: it discloses the skip-existing-text rule, the force override, page straightening, and confidence reporting. Gaps remain around the overwrite parameter (what happens to an existing output file) and whether the source PDF is mutated or a new file is written.

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

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

Three tight sentences: what it does, the language-code format, then the skip/force rule. Front-loaded and every clause carries information; zero 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?

An output schema exists, so return details need not be spelled out, and the description still flags the confidence report. However, for a 6-parameter mutation tool it leaves `pages`, `output`, and `overwrite` semantics unexplained, which an agent needs before invoking safely.

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% across 6 parameters, so the description carries the burden. It gives genuinely useful semantics for `language` ('fra', 'eng', 'fra+eng', 'auto') and for `force`, but says nothing about `path`, `output`, `pages` (range syntax), or `overwrite`, leaving four parameters undocumented in both schema and description.

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

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

States a specific verb+resource ('Make a scanned PDF searchable with Tesseract') and adds the mechanism and side behaviours (deskew, confidence reporting). No sibling tool performs OCR, so read_text/replace_text/render_page are implicitly excluded by the 'scanned PDF' framing.

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 rather than stated: the tool is for scanned PDFs, and 'Pages that already have text are skipped unless force=true' tells the agent when to set force. But it never says when to prefer this over read_text or export, nor what prerequisites (e.g., Tesseract availability) apply.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description only needs to add context. It does add that ranges map to original page numbers, which matters because keep/delete/rotate can interact. It omits what happens to unlisted pages, how keep and delete combine, and how overwrite/output behave.

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 set and with no filler. The angle parenthetical is slightly awkwardly placed but costs almost nothing.

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

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

An output schema exists so return values need not be described. For a 7-parameter mutation tool with zero schema descriptions, however, the description leaves too much implicit: the interaction between keep and delete, the destination file requirement, and overwrite semantics.

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% across 7 parameters, so the description must compensate. It explains keep, delete, rotate, and constrains angle to 90/180/270, but says nothing about path, output, or overwrite, leaving 3 of 7 parameters undocumented anywhere.

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 three concrete operations (keep, delete, rotate) on a page resource, which is specific enough to distinguish it from merge/split/compress. It stops short of explicitly naming which sibling to use instead.

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

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

There is no when-to-use guidance, no prerequisites, and no routing to alternatives like split (which also removes pages) or compress. The only constraint given, that ranges use original page numbers, is a scoping note rather than usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds behavioral context by specifying what it inspects (e.g., encryption, form fields, pages without text), but it does not explain handling of password-protected PDFs or the output format, which is partially covered by the 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 a single, front-loaded sentence that efficiently lists the tool's capabilities without wasted words. It is a sentence fragment rather than a full sentence, but it remains clear and appropriately sized.

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

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

With an output schema and annotations covering safety, the description provides enough detail about what is returned. However, it omits usage guidance and parameter semantics, leaving gaps for correct invocation and alternative selection.

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% for two parameters (path, password), and the description does not mention either parameter or how to use them. It fails to compensate for the missing 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 enumerates specific information the tool retrieves: page count, metadata, encryption, form fields, attachments, and pages lacking a text layer. This clearly distinguishes it from siblings like read_text, render_page, or ocr, though it lacks an explicit verb such as 'Retrieve' or 'Get'.

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 on when to use this tool versus alternatives such as find_sensitive_data or extract_transactions. The description only lists outputs, leaving the agent to infer usage.

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

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

Annotations already establish write (readOnlyHint=false), non-destructive, and closed-world behavior, so the safety profile is partly covered. The description usefully discloses that a password controls opening and/or permission restrictions, but says nothing about writing a new output file, overwrite semantics, or irreversibility, leaving notable behavioral gaps for an encryption 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?

A single front-loaded sentence with no filler, which is structurally clean. However, its brevity comes at the cost of omitting necessary detail rather than by elegantly compressing it.

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

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

Although an output schema exists (so return values need not be explained), the 7-parameter surface with 0% schema coverage and thin annotations leaves the description insufficient. It omits the meaning of 'path' vs 'output', overwrite behavior, and the distinction between owner and user passwords.

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?

With 0% schema description coverage across 7 parameters, the description must carry the burden but only loosely maps to 'user_password'/'owner_password' via 'a password' and to 'allow_copying'/'allow_printing' via 'restricted permissions'. It adds nothing for 'path', 'output', or 'overwrite', which are among the most consequential 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 gives a specific verb and mechanism ('Encrypt with AES-256') and names the configurable outcomes (open password, restricted permissions). It does not explicitly state that the encrypted artifact is the input document or name the sibling it complements ('unlock'), so it stops short of full 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 when-to-use guidance, no indication of when to choose this over 'unlock', 'redact', or 'export', and no stated preconditions (e.g., that a source file must exist at 'path'). The agent must infer all of this from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the output ordering ('reading order, page by page'), and says nothing about the password parameter's behavior, what happens when no text layer exists, or error/permission conditions.

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

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

One short, front-loaded sentence with no filler, but the brevity reflects under-specification rather than economy. It is efficient yet too thin to guide invocation.

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

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

An output schema exists so return values need not be explained, but the description omits usage guidance versus ocr/search, the pages format, and the password semantics. For a 3-parameter tool at 0% schema coverage, this leaves the agent under-informed.

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% across three parameters. The description gestures at 'pages given' but gives no accepted syntax (ranges, comma lists, 1-based indexing), and the password parameter is entirely unaddressed in both schema and description.

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

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

The description is a noun phrase ('Text of the document... in reading order, page by page') rather than a verb+resource statement, so the action (extract/read) must be inferred from the tool name. It does scope the resource and ordering, but it never distinguishes itself from siblings like ocr, search, or pdf_info, which is the key ambiguity for a text-extraction tool.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as ocr for scanned documents or search for targeted lookups. The agent is left to guess whether this works on image-only PDFs or only on documents with a text layer.

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

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

Annotations declare destructiveHint=false and readOnlyHint=false, so the safety profile is already covered; the description adds genuinely useful behavior beyond that by clarifying that data is truly removed rather than masked, and that sanitize=true also strips metadata, attachments and scripts. It does not discuss permissions, irreversibility of the output, or how overwrite interacts with the source file.

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

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

Three tight sentences with the core guarantee front-loaded, then parameter mapping, then the sanitize side effect. No filler, though the parameter sentences are terse enough to feel list-like.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description leaves a few gaps (overwrite semantics, only_verified meaning) but is otherwise sufficient for an agent to invoke the tool 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 carries the load for 7 parameters. It usefully explains kinds (find_sensitive_data categories), terms (exact names/phrases) and sanitize (strips metadata/attachments/scripts), but leaves path, output, overwrite and only_verified entirely undefined in both schema and prose.

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

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

States a specific verb and effect ('Remove sensitive data for good: the characters leave the file'), and explicitly distinguishes itself from a visual overlay ('it is not a black box drawn on top'), which routes the agent away from watermark/draw-style siblings. An agent can tell what this tool does 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 reference that `kinds` come from find_sensitive_data establishes the intended two-step workflow (find, then redact), giving clear context for when to reach for this tool. However, it never states explicit when-not conditions or names a competing alternative for destructive vs. non-destructive removal.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the bar is lower. The description does add one behavioral fact beyond the annotations: that the return is a visual image rather than extracted text, which matters since there is no output schema. It says nothing about image format, whether dpi affects output size, or that encrypted PDFs may need a password.

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 short sentence with no filler; the purpose leads and the use cases follow. It is efficient, though the brevity borders on under-specification given four undocumented parameters.

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 four parameters at 0% schema coverage, no output schema, and no parameter documentation, the description leaves the agent guessing about path format, dpi semantics, password handling, and the exact nature of the returned image. The readOnly annotation covers safety but not the operational gaps.

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

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

Schema coverage is 0% for four parameters, so the description must carry parameter meaning and largely fails. 'one page' loosely maps to the page parameter, but path, dpi (including its effect on image quality) and especially password for protected files are entirely unexplained.

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 phrase 'A picture of one page' communicates the resource (a single page) and the output form (an image), but there is no explicit verb such as 'render' or 'convert', so the agent must infer that this produces a rasterized page image rather than a description. It is distinguishable from read_text and ocr by implication, but the differentiation is never stated.

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

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

'to look at layout, stamps, signatures or scans' gives an implied use case for visual inspection, which is more than nothing. However, no alternatives are named (e.g. use ocr or read_text when you need text rather than visuals), and there is no 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so safety is partly covered, but the description adds genuinely useful behavior: the output is re-typeset in the document's own embedded fonts rather than covered by a white box, which affects searchability and visual fidelity. It omits failure modes (e.g. what happens when the string is absent or fonts are unembeddable), keeping it from 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?

A single front-loaded sentence with a clarifying parenthetical; there is no filler or repetition. It is well-formed as prose, though arguably too terse for an 8-parameter mutating tool.

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

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

An output schema exists, so return values need not be described, but with 8 parameters at 0% schema coverage, no usage guidance, and ambiguous path-vs-output and overwrite semantics, the description leaves major gaps for an agent to call this correctly. It is adequate only for the core intent.

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% across 8 parameters, so the description carries the full burden and does not meet it. It never explains path vs output, overwrite, pages scoping, whole_word, or case_sensitive, and its phrase 'everywhere it appears' obscures the existence of a per-page restriction parameter. Only the old/new semantics are loosely implied.

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

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

The description names a specific verb (replace) and resource (a word or phrase everywhere it appears) and clarifies the mechanism — rewriting embedded fonts rather than drawing an overlay — which implicitly distinguishes it from overlay-based siblings like redact. It is clear what the tool does, though it never names a sibling outright.

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

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

There is no when-to-use guidance, no exclusions, and no routing to alternatives such as redact or find_sensitive_data, which are natural competitors for text removal in this sibling set. The agent is left to infer applicability from the mechanism clause alone.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds no additional behavioral context such as return format, result limits, pagination, or authentication requirements. Since the tool has an output schema, some return information might be covered there, but the description itself is sparse on 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, concise sentence that conveys the core purpose. It is front-loaded but extremely sparse, which may be too brief given the tool's complexity and the lack of parameter documentation.

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, 0% schema description coverage, and an output schema that presumably covers return values, the description is incomplete. It does not compensate for the missing parameter documentation, nor does it provide usage context or behavioral details beyond the basic purpose. For a tool with this many parameters, more guidance is needed.

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 none of the five parameters (path, query, password, whole_word, case_sensitive) are documented in the schema. The description does not explain any parameter semantics, leaving the agent with no information about what 'path' refers to, what 'query' accepts, or what 'password' is for. This is a severe 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 describes a search operation that returns occurrences with page and surrounding context, which is understandable. However, it does not specify that it searches within a PDF/document (implied by siblings like read_text and pdf_info), and it does not distinguish itself from sibling tools like find_sensitive_data or replace_text. The purpose is clear 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 explicit guidance on when to use this tool versus alternatives such as find_sensitive_data or replace_text. The description only states what the tool does, leaving the agent to infer usage context from the name and siblings.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds that it creates new PDFs (one per range), which is useful context beyond annotations. However, it doesn't describe side effects on the source file, permissions, or error conditions.

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?

It's a single concise fragment that front-loads the core output, but it lacks a complete sentence and structural clarity, which limits comprehension.

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 4 parameters with no schema descriptions and a complex operation, the description leaves most parameter semantics and operational context unexplained. It is insufficient 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 must compensate. It only illustrates the ranges format via '1-3, 4-8, 9-', leaving path, output_dir, and base_name completely undocumented. This is a significant gap for a tool with 4 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 states the output (one new PDF per range) and gives an example range format, but omits the action verb and the input resource (splitting a source PDF). An agent can infer the purpose from the name and description, but it lacks explicit differentiation from siblings like organize_pages or merge.

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

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

No when-to-use guidance, no alternatives, and no prerequisites are provided. The description simply states what the tool produces, leaving the agent to infer the appropriate 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the password-precondition context; it says nothing about how the original file is handled or the role of the overwrite flag, so credit is limited.

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 short sentence with no filler, and the operative verb is front-loaded. Nothing could be trimmed without losing meaning.

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

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

An output schema exists, so return-value explanation is unnecessary, and annotations carry the safety profile. However, for a four-parameter write tool with zero schema descriptions, the definition omits output-file semantics and overwrite behavior, leaving real gaps 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% across four parameters, so the description bears the full burden and fails it. It hints at the password parameter but says nothing about path, output, or overwrite, leaving the agent to infer input location, destination, and clobber behavior from bare 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?

States a specific verb and resource — 'Remove the password' from a PDF — which is immediately distinguishable from siblings like protect, redact, or compress. The qualifier 'you can open' adds useful scope, but it never names the counterpart tool (protect) the way a 5 would.

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 'a PDF you can open' functions as an implied precondition: you must already know the password, so this is not a cracking tool. That is real but indirect guidance; there is no explicit when-to-use versus protect, and no mention of what happens when the password is wrong.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the write/overwrite safety profile is partly covered. The description adds no behavior beyond that: it does not say whether the source PDF is modified in place, that a separate output file is required, or how the overwrite flag behaves. "Across the pages" mildly contradicts the existence of a pages parameter for subsetting.

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

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

A single tight sentence with the action front-loaded and no filler. It is efficient, though its brevity is partly under-specification rather than true conciseness given the tool's 8 parameters.

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 8 parameters at 0% schema coverage, no parameter explanations in the description, and a write operation that produces an output file, the description is far too thin. The presence of an output schema excuses return-value details, but required inputs and mutation semantics remain undocumented.

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% across 8 parameters, so the schema documents nothing. The description only echoes the text parameter and vaguely implies page scope; opacity, rotation, font_size, output, overwrite, and the pages selector are all unexplained.

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

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

The description names a specific verb ("Stamp") and resource ("text watermark") and gives concrete examples (CONFIDENTIAL, COPY), so the action is unambiguous. It does not, however, differentiate itself from nearby siblings like redact or protect, which also alter page content.

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 choose watermark over redact/protect, no prerequisites, and no mention of when it is inappropriate. The agent must infer usage entirely from the one-line purpose statement.

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