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

With no annotations, the description carries the full behavioral burden. 'Validate... and report' implies a non-destructive read, but it never states that the PDF is not modified, how encrypted files are handled, whether it fails or returns a problem list on invalid input, or what the report contains.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the terseness is achieved partly by omitting information the tool actually needs to convey.

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, no annotations, and undocumented parameters mean the description must do more than one sentence. It omits what 'problems' are reported, how the result is returned, password handling, and the relationship to repair_pdf.

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?

Two parameters with 0% schema description coverage, and the description adds no meaning for either. In particular, the password parameter's role for encrypted PDFs is left completely unexplained, so the description does not compensate for the schema gap.

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

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

States a specific verb (validate) and the target (structural integrity) with a reporting outcome, which is more informative than the bare name check_pdf. However, it never says the resource is a PDF file and never distinguishes itself from the adjacent sibling repair_pdf, so an agent must infer the boundary.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative repair_pdf. The check-then-repair workflow is exactly the decision an agent faces here, and the description leaves it entirely unaddressed.

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 a genuine behavioral trait beyond the schema: Office/HTML inputs require LibreOffice, which warns the agent about a possible failure mode. It says nothing, however, about whether existing files are overwritten, what the default output_path is, or what the return value/errors look like.

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, purpose front-loaded, dependency stated as a follow-up constraint. Every sentence earns its place and nothing is padded.

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 annotations, no output schema, and 0% schema coverage, the description should carry more. It covers the conversion capability and one dependency, but omits overwrite semantics, output_path defaulting, and return/failure behavior, leaving an agent to guess on two of three parameters.

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

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

Schema description coverage is 0% across 3 parameters, so the description must compensate. It partially covers input_path by naming the accepted input formats, but leaves output_path and overwrite entirely undefined, including the meaning of the null defaults.

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 (Create) and resource (PDF) and enumerates the accepted input kinds: image, text/markdown, Office/HTML document. That is clear enough to know what the tool produces. It does not, however, differentiate itself from the sibling images_to_pdf, which overlaps on the image case.

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

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

There is no explicit guidance on when to use this tool versus alternatives, and the obvious overlap with images_to_pdf is never addressed, so an agent cannot tell which to pick for an image input. The only conditional content is a runtime dependency (LibreOffice), which is a prerequisite rather than usage routing.

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 usefully discloses that a correct password is required and that this is not a brute-force cracker, which materially shapes expectations of failure. However, it says nothing about whether the file is rewritten in place, how 'overwrite' behaves, or what happens on a wrong password.

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

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

Two short sentences, no filler, with the operation stated before the disqualifying caveat. Every clause earns its place.

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

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

No annotations, no output schema, and 4 undocumented parameters mean the description is the only source of behavior, yet it omits output destination and overwrite semantics — the details most likely to cause a wrong or destructive call. Inadequate for a 4-parameter mutating tool.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate and largely does not. It conveys the semantics of 'password' (it must be the correct one) but leaves input_path, output_path, and especially the write-affecting 'overwrite' flag entirely unexplained.

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

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

States a specific verb and resource ('Remove the password from a PDF') plus the precondition ('given its correct password'), so the agent knows exactly what operation this performs. The inverse relationship to the sibling encrypt_pdf is evident, though it is never named explicitly, which keeps this from 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?

'Given its correct password' defines the condition for use, and 'Not a cracker' explicitly defines when NOT to use it (unknown/forgotten passwords). It offers no alternative route for the password-unknown case, so it falls just short of full when/when-not/alternatives coverage.

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 but only says 'delete'. It does not disclose that pages are permanently removed, whether the operation is in-place or requires an output_path, or how password-protected PDFs are handled — significant gaps for a destructive 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?

A single short sentence is front-loaded and waste-free, but it is under-specified rather than genuinely concise — the brevity comes at the cost of missing information.

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

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

For a 5-parameter destructive tool with no annotations and no output schema, the description is far too thin. It should cover the output_path/overwrite interplay and the password parameter, none of which are explained anywhere.

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

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

