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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive, but the description adds two facts annotations cannot: the file leaves the machine and is uploaded to conv2pdf, and the call consumes one conversion credit. It does not mention overwrite behavior or password handling beyond the schema, which keeps it short of a 5.

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

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

Two sentences, zero padding, and the core action is front-loaded before the operational caveat about upload and quota. 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?

With no output schema, the description does not explain the return value or where the result lands, though the schema covers output_path/default naming and non-overwrite. The quota and upload disclosure fills the biggest annotation gap; only result-shape detail is missing.

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

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

Schema description coverage is 100% and every parameter (format, password, position, input_path, output_path) is documented in the schema, so the baseline is 3. The description adds no format, position, or password semantics beyond what is already there.

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 ('adds/prints the page number ... of a PDF') with exact scope ('at the bottom of every page'), which separates it cleanly from siblings like add_watermark and rotate_pdf that also modify a PDF. An agent can identify the operation 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 description never says when to choose this over alternatives such as add_watermark (also stamps content on pages) or when it is inappropriate (e.g., already-numbered documents). Usage is only implied by the operation itself.

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 cover the safety profile (destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description is judged on what it adds. It adds two genuinely non-obvious traits: the file is uploaded to an external service (conv2pdf) and the call consumes one conversion/quota unit. It does not discuss overwrite behavior or failure modes, which the schema partially covers.

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, front-loaded with the core action and followed by the two side effects an agent most needs (external upload, quota cost). No filler and nothing redundant with the schema.

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 mutation tool with no output schema, the description supplies the operation's scope plus the two non-schema facts (upload destination and quota consumption). Remaining details like output naming and password handling are adequately covered by the schema, leaving only minor gaps around failure behavior.

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

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

Schema description coverage is 100%, so all four parameters (text, password, input_path, output_path) are already documented with constraints such as the 50-character limit and the no-overwrite rule. The description adds nothing parameter-specific, 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 (stamps) and resource (text watermark across every page of a PDF), with the visual effect ('diagonally across every page') distinguishing it from neighbours like add_page_numbers or rotate_pdf. It does not name a sibling explicitly, so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no exclusion such as when to prefer add_page_numbers or protect_pdf instead. The only routing-adjacent information is that the call consumes a conversion, which is cost, not 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 openWorldHint=true and readOnlyHint=false. The description adds genuinely new behavioral facts beyond them: the file leaves the machine to be uploaded to conv2pdf, the call consumes one conversion from a quota, and password-protected inputs yield an unprotected result. It stops short of stating what is returned or how long the upload takes.

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 with no filler; the core purpose leads and the operational caveat (external upload, one conversion) follows. Nothing is redundant with the title or schema.

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 conversion tool with no output schema, the definition covers what the operation does and its side effects (upload, quota, password stripped), which is enough to call it safely. It could still say what the caller receives back (e.g., confirmation plus the new file path) to close the last 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 100% – quality levels, DPI mapping, default, password handling and output_path collision behavior are all documented in the schema. The description adds no parameter detail beyond that, 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 (reduces the size) and resource (a PDF) plus the mechanism (lowering image resolution), which cleanly separates it from every sibling such as merge_pdfs, rotate_pdf, or extract_pdf_pages. An agent can pick it without opening a 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 only implied by the purpose statement; there is no explicit when-to-use/when-not rule and no routing to an alternative (e.g., a lossless-compression sibling, or a different tool when only page removal is wanted). The one contextual hint given is the quota cost of a conversion.

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 openWorldHint=true and destructiveHint=false, and the description usefully confirms the external-service behavior ('uploaded to conv2pdf') plus the cost model ('counts as one conversion') — quota/billing context the annotations do not convey. It does not restate the non-overwrite guarantee, but that detail lives in the output_path 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?

Two short sentences, front-loaded with the conversion and followed by the context an agent needs (upload destination and quota impact). No filler or redundancy.

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

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

There is no output schema, but the description plus the rich output_path schema make the return contract clear (result written to a path). The quota disclosure covers the main hidden cost; only the upload/network-failure behavior is left unstated.

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 parameters, both well documented (path resolution rules, default output naming, no-overwrite guarantee), so the baseline of 3 applies. The description adds no syntax or format detail beyond the schema.

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

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

States a specific verb (converts) and precise resource (iPhone HEIC or HEIF photo to a JPG image), which is enough to separate it from the PDF-centric siblings like convert_to_pdf and convert_pdf_to_images. It stops short of naming any sibling explicitly, but the transformation pair 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?

Usage is only implied: 'an iPhone HEIC or HEIF photo' tells the agent the input class, but there is no when-to-use, when-not-to-use, or pointer to an alternative converter. Adequate for a narrow single-purpose tool, but the agent gets no routing 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 it is not read-only, not idempotent and open-world, and the description usefully adds quota-relevant behavior ('counts as one conversion'), the upload destination, the 100-page limit, and the ZIP output shape. It stops short of describing failure modes or error behavior for invalid/encrypted PDFs.

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, front-loaded sentences with no filler: rendering behavior, output artifact, page limit, then quota/upload. Every sentence carries information an agent would otherwise lack.

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 still explains the return artifact (ZIP with one image per page), the resolution, the page cap, and the quota cost, while the schema covers all four parameters. An agent has what it needs to call this 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 100%, so format, password, input_path and output_path are fully documented in the schema; the description adds no parameter-level detail beyond the output-format implication. Baseline 3 is appropriate when 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 names a specific verb (renders) and resource (each page of a PDF as an image) plus concrete parameters of the output: 150 DPI, one image per page, delivered as a single ZIP archive. This clearly separates it from siblings like convert_pdf_to_word and extract_pdf_pages.

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 by the tool's function; there is no statement of when to choose this over extract_pdf_pages or convert_to_pdf, and no exclusions or prerequisites beyond noting the 100-page cap. Adequate but with a clear routing gap.

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?

Discloses behavior well beyond the annotations: the file is uploaded to the external conv2pdf service (matching openWorldHint), the call consumes one conversion credit, and a failed/refused case is defined. This is material operational context an agent cannot infer from {readOnlyHint:false, destructiveHint:false}.

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 sentences, each earning its place: capability, refusal condition, then side effects (upload + quota). Front-loaded and free of 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 no output schema, the description covers the important behavioral gaps itself: the refusal case, the external upload, the quota cost, and the password-free result. An agent has everything needed to call it and interpret failure.

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 three parameters (input_path, output_path, password) are already documented in the schema, including defaults and the no-overwrite rule. The description adds no parameter-level 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 and resource ('Converts a PDF ... to an editable Word document (DOCX)') and immediately bounds the input type, distinguishing it from siblings like convert_to_pdf and convert_pdf_to_images. An agent can select this tool 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?

Gives a clear applicability condition: the PDF must contain real text, and a scanned image-only PDF is refused. It does not explicitly name an alternative tool for scanned PDFs or OCR, so it falls short of a true when/when-not 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 only supply generic flags (writes, not idempotent, open world). The description adds real context beyond them: the file is uploaded to an external service (conv2pdf) and the call consumes one conversion from a quota. It stops short of describing outcomes such as whether the source file is modified or what happens to an existing output 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?

Two sentences, front-loaded with the core purpose; the long format enumeration is dense but directly actionable for judging eligibility. No redundant restatement of the title, though the list could be tightened.

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

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

There is no output schema, yet the description never says what the tool returns (e.g., the path of the generated PDF, which matters because output_path defaults to an auto-generated name). The upload and quota notes cover behavior, but the return contract is left unspecified.

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%, including the non-overwrite default for output_path, so the baseline is 3. The 'converter is chosen from the extension' statement adds a small amount of meaning about input_path, but no new syntax or constraints beyond the schema.

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

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

States a specific verb and resource ('Converts ... to PDF') and enumerates the exact input formats accepted, so the agent can distinguish it from the reverse-direction siblings like convert_pdf_to_word and convert_pdf_to_images without opening a 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?

Explains the mechanism ('converter is chosen from the extension of the file'), which implicitly defines the applicable inputs, but never states when to prefer this over an alternative or when it will fail. No exclusions or routing guidance to siblings are given.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds real context beyond them: the file is uploaded to an external service (conv2pdf) and the call consumes one conversion from the quota, which an agent must know given the sibling get_quota.

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, zero filler, with the core behavior (subset extraction, order preserved) front-loaded before the deployment/quota note. 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?

No output schema exists, but the description covers the operation, output nature (a new PDF), ordering, and the quota/upload side effect; the schema covers file paths and password. Only the exact return value/shape is unstated, which is minor.

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 are already documented in the schema (pages syntax, password handling, input/output path defaults and no-overwrite rule). The description adds no parameter-level detail beyond that, 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?

The description gives a specific verb and resource ('Keeps some pages of a PDF in a new PDF') and clarifies that page order is preserved, which distinguishes it from siblings like merge_pdfs or rotate_pdf. It does not name an alternative tool, so it stops short of a 5.

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

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

Usage is implied by the clear purpose and the sibling set (extract a subset of pages rather than merge/rotate/convert), but there is no explicit when-to-use or when-not, and nothing pointing an agent to merge_pdfs versus this tool. Adequate but with a clear gap.

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 genuinely new behavioral context not in the annotations: that reads are free of charge, and what the response contains (plan, used, remaining). It stops short of stating auth requirements or rate limits, which keeps 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?

Two short sentences with the resource and return contents front-loaded; the free-read note follows as a useful but subordinate detail. Nothing is padded or repeated from the title.

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

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

With no output schema, the description does the right thing by naming what comes back (plan, conversions used, remaining). For a zero-parameter, read-only tool this is essentially sufficient, though it leaves open whether the quota is scoped per key or per account and whether results are cached.

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

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

The tool takes zero parameters, so per the baseline this dimension is well-served by the schema alone and the description has nothing extra to explain. No parameter documentation is missing.

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 ('Returns the plan of the conv2pdf API key and how many conversions it has used and may still use'), which is unambiguous and clearly distinct from all conversion-oriented siblings. An agent can tell it apart from merge_pdfs or compress_pdf 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 only implied: an agent infers this is a pre-flight check before spending conversions, but the description never says when to call it or in what order relative to conversion tools. Since no sibling overlaps with quota retrieval, the missing 'when' is a modest gap rather than a confusion risk.

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 cover the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false), so the bar is lower. The description still adds meaningful disclosure: files are uploaded to an external service (conv2pdf), the call is metered as one conversion, and the result lands next to the first file. Nothing contradicts 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?

