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

With no annotations, the description carries the full burden and does it well: overwrite semantics on output_path, the return value (path plus size in bytes), the 50 MB input cap, quota consumption per call, in-memory processing with no storage, and the no-op behavior for already-optimized 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?

Five short sentences, front-loaded with the action and effect, then the use case, then operational constraints. No sentence is filler and the ordering follows what an agent needs before deciding to call.

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

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

No output schema exists, and the description still explains exactly what comes back (path and byte size). Size limit, quota cost, overwrite risk and storage behavior are all covered, leaving nothing an agent would need to infer before calling.

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 schema already explains file, level and output_path. The description adds real value on top, spelling out that output_path replaces any existing file and defaulting behavior, and tying level indirectly to the quality/size tradeoff.

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 ('Shrink a PDF') plus the mechanism (image downsampling), and notes text stays selectable. This clearly separates it from conversion/extraction siblings like extract_pdf_text or pdf_to_jpg, none of which compress.

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 an explicit trigger case ('when a PDF is too large to email or upload') and notes already-optimized files are returned unchanged, which heads off a wasteful retry. It doesn't name an alternative tool or an exclusion condition, but no sibling covers compression, so the guidance is effectively complete.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the upload to the Papyrio API, in-memory processing with no storage, an overwrite of output_path (a destructive side effect), the return payload (path and byte size), a 50 MB limit, and per-call quota consumption. This is exactly the behavioral context an agent needs before committing.

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?

Five tight sentences, front-loaded with the core action and immediately followed by the scanned-PDF caveat. Each sentence conveys distinct, operationally relevant information with no 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?

For a two-parameter tool with no output schema, the description still explains the return value (path and byte size in bytes) and covers safety, limits, and quota. An agent has everything needed 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?

Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds genuine value beyond the schema by warning that output_path replaces any existing file and that the result is written to that path, which the schema does not state.

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 ('Return the text of a PDF as UTF-8') plus the downstream intent (read or summarize). It explicitly distinguishes itself from the sibling ocr_pdf, so an agent can route correctly without opening either 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 an explicit condition for use ('when the PDF already has a text layer'), an explicit exclusion ('A scanned PDF has none'), and names the alternative to run first ('run ocr_pdf on it first'). Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does: it discloses data handling (uploaded to the API, processed in memory, not stored), destructive overwrite of output_path, the 50 MB input limit, and per-call quota consumption. It also states exactly what the call returns.

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 purpose then usage, then behavior and limits. No sentence is redundant; each conveys a distinct operationally useful fact.

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-parameter conversion tool with no annotations and no output schema, the description covers everything an agent needs: input formats, size cap, storage behavior, overwrite risk, return value, and quota impact.

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 both parameters are already documented. The description still adds real semantics beyond the schema by stating that output_path is overwritten if a file already exists, which the schema does not say.

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 ('wrap a JPG, PNG or WebP image in a PDF page') and names the accepted input formats. It is clearly distinguishable from sibling conversions like office_to_pdf, webpage_to_pdf, and the reverse pdf_to_jpg.

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: 'Use this when an image needs to be submitted or printed as a PDF.' It does not explicitly exclude alternatives (e.g. when to prefer office_to_pdf for a document), but the image-format scoping makes the selection obvious in practice.

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

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

With no annotations, the description carries the full burden and does so: it discloses upload to the Papyrio API, in-memory processing with no storage, an overwrite of any existing file at output_path, the 50 MB input cap, and quota consumption. The destructive overwrite warning is especially valuable since no annotations flag it.

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?

Five tight sentences, front-loaded with the core action and scope, followed by prerequisites, privacy, side effects, and limits. Every sentence carries distinct information with no repetition of 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?

Although there is no output schema, the description states the return value (path and size in bytes), covers side effects, size limits, and quota cost. An agent has everything needed to invoke this correctly on the first try.

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, but the description adds meaning beyond the schema: it reinforces that file order determines output order and that output_path replaces any existing file. It does not otherwise elaborate on path formats, but the added overwrite semantics are real value.

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?

Opens with a specific verb and resource ("Combine 2 to 10 PDFs into one document") plus a scope constraint (order preserved, count bounded). It is clearly distinguishable from siblings like split_pdf or extract_pdf_text without needing 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 concrete use cases (scans, chapters, invoices) and an explicit prerequisite: password-protected files must be unlocked first, which implicitly routes to unlock_pdf. It does not explicitly name alternatives or state when not to use it, but the context is clear.

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

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

No annotations exist, so the description carries the full burden and does so richly: page images preserved and output size similar to input, already-texted pages untouched, 2-10s per page runtime, DPI thresholds for accuracy, upload to the Papyrio API processed in memory and not stored, overwrite of output_path, return value, 50 MB input cap, and one-operation quota cost.

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?

