tinytoolbox

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

With no annotations, the description carries the full burden; it does usefully disclose what the tool surfaces (page count, byte size, info fields), implicitly framing it as a read-only inspection. It says nothing about behavior on password-protected or malformed PDFs, whether the full base64 file must be loaded, or how failures are reported.

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

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

A single short sentence that front-loads the resource and lists the return fields without padding. It is efficient, though slightly fragmentary and could carry one clause of usage guidance at no real cost.

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 one-parameter metadata reader with complete schema coverage and no output schema, listing the returned fields is exactly the right compensation. Only the absence of any error/encryption behavior note keeps it from a 5.

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 there is only one parameter, whose schema description ('PDF file content as base64') already fully specifies it. The description adds no further param semantics, 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 names the resource (PDF metadata) and enumerates the specific fields returned: page count, byte size, and document info fields. That clearly separates it from text-extraction (pdf_text), mutation (pdf_merge/pdf_split/pdf_rotate), and scanning (pdf_safe_scan) siblings. It lacks an explicit verb ("Extract"/"Read"), which keeps it 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 statement about when to use this tool versus pdf_text or pdf_safe_scan, nor any precondition such as whether the PDF must be unencrypted. The agent must infer usage purely from the name and field list.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two valuable behaviors: page order follows input order, and the result is returned as base64 rather than written to storage. It says nothing about size limits, encrypted/corrupt input handling, or failure behavior, which is a meaningful gap for a file-processing tool with zero annotation coverage.

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, zero waste, with the core operation stated first and the return contract second. Nothing to trim.

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 one-parameter tool, the description covers the operation, ordering, minimum input count, and the return shape (base64), so no output schema is needed. It is slightly incomplete on error/edge-case behavior, but an agent has enough 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% and the single parameter already says "PDF file contents as base64, in merge order (2+ files)". The description's "in order" merely restates that, adding no syntax, sizing, or format detail beyond the schema. 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?

Specific verb+resource ("Merge multiple PDF files into one PDF") with two useful qualifiers: order is preserved and the output is returned as base64. It is clearly distinct from siblings like pdf_split or pdf_rotate, but it never names or contrasts 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?

Usage is implied by the operation itself (combine 2+ PDFs into one), and "in order" hints at the merge-order contract. But there is no guidance on when to prefer this over pdf_split or pdf_text, no preconditions (e.g. all inputs must be valid, unencrypted PDFs), and no mention of limits.

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

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

With no annotations, the description carries the full behavioral burden; it does deliver the key fact that output is base64 of the rotated PDF rather than an in-place mutation. It omits whether the original is altered, any file-size or page-count limits, and error behavior for invalid page specs, which matters for a stateless transform.

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 that front-load the operation and then the return value; every clause earns its place with no filler or restatement of the tool name.

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 three-parameter transform with full schema coverage and no output schema, stating the base64 return is enough to call it correctly. Only minor gaps remain around limits and failure modes, so it falls just short of complete.

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

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

Schema coverage is 100% and the schema already documents all three parameters, including defaults and the '1-3,5' page format. The description only adds the loose phrase 'some or all pages', which duplicates what 'pages' already conveys, so 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 (rotate), resource (PDF pages), a bounded parameter domain (90/180/270), a scope option (some or all pages), and the return format in base64. No sibling (pdf_merge, pdf_split, pdf_text, pdf_info) overlaps with rotation, so the agent can select it unambiguously.

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 and scope phrase, and there is no competing rotation sibling to route away from. However, there is no explicit when-to-use context, no prerequisites, and no pointer telling the agent to first inspect pages with pdf_info before choosing a page range.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return shape (verdict, risk_score, findings), the verdict enum values, and the crucial limitation that detection is heuristic rather than signature-based AV. It omits whether the file is stored or transmitted anywhere, 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 dense sentences: the first front-loads what is scanned, the second delivers the output shape and the key caveat. No filler and nothing redundant with structured fields.

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 one-parameter read tool with no output schema, the description supplies the return fields, the verdict taxonomy, the detection scope, and the heuristic disclaimer. An agent has everything needed to decide to call it and to interpret the result.

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?