Four short sentences, front-loaded with what the tool does, then cost/limit context. Every sentence carries information, though the 'written next to the first file' clause lightly duplicates the output_path default in the schema.

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 two-param tool with no output schema, the description covers destructive behavior (no overwrite), external upload, quota cost, and plan-dependent item limits — enough for an agent to call it correctly. It omits failure modes and any auth requirements for the conv2pdf upload, which 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% and both parameters (input_paths with min/maxItems, output_path with defaults and no-overwrite behavior) are already fully documented. The description only restates ordering and default placement, adding no syntax or format detail beyond the schema. 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 ('Combines several PDFs into one') plus the ordering semantics, which no sibling does — every sibling tool (convert_*, rotate_pdf, compress_pdf, etc.) operates on a single file. An agent can distinguish this from the rest of the list 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 operational context that shapes use: a 2-file minimum on the Dev plan, up to 20 on paid plans, and that the call consumes one conversion from quota. It does not explicitly name when to prefer an alternative, but the resource is unique among siblings so no real disambiguation is required.

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?

Beyond annotations, the description discloses the encryption algorithm (AES-256), that the file leaves the local machine for conv2pdf, and that the call consumes one conversion from quota - none of which the annotations convey. This is consistent with openWorldHint=true, readOnlyHint=false and destructiveHint=false; no contradictions.

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

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