Schema description coverage is 0% across 5 parameters. The description adds a useful page-range syntax example ('2,5-7') that the schema lacks, but leaves password, overwrite, input_path, and output_path entirely undocumented in both places.

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 ('Delete pages'), which is unambiguous against siblings like extract_pages or rearrange_pages. However, it does not explicitly differentiate itself from those adjacent tools, 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?

No when-to-use guidance, no prerequisites, and no mention of when to prefer extract_pages or rearrange_pages. The agent must infer the use case purely from the verb.

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 well on security semantics -- clarifying that owner_password defaults to user_password and that allow_* are only viewer-enforced restrictions, which is important caveating. But it never says whether the file is modified in place or written to output_path, what overwrite controls, or what happens on a wrong current_password, leaving real gaps for 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?

Front-loaded one-line statement of the action, followed by tight clauses that each map to a parameter group. Every phrase carries information; there is no filler or 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?

For a 10-parameter file-mutating tool with no annotations and no output schema, the description covers password semantics well but omits where the result is written and how overwrite/output_path interact. An agent still lacks enough to predict side effects on the input file.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains user_password vs owner_password vs current_password, enumerates all four algorithm values with the default, and characterizes the allow_print/copy/modify flags. Only input_path, output_path, and overwrite go unexplained, which keeps it short of a 5.

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 -- 'Add a password to a PDF' -- which unambiguously identifies the operation and implicitly separates it from the sibling decrypt_pdf. No ambiguity about which tool this is or what it produces.

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

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

The tool name and opening sentence make the general usage obvious, and 'Use current_password if the input is already encrypted' is a useful conditional. However, there is no explicit 'use decrypt_pdf to remove a password' routing, and no statement of when this tool should not be used. Usage 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 behavioral burden. It discloses that a new PDF is created, but says nothing about password handling, overwrite behavior, output path defaults, or whether the input file is modified.

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

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

The description is a single front-loaded sentence with a useful inline example and no wasted words. Its brevity is appropriate structurally, even though other dimensions reveal missing detail.

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 five-parameter, no-annotation, no-output-schema tool that creates a new file, the description is too thin. It omits key operational details such as output location behavior, overwrite handling, and password requirements.

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

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

Schema description coverage is 0%, so the description must compensate, but it only documents the pages format with an example. It does not explain input_path, output_path, password, or overwrite 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?

The description states a specific verb and resource: saving only selected pages as a new PDF. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as split_pdf or delete_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?

It implies extraction via "Save only the given pages," but gives no explicit guidance on when to use this instead of delete_pages, rearrange_pages, or split_pdf. There are no exclusions or alternative-selection criteria.

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 more burden but does disclose the return shape: text plus a truncation flag. It does not explain password handling, truncation conditions, or limits beyond that, leaving meaningful behavioral gaps.

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

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

The description is two short sentences, front-loaded with the action and followed by useful return information. There is no wasted text.

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

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

For a tool with four parameters, no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It omits password behavior, max_chars/truncation details, and any error or permission context.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies only the 'pages' parameter with an example ('1-3,7') and does not explain password, max_chars, or input_path semantics beyond what the bare schema names imply.

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: 'Extract text' from pages. It also clarifies scope with 'all pages or a page spec,' but it does not explicitly distinguish the tool from siblings such as extract_pages, which could also involve page selection.

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

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

The description implies when to use the tool by saying it extracts text from all pages or a page spec. However, it gives no explicit guidance on when to choose this over extract_pages or other sibling tools, and no exclusions are stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses a hard external dependency (qpdf CLI) and implies a lossy, irreversible transformation (interactive fields become static content), but says nothing about in-place modification, password handling, or failure 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?

A single tight sentence with the operation front-loaded and no padding. It is efficient, though arguably too terse given the undocumented parameters.

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

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

For a four-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is substantially incomplete. It never addresses output location defaults, overwrite semantics, or password-protected inputs, all of which determine correct invocation.

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

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