Purpose and the ordering instruction are front-loaded, and every sentence carries operational information (limits, timing, DPI, privacy, return value). It is on the dense side with several clauses per sentence, but no sentence is 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?

There is no output schema, and the description compensates by stating exactly what is returned ('that path and the size in bytes'). Given the simple three-parameter schema and full behavioral disclosure, an agent has everything needed to invoke 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 coverage is 100%, so the baseline is 3; the description adds value beyond the schema by giving the conditional rule for lang ('when the text is not English') and by flagging that output_path replacement overwrites existing files. It stops short of elaborating the '+' language-joining syntax, which the schema already covers.

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?

Specific verb+resource ('Add an invisible text layer to a scanned PDF') with the outcome stated (searchable, selectable, extractable text). It is clearly distinguishable from every sibling, since none of the other tools operate on a scan to produce an OCR layer.

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?

Explicitly says to use this before extract_pdf_text or pdf_to_word on a scan or photographed document, and adds the conditional 'set lang when the text is not English'. Both the when-to-use and the ordering relative to alternatives 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?

With no annotations, the description carries the full burden and does: it discloses latency ('30 seconds or more'), the privacy model (uploaded to the Papyrio API, processed in memory, not stored), destructive behavior (output_path is replaced if it exists), the return value (path and size in bytes), a 50 MB input cap, and per-call quota consumption.

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?

Single dense block, front-loaded with the verb and supported formats, with constraints following. Nearly every clause carries actionable information, though the privacy and quota details could be split more cleanly for scanning.

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-parameter conversion tool with no output schema, everything an agent needs is present: accepted formats, output destination behavior, size limit, failure mode (encrypted files), runtime expectations, and the shape of the return value.

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

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

Schema coverage is already 100%, so the baseline is 3; the description adds meaning beyond it by explaining that output_path is overwritten and that the resolved path is returned, and by noting the extension drives parsing. It does not restate the default suffix logic, but that is fully covered in 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 ('Convert a Word (.doc, .docx, .odt), PowerPoint ... or Excel ... document to PDF') with all supported extensions and the engine used. It is clearly distinguishable from siblings such as pdf_to_word (reverse direction) and image_to_pdf/webpage_to_pdf (different sources).

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?

Explicitly gives the use case ('turn an Office file into a fixed, shareable PDF') and an exclusion ('not for files that are already PDFs'), plus a hard constraint that password-protected Office files are not supported. No alternatives need inferring.

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

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

With no annotations, the description carries the full burden and does: 50 MB input cap, per-call quota cost, in-memory processing with no storage, and destructive overwrite of output_path. These are exactly the operational facts an agent needs before invoking.

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

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

Four tight sentences: what it does first, then when to use it, then storage/safety behavior, then limits and return value. No filler.

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

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

No output schema, but the description states the return shape (path and byte size), plus limits, overwrite semantics, and processing model — everything needed 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?

Schema coverage is 100%, so baseline would be 3. The description adds value beyond the schema by disclosing that output_path is overwritten if it exists and by describing the return payload (path plus size in bytes), which the schema lacks.

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: render every page of a PDF as JPG, returned as a ZIP. The output format detail (ZIP of JPGs) clearly separates it from extract_pdf_text, ocr_pdf, and pdf_to_word.

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 explicit use cases — thumbnail, slide, image pipeline — which implies when to pick this over text-extraction siblings. It does not name an alternative tool or state exclusions, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does: it discloses the upload destination (Papyrio API), that processing is in-memory and non-persistent, that output_path is overwritten destructively, the 50 MB input cap, and that each call consumes one unit of daily quota. These are exactly the operational facts an agent cannot infer elsewhere.

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?

Front-loaded with purpose and the scanned-PDF caveat before operational details, and nearly every sentence adds distinct information. It is dense but not padded; one could argue the privacy sentence and quota sentence are separable, but both are load-bearing for agent behavior.

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 no annotations and no output schema, the description covers safety (overwrite), limits (50 MB, quota), data handling, failure-mode routing (scanned PDFs), and return shape. An agent has everything needed to call it correctly and to know when to call ocr_pdf instead.

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, but the description adds value the schema does not: it explains that the result is written to output_path and that any existing file there is replaced, clarifying the destructive side effect of that parameter. It also states the call returns the path and byte size, which compensates for the absence of an output 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 ('Convert a PDF into an editable Word document') and immediately distinguishes itself from pdf_to_jpg, extract_pdf_text, and office_to_pdf by naming the output format. The routing sentence about scanned PDFs further separates its domain from ocr_pdf.

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 explicit when-it-works conditions (Word, Google Docs, InDesign exports) and an explicit when-not plus alternative ('A scanned PDF is a picture of a page, so run ocr_pdf on it first'). This is exactly the agent routing signal that matters when ten sibling conversion tools exist.

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

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