Two tightly written sentences with no filler; the core behavior is front-loaded and the secondary operational fact (upload + quota) is appended where it belongs.

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-parameter, non-idempotent mutation with full schema coverage and no output schema, the description covers mechanism, side effects, and cost. Minor residual gaps are error/failure behavior (e.g., what happens if the password is rejected or the upload fails), which an agent would need before relying on it.

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

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

Schema description coverage is 100%, so password, input_path, output_path, prevent_copy and prevent_print are already fully documented in the schema. The description restates the optional print/copy restrictions but adds no new syntax, format, or default detail.

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 ('Encrypts a PDF') plus a concrete mechanism (AES-256) and the two protection modes, so the agent knows exactly what the tool produces. It does not explicitly contrast itself with the inverse sibling unlock_pdf, 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?

Usage is implied by the purpose (add open-password and printing/copying restrictions) and the note that the call is uploaded to conv2pdf and consumes one conversion gives decision-relevant cost context. There is no explicit when-to-use/when-not statement and no reference to alternatives such as unlock_pdf.

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 write/openWorld/idempotency profile, so the bar is lower. The description adds genuinely useful context beyond them: the file is uploaded to an external service (conv2pdf) and the call is billed as one conversion, which informs quota-sensitive 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?

Two tight sentences with the primary action front-loaded and no filler. Both sentences carry distinct information (what it does, and the upload/billing side effect).

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

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

For a simple single-operation tool with no output schema and full schema coverage, the description covers the action, direction, and side effects (external upload, quota cost). It omits only return/result details, which are largely implied by output_path 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 description coverage is 100%, so all four parameters (input_path, output_path, rotation, password) are already documented, including the non-overwrite behavior. The description only restates the clockwise direction already present in the rotation enum description, adding no new parameter semantics.

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

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

States a specific verb and resource ('Rotates every page of a PDF') plus direction (clockwise) and scope (every page). This clearly distinguishes it from the conversion, merge, and extraction siblings, though it does not name any 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?

Usage is implied by the self-explanatory name and the note that the call 'counts as one conversion' (a quota consideration), but there is no explicit statement of when to use this versus alternatives such as convert_pdf_to_images or extract_pdf_pages for orientation fixes.

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 mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description's added value is the external-service disclosure ('uploaded to conv2pdf') and the cost model ('counts as one conversion'). These are real behavioral facts the agent needs and are not in the annotations; it does not, however, cover output file handling, which the schema carries instead.

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, then the boundary, then the operational cost. No padding and nothing important is buried.

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

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

For a 3-parameter, single-purpose tool with full schema coverage and annotations covering the safety profile, the description supplies the two things structured fields cannot: the external upload and per-call quota cost. Return-value behavior is left implicit, but there is no output schema and output_path is 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 description coverage is 100%, including non-obvious guidance that password can be omitted for print/copy-restricted files, so the baseline is 3. The description only reinforces the 'known password' condition and adds no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Removes the password and the restrictions of a PDF') and immediately bounds the scope ('whose password is known') and what it is not ('does not find a forgotten password'). An agent can separate this from protect_pdf and the rest of the conversion siblings without opening a 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 use condition (password is known) and an explicit exclusion (forgotten passwords are not recovered). It does not name an alternative tool for the excluded case, but the condition that selects this tool is unambiguous.

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