Single required parameter with 100% schema description coverage ('PDF file content as base64'), so the schema already does the work and the baseline is 4. The description adds nothing further about the parameter, which is acceptable at this coverage level.

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 (scan) and resource (PDF) plus an enumerated list of what is detected: JavaScript, embedded files, Launch/Open actions, XFA forms, encryption. This clearly distinguishes it from siblings like pdf_info or pdf_text, which inspect content rather than assess hostility.

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 closing clause 'Static heuristics, NOT an antivirus' sets an explicit scope boundary and warns against over-trusting results. It does not name an alternative tool or state when to prefer another sibling, so it falls 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?

No annotations are provided, so the description carries the burden. It does disclose the return format (base64 of the extracted PDF), which is useful, but it does not describe error behavior (invalid ranges, out-of-bounds pages) or whether the original is preserved.

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 zero waste; the action is front-loaded and the return value follows immediately.

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 two-parameter tool with fully documented schema and a stated base64 return, the description is largely complete. The main missing piece is error/edge-case behavior, but nothing critical blocks correct invocation.

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

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

Schema description coverage is 100%, so both parameters (file, pages) are fully documented in the schema including the '1-3,5' format and default. The description adds no parameter detail beyond the schema, which is appropriate given full coverage — baseline 3.

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

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

States a specific verb ('Extract') and resource ('selected pages from a PDF') with clear output ('base64 of the extracted PDF'). It does not explicitly contrast with siblings like pdf_merge or pdf_info, so 4 rather than 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 'Extract selected pages' and the pages parameter, but there is no explicit when-to-use versus alternatives (e.g., pdf_merge for combining, pdf_info for metadata) and no exclusions or prerequisites.

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 must carry behavioral weight; it does disclose output shape (per-page results, '## Page N' headings in Markdown mode), which is useful. It says nothing about scanned/image-only PDFs, OCR, encrypted files, failure modes, or input-size limits for base64 payloads.

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, zero filler, with the core action front-loaded and the option modifier second. Nothing is repeated from the schema verbatim beyond what is needed to explain the 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 2-parameter extraction tool with no output schema or annotations, the description covers what it does and the output format switch, but omits the practical caveats an agent needs — scanned PDFs without a text layer, password-protected files, and expected error behavior.

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

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

Schema coverage is 100%, so baseline is 3, but the description genuinely adds meaning beyond the schema: it spells out that Markdown mode yields a 'clean' version with '## Page N' headings, telling the agent what the flag actually produces. It still doesn't clarify the base64 input format beyond what the schema already says.

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 ("Extract text from a PDF") plus the output granularity ("per page"), so an agent knows exactly what it returns. Sibling tools (pdf_info, pdf_merge, pdf_split) are clearly different operations, though the description never names them for explicit 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?

Gives one conditional usage hint — set as_markdown=true when a Markdown form is wanted — which implies the default path. It offers no guidance on when to reach for this versus pdf_info (metadata) or pdf_safe_scan, leaving sibling selection to inference from names.

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 burden and does disclose the key behavior an agent needs: the output is a base64-encoded PNG with media type image/png. It does not mention failure modes (e.g. oversized input) or whether the code is generated locally versus remotely, but the critical return contract is covered.

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, no waste, and the action is front-loaded before the return-format detail. Everything present 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?

For a simple two-parameter generator with full schema coverage and no output schema, the description supplies exactly the missing piece – the return encoding and media type. Nothing further is required 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 description coverage is 100% – both 'text' and 'size' (with its 64-1000 range and default 300) are documented in the schema. The description adds only the 'text or URL' nuance, which the schema already states, so 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 ('Generate a QR code PNG') plus the input domain ('for a text or URL'), which is unambiguous. It cannot be confused with any sibling (pdf_info, pdf_merge, pdf_text, etc.), so no explicit differentiation is needed.

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 name and is effectively self-evident since no sibling tool competes with it. However, there is no guidance on limits such as maximum text length, error-correction level, or when to prefer a URL versus free text.

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