Schema description coverage is 0% across four parameters, and the description mentions none of them. Nothing explains input_path vs output_path, what overwrite controls, or that password unlocks encrypted input, so the description provides zero compensation for the documentation gap.

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

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

States a specific verb (flatten) and the exact resources affected (form fields and annotations into page content). It is unambiguous and easily distinguished from siblings like encrypt_pdf or optimize_pdf, though it does not explicitly name sibling alternatives.

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

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

There is no guidance on when to use this versus alternatives such as optimize_pdf or convert_to_pdf, nor any stated preconditions beyond the CLI dependency. The agent must infer usage entirely from the verb.

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. 'Read' implies non-destructive access, but there is no mention of password-protected files, failure modes for malformed PDFs, or what happens with missing metadata keys.

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

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

A single tight sentence, front-loaded with the verb and resource, with the field list as useful detail. No filler, though it is arguably too sparse for a 2-parameter tool.

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

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

For a tool with 0% schema coverage, no annotations, and no output schema, the description should at minimum explain input_path and note password support for encrypted documents. The return-field list is helpful context but the input contract is undocumented.

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

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

Schema description coverage is 0%, so the description must compensate and does not: neither the required input_path nor the optional password parameter is explained. The listed items are return values, not parameters.

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

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

States a specific verb+resource ('Read document metadata') and enumerates the exact fields returned, which helps an agent know what it gets. However, it does not differentiate from the sibling pdf_info, which plausibly overlaps in purpose.

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

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

No when-to-use guidance and no mention of alternatives such as pdf_info or set_metadata. The agent must infer from the tool name alone whether this or pdf_info is appropriate.

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 and only discloses page order and one-image-per-page layout. It does not explain overwrite behavior, supported image formats, or what happens when the output path already exists.

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

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

The description is a single front-loaded sentence with no wasted words. The key operation and ordering behavior are stated 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 file-creating tool with no annotations, no output schema, and 0% parameter description coverage, the definition is too sparse. It omits overwrite semantics, supported formats, error behavior, and return expectations.

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

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

Schema description coverage is 0%, so the description must compensate, but it never names or explains input_paths, output_path, or overwrite. It only weakly implies that input image order matters and that the output is a single PDF.

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: combine images into a single PDF. It also adds ordering and page layout, which helps distinguish it from generic conversion or PDF merging, though it does not explicitly name the relevant siblings.

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

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

The description implies the tool is used for image-to-PDF creation, but it gives no explicit when-to-use guidance, prerequisites, or comparison to alternatives such as convert_to_pdf or merge_pdfs.

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. It usefully discloses the ordering guarantee and that passwords apply to encrypted inputs, but it omits the critical mutation semantics: what happens when output_path already exists (the overwrite parameter is never mentioned), and whether inputs are modified.

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

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

Two short sentences, front-loaded with the core action and output target, followed by the less common password case. Nothing is padded, though the second sentence could be folded in for tighter structure.

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

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

For a 4-parameter file-mutating tool with no annotations and no output schema, the description covers the primary flow and the encrypted-input case but leaves the overwrite behavior and the failure/return expectations unstated. A reader can call it, but not confidently predict side effects.

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

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

Schema description coverage is 0%, so the description must compensate, and it does explain input ordering, output_path, and the passwords map ('maps an input path to its password') beyond the bare schema. However, the overwrite parameter is left completely undocumented in both schema and description.

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

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

States a specific verb and resource ('Merge PDFs') plus the destination ('into output_path') and a meaningful behavioral detail (order is preserved). The action is unambiguous and clearly distinct from siblings like split_pdf or extract_pages, though it never names or contrasts those siblings 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?

There is no when-to-use guidance and no routing to or away from alternatives such as images_to_pdf or convert_to_pdf. The only situational hint is the implicit note that passwords are needed for encrypted inputs, which is a parameter detail rather than usage guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only describes what the transformation does. It doesn't state whether the operation is destructive (the overwrite param and output_path handling suggest in-place vs. copy behavior that is never explained), whether a password is needed for encrypted inputs, or what happens on failure.

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

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

