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

With no annotations provided, the description carries the full behavioral burden. It discloses that verification happens offline against a built-in public key, that the key is persisted to the config file, and that invalid keys are refused and left unsaved. This is substantial transparency for an activation tool, though it could mention overwriting an existing key or the exact return 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 two sentences with no filler. The first sentence front-loads the main action, source, verification method, and persistence. The second sentence efficiently covers error handling and points to the related read-back tool. Every clause 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?

Given a single-parameter tool with no output schema and no annotations, the description covers activation behavior, verification mechanism, persistence, error outcomes, and how to read the result later. The only minor gap is an explicit statement of what the function returns upon success or failure, but the phrase 'refused, unsaved' implies a feedback mechanism. Overall, it is sufficiently complete for an agent to call it correctly.

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

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

The schema already documents the 'key' parameter at 100% coverage, so the baseline is 3. The description adds meaningful semantics by giving the concrete key format ('MCPL1.xxx.yyy'), confirming the key comes from the checkout page, and explaining that malformed or expired keys will be rejected. This goes beyond the schema's one-line description.

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

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

The description states a specific action ('Activate a Pro key'), the exact key format ('MCPL1.xxx.yyy'), the source ('from checkout'), and the core mechanism ('verified offline against a built-in public key'). It also differentiates itself from the sibling license_status by noting that license_status reads the activation back, so there is no ambiguity about which tool does what.

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 clear context: use this when you have a Pro key from checkout that needs to be activated. It also points to license_status as the read-back tool, which implies when to use a related sibling. It does not explicitly spell out 'do not use for checking status' or list other alternatives, but the context is strong enough to avoid misuse.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It discloses that the call is local ('no network') and argument-free, and it mentions a specific explanatory behavior. The word 'Report' implies read-only, though it does not explicitly state non-destructive or permission requirements; this is adequate for a status command.

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 with no filler. The first sentence lists the output fields; the second adds constraints and the sibling pointer. Every clause contributes meaningful 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?

For a zero-parameter status tool with no output schema, the description lists the expected output fields, behavioral constraints, and the relevant alternative tool. Nothing an agent needs to call it correctly is missing.

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

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