With no annotations, the description carries the full burden and does so well: it says the input is uploaded to the Papyrio API, processed in memory and not stored, that output_path is overwritten (a destructive side effect the schema does not flag), the return value shape, the 50 MB input limit, and per-call quota consumption.

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 sentences, each carrying distinct new information (purpose, trigger, data handling, side effects/limits), with the core action stated first and 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?

No output schema exists, so the description supplies the return value itself, and it covers the destructive overwrite, privacy handling, size cap, and quota. For a 3-parameter encryption tool this is complete enough to call correctly without guessing.

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 a baseline of 3 is warranted, but the description adds real meaning beyond the schema by disclosing that output_path replaces any existing file and that the call returns the path and byte size. It doesn't discuss password strength requirements, a minor omission.

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 ('Encrypt a PDF with AES-256') along with the concrete effect: the file cannot be opened without a password. This is instantly distinguishable from sibling tools such as unlock_pdf or compress_pdf.

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 trigger: 'Use this before sending a document that contains anything private.' That tells an agent when to reach for it, though it never names unlock_pdf or other alternatives as the opposite operation, so the alternative framing is only implicit.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses that input is uploaded to the Papyrio API, processed in memory and not stored, that output_path overwrites any existing file, the 50 MB size limit, and that each call consumes one daily-quota operation. It also states the return payload (path and size in bytes).

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 output format and use case are front-loaded, followed by privacy, side effects, limits, and return value in tight sentences. No sentence is filler; the density is high but every clause carries information an agent needs.

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-parameter tool with no output schema, the description covers purpose, when to use, side effects, privacy, limits, quota cost, and return shape. Nothing an agent needs to invoke 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?

Schema coverage is 100%, so the schema already defines both parameters. The description goes beyond it by explaining the overwrite behavior of output_path and the shape of the return value, adding operational meaning rather than repeating 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?

The description opens with a specific verb and resource ('Separate every page of a PDF into its own file, returned as a ZIP archive'), which clearly distinguishes it from siblings like merge_pdfs (the inverse operation) and extract_pdf_text.

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 this to pull single pages out of a long document' gives a clear use case, and the ZIP output clarifies the deliverable. However, it never explicitly names an alternative (e.g., extract_pdf_text when you only need text) or states when not to use it, so the routing is implied rather than spelled out.

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

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

With no annotations, the description carries the full burden and does so: it discloses the upload to the Papyrio API, in-memory processing with no retention, the destructive overwrite of output_path, a 50 MB input cap, and per-call quota consumption. This is exactly the behavioral context an agent needs before invoking a mutation 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?

Five sentences, front-loaded with the action and its constraint, then storage/limit details, then output behavior. Every sentence conveys a distinct operational fact with no restatement of the tool name or title.

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

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

For a 3-parameter tool with no annotations and no output schema, the description covers the security model, data handling, size limit, quota cost, overwrite behavior, and return values. Nothing an agent needs to decide or call 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?

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining that output_path silently replaces an existing file and by describing the result path and byte size returned. That adds real semantics not present in the schema, particularly the overwrite risk.

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 ('Remove the password from a PDF') and immediately bounds the scope with 'you already know the password' plus an explicit exclusion ('does not break or guess encryption'). That cleanly separates it from the sibling protect_pdf and from any cracking-style 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?

The precondition for use ('a PDF you already know the password for') and the negative case ('does not break or guess encryption') are stated explicitly. It doesn't name a sibling as an alternative for the unsupported case, which keeps it just short of a 5.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses headless-browser rendering, upload to the Papyrio API, in-memory processing with no storage, overwriting output_path, returned path and size, a 50 MB input limit, and quota consumption. These details cover side effects, data handling, output, and constraints beyond what the schema or annotations provide.

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 front-loaded with purpose, then usage, parameter rationale, behavior, and limits. Every sentence adds relevant operational information without repetition or wasted framing.

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-parameter tool with no annotations and no output schema, the description is complete: it explains what the tool does, when to use it, how inputs are processed, where output is written, what is returned, and relevant limits. No critical agent-facing context appears to be missing.

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

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

Schema coverage is already 100%, so the baseline is 3. The description adds useful meaning by explaining why output_path is required for this URL-based tool and by noting that output_path will be overwritten if a file already exists.

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: fetch a public URL and render the page to PDF in a headless browser. It distinguishes the tool from PDF-oriented siblings by clarifying that it takes a URL rather than a file, so an agent can identify it without opening another 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?

It gives clear usage context with 'Use this to archive or print a web page' and reinforces the URL-versus-file distinction. It does not explicitly name alternative sibling tools such as image_to_pdf or office_to_pdf, so it stops short of fully explicit routing guidance.

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