A single front-loaded sentence with no waste. It is appropriately terse, though the brevity contributes to the underspecification captured in other dimensions.

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 6 parameters, no annotations, no output schema, and 0% schema coverage, the description is far too thin. An agent lacks the information needed to call it correctly (password handling, overwrite/output 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 0% across 6 parameters, and the description only touches on two of them indirectly (linearize, compress). It says nothing about password, overwrite, input_path, or output_path semantics, leaving the challenge of handling password-protected or in-place edits unexplained.

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

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

States a specific verb+resource ('Shrink a PDF') and names the two operations (linearize, recompress), which distinguishes it from siblings like repair_pdf or flatten_pdf. However, it doesn't explicitly differentiate itself from those tools, so it falls 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?

The description gives no guidance on when to use this tool versus alternatives such as repair_pdf, flatten_pdf, or encrypt_pdf. There are no prerequisites, no exclusions, and no routing cues for the agent.

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 discloses a genuinely useful non-obvious behavior (operates on encrypted files without a password, returning is_encrypted only), but it omits the read-only/non-destructive safety profile, error behavior on corrupt files, and any cost/perf notes.

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 primary purpose and return fields, then the encryption caveat. Every sentence earns its place; nothing is padded.

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 and no annotations, the description does the necessary work by listing what is returned and how encryption is handled. It is nearly complete for a simple inspection tool; the only gap is the safety/destructiveness profile and unmentioned input_path semantics.

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

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

Schema coverage is 0%, so the description must compensate. It adds real meaning for the password parameter by explaining it is not required to read encryption status, but input_path is left entirely unexplained and the password's exact effect on other returned fields is not clarified.

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 (Report) and resource (PDF info) and enumerates the exact fields returned (page count, file size, version, encryption status, metadata). This clearly separates it from extract_text or manipulation siblings, but it does not explicitly distinguish itself from the closest siblings get_metadata and check_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?

Implied usage for inspecting a PDF without modifying it, and it gives one useful conditional ('works on an encrypted file without a password'). However, it never states when to pick this over get_metadata or check_pdf, which overlap heavily in the sibling 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 important behaviors – unlisted pages are dropped unless append_unlisted=true, and repeated pages duplicate content – but says nothing about overwrite semantics, password handling, or where output is written for a tool that mutates/creates files.

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, each earning its place, with the core action front-loaded and the syntax example and drop behavior following immediately. 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?

For a 6-parameter tool with no annotations and no output schema, the description covers the critical page_order and append_unlisted semantics but omits the overwrite/output_path behavior that determines where results land and whether the input is modified.

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

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

Schema description coverage is 0% across 6 parameters, but the description compensates well for the most complex one, page_order, with concrete syntax examples ('3,1,2', '5-1', 'last,1-4') and explains append_unlisted. It leaves password, overwrite, input_path, and output_path entirely unexplained.

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

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

States specific actions (reorder/duplicate/reverse) on a specific resource (pages), which clearly distinguishes it from siblings like delete_pages, extract_pages, and rotate_pages. An agent can tell what it does without opening the schema.

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

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

Usage is implied by the actions described, but there is no explicit when-to-use guidance or comparison to alternatives such as extract_pages (subset selection) or rotate_pages. The agent must infer the selection criteria from context.

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

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

With no annotations, the description carries the full behavioral burden but only discloses the mechanism ('reading and rewriting'). It says nothing about whether the original file is modified, how failures on irreparable PDFs are handled, or permission/error behavior — significant gaps for 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?

A single front-loaded sentence with no filler; the operation and mechanism come first. It is efficient, though arguably too terse for a four-parameter mutation tool.

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

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

For a four-parameter mutation tool with no annotations and no schema descriptions, the description omits parameter meaning, side effects, and success/failure behavior. It is not complete enough for an agent to call it 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 0% and the description explains none of the four parameters. It never mentions input_path, output_path, overwrite, or password, nor the interaction between output_path and overwrite, so it adds no parameter meaning at all.

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

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

States a specific verb and resource: rebuild/repair a damaged PDF's structure, and adds the mechanism ('reading and rewriting'). An agent can tell this is a repair operation rather than extraction or optimization. It stops short of differentiating from near-siblings like check_pdf or optimize_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?

'Damaged PDF' implicitly signals the trigger condition, so usage is inferable. However, it gives no explicit when-to-use guidance, no note about first diagnosing with check_pdf, and no alternatives or exclusions.

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 usefully discloses rotation direction and default scope, but says nothing about whether the source file is modified, how `overwrite` and `output_path` interact, or that password-protected PDFs require `password`.

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

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

A single sentence with the core operation front-loaded and the default-scope caveat tucked into a parenthetical. Every clause carries information; nothing is wasted.

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 six undocumented parameters, no annotations, and no output schema, the description is too thin. It covers the rotation itself but leaves file I/O, overwrite semantics, and encryption handling entirely to inference.

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

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

Schema description coverage is 0% across six parameters, so the description must compensate and does so only partially. It clarifies `degrees` (allowed 90/180/270) and the default behavior of `pages`, but `input_path`, `output_path`, `password`, and `overwrite` are left completely undefined.

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 (rotate), resource (pages), and direction (clockwise), so there is no ambiguity about the operation. It does not explicitly contrast with siblings like rearrange_pages or extract_pages, but 'rotate' is distinct enough in this set that an agent can route to it without confusion.

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 only usage detail is the parenthetical that omitting `pages` rotates all pages, which is really a default-value statement, not guidance. There is no mention of when to prefer this over rearrange_pages, nor prerequisites such as needing a password for encrypted inputs.

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 behavioral burden and does not meet it. It never says whether metadata is written in place or to output_path, what happens to existing tags by default, how 'overwrite' behaves, or that password-protected files require a password.

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

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

Two short sentences, front-loaded and free of filler, but brevity here shades into under-specification rather than disciplined concision. The allowed-keys sentence is the only content-bearing part.

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 mutation tool with a nested object, zero schema descriptions, no annotations, and no output schema, this is thin. The allow-list of metadata keys is helpful, but write semantics, path handling, and password/overwrite behavior are all 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 0% for 5 parameters, so the description must compensate and largely fails. It usefully enumerates the permitted keys inside 'fields', but says nothing about input_path, output_path, overwrite, or password, or the in-place-vs-copy behavior they imply.

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?

'Set metadata' names a specific verb and resource, and the sibling set (get_metadata, pdf_info) makes the read/write distinction inferable. It does not explicitly contrast itself with get_metadata, but the operation 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?

No statement of when to use this versus get_metadata or pdf_info, no prerequisites (e.g., needing to read metadata first, or encryption requirements). The agent must infer usage entirely from the name.

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 behavioral burden. It states output cardinality—one file per range, otherwise one file per page—but omits overwrite behavior, password handling, output naming, and whether the original file is modified.

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 short, front-loaded, and includes a concrete example. Every sentence supports range formatting or default behavior, with 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?

For a five-parameter tool with no annotations, no output schema, and zero schema descriptions, the definition is incomplete. It covers the most distinctive parameter but leaves overwrite/password/output behavior and error expectations 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 0%, and the description only documents the ranges parameter, including its semicolon syntax and default. It does not explain password, overwrite, input_path, or output_dir semantics, leaving most parameters to inference.

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: "Split a PDF into several files." That lets an agent distinguish it from merge_pdfs and extract_pages by the multiple-output outcome, though no sibling is named explicitly.

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

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

It explains the ranges format and the default when ranges is omitted, which helps with invocation. However, it does not state when to choose split_pdf over extract_pages or merge_pdfs, nor does it mention prerequisites or exclusions.

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