The schema has zero parameters and the description reinforces this with 'No arguments'. It adds value by listing the reported fields, helping an agent understand what the empty input will yield. The baseline for zero-parameter tools is high, and the description meets it.

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 ('Report'), a clear resource ('this server's licence state'), and enumerates the exact fields returned. It also names the sibling 'license_activate' as the tool that does something different, so an agent can distinguish them immediately.

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 explicit usage constraints: no arguments, no network, and explains a free-tier refusal. It also directs the agent to license_activate when the task is to install a key, serving as an explicit pointer to the relevant alternative.

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?

The description asserts 'Read-only', but the annotations declare readOnlyHint=false (and idempotentHint=false). A page count is inherently a safe, idempotent read, so the annotation flag contradicts the stated behavior and could mislead an agent about safety/idempotency. The otherwise useful failure semantics ('a file that cannot be read is reported on its own row') cannot rescue a direct contradiction with structured metadata.

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, front-loaded with the primary output ('page count per file plus the total'), then error semantics, then cost. Every clause carries information; nothing is padding.

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

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

With no output schema, the description compensates well by describing return values (per-file counts, total, readable count) and partial-failure behavior. The main gap is the contradiction with readOnlyHint rather than missing content, plus no note on path resolution or how unreadable files are surfaced.

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?

Only one parameter (paths) with 100% schema description coverage, so the schema fully documents it (array of file paths, minItems 1). The description corroborates multiplicity ('any number of PDFs') and implies an array, but adds no path syntax, glob, or ordering detail beyond the schema. Baseline 3 for full coverage.

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

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

States a specific verb (count pages) and resource (PDFs), and even specifies the output shape: per-file count plus total plus readable count. It differentiates itself from single-file siblings like pdf_info and pdf_pages by emphasizing batch scope ('for any number of PDFs'), though it never names a sibling explicitly.

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

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

'For any number of PDFs' implies the batch use case, and the description hints this is free/unlimited so there's no reason to batch conservatively. But there is no explicit when-to-use vs. alternatives (pdf_info, pdf_pages) and no exclusions or prerequisites 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?

The description asserts 'Read-only, never modifies the file', while the annotations declare readOnlyHint=false, which explicitly marks the tool as not a read-only operation. This is a direct conflict between the prose and the structured safety metadata, so per the rubric the score is 1 and the contradiction is flagged.

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 an enumerated return list; nothing is padded. The leading 'Call this tool to' is mild filler, but the payload arrives immediately and every clause carries information.

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

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

With no output schema, the description correctly carries the return-value burden and enumerates the fields an agent will receive, which is the key requirement here. It does not state behavior for malformed or password-protected files, leaving a small gap for a single-parameter inspection 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?

There is a single parameter and schema description coverage is 100%, so the schema already documents the 'path' argument including tilde expansion and relative-path resolution. The description adds nothing further about the parameter, which is the expected baseline when the schema carries the burden.

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+resource (inspect a PDF) and enumerates exactly what the inspection yields: page count, page sizes in points/mm, paper name, metadata fields, and encryption state. That enumeration implicitly separates it from pdf_count, pdf_pages, and pdf_text, but no sibling is named explicitly, 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?

The opening imperative 'Call this tool to inspect a PDF' implies the usage context but offers no when-not guidance and no routing against near-siblings such as pdf_count, pdf_pages or pdf_text. The 'Free tier: unlimited' note is useful operational context but is not selection 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?

Adds real behavioral context beyond annotations: inputs are never modified, page sizes are kept as-is (mixed sizes possible), and the result reports that. Free-tier cap of 5 files is disclosed. Annotations already state destructiveHint=false and readOnlyHint=false; description reinforces the non-destructive behavior of inputs.

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: action and ordering first, then output behavior (mixed sizes), then input safety and limit. Zero waste and well front-loaded.

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?

Covers action, ordering, output quirk (mixed page sizes), input immutability, and a service limit. No output schema exists, but the description says the answer reports page-size mixing. Missing explicit overwrite guidance, though the schema covers it fully.

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 paths, out_path, and overwrite are already documented with semantics including default false for overwrite. The description only mentions ordering of inputs, which duplicates the paths description. 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 (join/merge) and resource (PDFs) with the ordering scope ('in the order given'). An agent can distinguish it from pdf_split, pdf_reorder, and other pdf_* siblings without opening schemas.

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?

Implies usage ('join several PDFs into one') but offers no explicit when-to-use vs alternatives like pdf_reorder or pdf_split. The free-tier limit is a useful constraint but not a usage routing rule.

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?

The description adds useful behavioral context beyond the annotations: the input PDF is never modified, duplicate page requests produce duplicate pages, and free-tier files are limited to 30 pages. It does not contradict the annotations, though it leaves overwrite/failure behavior to the schema.

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

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

Four short sentences, front-loaded with the core action and immediately followed by the most important edge cases. 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?

Given the annotations and 100% schema coverage, the description covers purpose, page-order semantics, duplicate behavior, input immutability, and tier limits. It omits return/output details, but no output schema exists and the write behavior is already well documented in 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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by clarifying that asking for the same page twice copies it twice, which is not explicit in the schema's example.

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: pull selected pages into one new PDF. The phrase 'in the order written' and the duplicate-page example distinguish it from merge, split, and reorder siblings without needing to 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?

The description implies the use case by saying 'Call this tool to pull selected pages into one new PDF' and gives a free-tier size limit, but it does not explicitly say when to use this tool versus siblings such as pdf_split, pdf_merge, or pdf_reorder.

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 idempotentHint=false, so the safety profile is covered. The description adds the validation rule ('name every page exactly once, so nothing drops by accident') and a cryptic 'Pro.' marker suggesting a plan requirement, but says nothing about overwrite semantics or that the source file is untouched.

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 tight sentences with the action front-loaded and the key constraint immediately after. The trailing 'Pro.' is terse to the point of being unclear, and 'Call this tool to' is minor 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 a 4-parameter write tool with no output schema, the description covers purpose, the critical validation constraint, and the sibling to use instead. Only the overwrite/file-clobbering behavior and any permission requirements are left implicit, and those are partly handled by 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 coverage is 100% and every parameter (path, order, out_path, overwrite) is documented in the schema itself. The description's mention of the order constraint duplicates the schema text and adds no new syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb+resource ('write a new PDF with pages in the order you give'), which is clearly distinct from pdf_pages/pdf_split. It does not differentiate itself from the other PDF writers (pdf_merge, pdf_rotate), but the core action is unambiguous.

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

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

Names the alternative explicitly: 'use pdf_pages for a subset', giving a clear when-not condition. No exclusion guidance relative to pdf_merge or pdf_rotate, so it stops short of a full routing statement.

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 (readOnly=false, destructive=false), and the description adds genuinely useful behavior: rotation is additive to existing page rotation and a new file is written rather than in-place editing. It also discloses a 'Free tier: files up to 30 pages' operational limit, which structured fields do not capture.

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 short sentences with the core action front-loaded and the tier limit placed last. The opening 'Call this tool to' is mild filler, but there is no real 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?

For a 5-param mutation tool with no output schema, the description covers the essentials an agent needs: additive rotation behavior, new-file output, and a free-tier size cap. Page-range and overwrite semantics live in the schema, which is acceptable at full coverage.

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 five parameters are already documented, including the additive-rotation note and the 90/180/270/-90 values. The description largely restates those semantics (multiple-of-90, clockwise-for-positive) rather than adding new meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ('turn pages by a multiple of 90 degrees') and even clarifies the direction convention. However, it never distinguishes itself from the many pdf_* siblings (pdf_reorder, pdf_stamp, pdf_pages), so an agent must infer the difference on its own.

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

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

Usage is only implied via the phrase 'for a sideways scan.' There is no explicit when-to-use, no when-not-to-use, and no named alternative among the large pdf_* family, leaving selection guidance thin.

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 annotations already declaring readOnlyHint=false and destructiveHint=false, the description usefully adds that 'the input is never modified' and discloses a free-tier limit of 30 pages, which are real operational constraints not present in the structured fields. It stops short of describing the return value or how partial failures across multiple output files are handled.

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 action and immediately followed by the range semantics and the safety guarantee. No filler, though the range example duplicates the schema verbatim.

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?

Covers the operation, range syntax, non-destructiveness of the input, and a tier limit, but with no output schema and four parameters it never says what the tool returns (e.g., the list of written file paths) or how the {n}/{range}/{name} pattern interacts with multiple ranges. Adequate but with a visible gap for a multi-file write 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 100%, so the baseline is 3. The description restates the ranges format already fully documented in the schema and says nothing about out_path_pattern or overwrite, so it adds no meaning beyond the structured fields.

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 action and outcome: 'write one new PDF per range', which clearly identifies a split operation on a PDF resource. An agent can distinguish it from read-oriented siblings like pdf_text or pdf_info, though it never explicitly contrasts itself with pdf_merge (the other multi-file write 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?

Usage is implied by the verb ('Call this tool to write one new PDF per range') and the description supplies a concrete range syntax example, but there is no when-to-use vs when-not guidance and no alternative named among the many pdf_* siblings. The free-tier note hints at a scope boundary but not a routing rule.

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 agent knows it writes without destroying. The description adds valuable context beyond annotations: it writes a new file, leaves the input untouched, and restricts free-tier use to the PAID and DRAFT presets in preset colours. This is strong transparency, though it omits overwrite and output details covered in the schema.

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

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

Three short sentences, front-loaded with the core action and followed by write behavior and tier limits. Every sentence earns its place; 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?

The description covers the core action, the write-to-new-file behavior, input preservation, and free-tier limits, which is sufficient given 100% schema coverage for parameters. It does not explain the output/return or overwrite edge case, but with no output schema and overwrite documented in the schema, these are minor gaps.

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

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

Schema description coverage is 100%, so the schema already defines all nine parameters, including text presets, colour, pages, opacity, position, font size, and overwrite. The description adds only a general reference to 'colour and position you choose' and repeats the free-tier preset constraint for text/colour, which is already in the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states a specific verb ('draw a word such as PAID or DRAFT across the pages') and resource (PDF pages), with concrete examples of the stamped text. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling pdf_watermark_business, so sibling differentiation is missing.

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

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

The description only says 'Call this tool to draw a word...' but gives no when-to-use conditions, no when-not-to-use, and no alternatives (e.g., pdf_watermark_business). Usage is implied by the purpose, but explicit guidance 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?

Annotations already cover read-only, idempotent, non-destructive and closed-world, but the description adds genuinely new behavioral context: scans yield nothing, custom-encoded fonts yield glyph indices, and the tool reports which case occurred. It also discloses a 'Free tier: unlimited' cost/quota trait the annotations do not carry.

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 short sentences, front-loaded with the core purpose and the failure modes immediately after; nothing is padded. The 'Read-only' clause is mildly redundant with readOnlyHint=true, which keeps it from a 5.

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

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

With no output schema, the description carries the return-value burden and does explain the two degraded outcomes and that the tool signals which applies. It does not describe the shape of a normal successful return (e.g., plain concatenated text vs. per-page), leaving a modest gap for a read 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 100% with only two simple parameters (path, pages) fully documented in the schema, including the page-range syntax. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ('best-effort text extraction from standard-font PDFs'), and the scoping to standard-font PDFs separates it from generic PDF siblings such as pdf_info, pdf_pages, and pdf_merge. An agent can select it over those 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?

Gives a clear usage condition ('for best-effort text extraction from standard-font PDFs') and effectively rules out scanned documents ('Returns nothing for a scan (no OCR)'), which functions as a when-not-to-use signal. It stops short of naming an alternative tool (e.g., for OCR or metadata), so it is not a full routing directive.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write. The description adds that the footer content is drawn from a shared profile, which is genuinely useful context, but it says nothing about the non-idempotent overwrite behavior or what happens to an existing out_path.

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 is short, but the middle clause "from the shared profile mcp-invoice and mcp-docx write" is garbled and hard to parse, and the trailing "Pro." is a dangling fragment that does not earn its place.

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

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

For a four-parameter write tool with annotations covering safety and no output schema, the description is barely adequate. The garbled profile clause leaves ambiguity about where the business details originate, which an agent would need clarified before invoking it 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?

Schema description coverage is 100%, so all four parameters including pages and overwrite are already documented in the schema. The description adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: putting business name and VAT id into the footer of every page. An agent can identify the operation clearly, though it never differentiates itself from the sibling pdf_stamp, which plausibly does overlapping work.

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?

"Use it before sending a document out" gives a timing cue, which is useful implied usage. However, it names no alternative and no when-not condition, and the fragmented clause about the shared profile does not clarify routing against siblings like pdf_stamp.

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