pdf-splitter

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

Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.

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

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

The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential 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 single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.

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

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

The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present 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?

The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.

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 provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.

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 cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.

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

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

With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool 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?

There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.

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 begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.

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 explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.

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

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

The description explicitly states 'Read-only,' but the annotations declare readOnlyHint=false. This contradicts the annotations. Although the description adds useful behavioral details about unreadable files and the total count, the contradiction with the structured annotation is a serious inconsistency and forces the lowest score.

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 compact and front-loaded: the core behavior, output type, and failure handling are all stated in three short sentences. There is no filler or redundant restating 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 one-parameter tool, the description covers the main behaviors: per-file page count, total pages, readable count, and handling of unreadable files. It lacks an explicit output format or prerequisites, but the schema and sibling context cover most practical needs.

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 fully documents the 'paths' parameter as an array of PDF names uploaded with pdf_upload. The description adds context about counting multiple files and handling unreadable ones, but does not add new parameter-level semantics beyond what the schema already provides.

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: it counts pages in PDFs, reporting page count per file plus a total and readability count. This clearly differentiates it from siblings like pdf_info or pdf_pages, which serve different purposes.

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 for counting pages across any number of PDFs, and mentions that unreadable files are still reported. However, it does not explicitly specify when to use this tool versus alternatives like pdf_info or pdf_merge, nor does it state 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?

No annotations are provided, so the description carries the burden. It indicates deletion but does not explicitly warn that the action is permanent or irreversible. The destructive nature is implied but not fully disclosed.

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 concise sentence with no superfluous words. It conveys the essential information efficiently.

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 delete operation, the description provides sufficient context about what is deleted. It does not mention error cases or output, but those are not critical for basic usage.

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

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

The schema provides no description for 'name', and the description does not clarify whether 'name' refers to the original filename, a stored identifier, or something else. Since this is the only parameter, the ambiguity is notable.

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?

Description clearly states the action (delete) and the resource (PDF stored for your token, including uploaded or generated). It is unambiguous and distinct from sibling tools like pdf_upload or pdf_merge.

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 explains the scope (stored for your token, uploaded or generated) and implies when to use it (to remove a stored PDF). It does not explicitly name alternative tools, but none of the siblings perform deletion, so context is sufficient.

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 takes on the burden of explaining behavior. It clearly states that the tool lists both user-uploaded and server-generated files, and includes sizes, which is sufficient to infer a read-only, non-destructive operation. It does not mention any side effects, but none are expected.

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, concise sentence that conveys all essential information without redundancy. It is front-loaded with the action and subject, making it easy to parse.

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 listing tool with no parameters, the description is complete. It explains what is listed, for whom, and what information is included (sizes). Given the lack of an output schema, this adequately covers the expected 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?

The tool has zero parameters, and the schema reflects that (100% coverage). The description adds no parameter-specific detail, but none is needed. The baseline for no parameters is 4, and the description does not introduce ambiguity.

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 clearly states the tool's purpose with a specific verb ('List') and resource ('PDFs stored for your token'). It also distinguishes itself by mentioning both uploaded and server-generated files, making it unambiguous among the sibling tools.

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 effectively indicates when to use the tool (to list all stored PDFs) and implicitly conveys that it is the appropriate choice for a full inventory. It does not explicitly name alternative tools, but the contrast with count/info tools is inferable from the listing scope.

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

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

The description states 'Read-only, never modifies the file,' but the annotation readOnlyHint is false. This is a direct contradiction. Since the description contradicts the annotation, it scores a 1 and is flagged as an annotation contradiction.

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 concise and front-loaded: it states the purpose, lists the inspected attributes, and adds the read-only note and free tier in two sentences with no fluff. Every sentence earns its place.

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

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

The tool is simple (one parameter, no output schema), and the description covers the return information. However, it omits the prerequisite that the file must be uploaded via pdf_upload (which is only in the schema), and does not mention error conditions or how the results are structured. Given the simplicity, it is adequate but has gaps.

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

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

The input schema fully documents the path parameter (100% coverage), so the description does not need to add parameter details. The description adds nothing about path format or constraints beyond the schema, matching the baseline of 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?

The description clearly states the tool inspects a PDF and enumerates what it returns (page count, sizes, paper name, metadata, encryption). It has a specific verb and resource, but does not explicitly distinguish it from sibling tools like pdf_count or pdf_pages, so it misses the top score.

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

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

The description gives clear context on when to call it ('Call this tool to inspect a PDF') and notes it is read-only. However, it does not mention alternatives or conditions for using a different tool, so it stops short of full guidance.

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

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

Annotations are all false, so the description carries the full burden. It adds key behavioral disclosures: inputs are never modified, page sizes are kept as-is (potentially mixed), free tier limit of 5 files, and that the result may indicate mixed sizes. These go beyond the schema and are highly useful for an agent.

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 concise sentences with no wasted words. The purpose is front-loaded, followed by a behavioral caveat and a usage limit. Every sentence earns its place.

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

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

The tool is simple, and the schema covers all parameters, including the return link for out_path. The description adds necessary caveats about mixed sizes and free tier limits. No output schema exists, but the return behavior is implied through the out_path schema description, so coverage is adequate.

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 each parameter (paths, out_path, overwrite) is already clearly described. The tool description adds no extra parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

States a specific verb (join) and resource (PDFs) with a clear outcome (into one file). The order requirement is explicit, and the name 'pdf_merge' plus description unambiguously distinguishes it from siblings like pdf_split.

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 clearly implies when to use it (when joining PDFs) but does not explicitly name alternatives or state when not to use it. No exclusion criteria are given, so an agent must infer usage from the clear purpose.

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

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

The annotations only provide generic hints, so the description adds meaningful behavioral context: the input is never modified, repeated page references are copied twice, and the free tier is capped at 30 pages. These details go well beyond the annotation flags and help an agent predict side effects and limits.

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 compact sentences with no filler. The core instruction is front-loaded, and the example plus caveats are high-signal and directly useful for invocation.

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

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

The description covers the operation, page-selection rules, input safety, and a usage limit, while the schema documents all parameters and the download-link behavior. Naming sibling tools for routing would improve it further, but the current guidance is sufficient for correct usage.

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 by explicitly clarifying page ordering and duplicate-copy behavior for the 'pages' parameter, which complements the schema's examples rather than merely repeating them.

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 (pull/extract) and resource (selected pages into one new PDF), making the tool's function unmistakable. It is clearly distinct from sibling tools like pdf_merge, pdf_split, and pdf_reorder because it focuses on selecting existing pages into a single output 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?

The opening phrase 'Call this tool to pull selected pages into one new PDF' gives an unambiguous use case. It does not explicitly name sibling alternatives or exclusion conditions, but the intended scenario is clear enough for an agent to select it correctly.

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

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

The description discloses that it writes a new PDF and enforces that each page appears exactly once, which is useful behavioral context beyond the annotations. However, annotations provide no safety hints (all false), and the description does not mention what happens on invalid order input or overwrite conflicts, so the behavioral picture is incomplete.

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 first two sentences are front-loaded and efficient: they state the action, the constraint, and the relevant alternative. The final stray word 'Pro.' adds no informational value and keeps it from a perfect score, but the overall structure is still tight.

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 and no output schema, the description plus the fully descriptive schema cover tool selection, invocation, validation rules, and output behavior (the download link is mentioned in the out_path schema). It is complete enough for correct use, with only edge-case behavior left implied.

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

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

The input schema already describes all four parameters with 100% coverage, including the 1-based order, output path, and overwrite default. The description adds rationale ('nothing drops by accident') but no new parameter-level 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 a concrete action ('write a new PDF') and a specific resource (PDF pages), and it clearly separates itself from pdf_pages by noting that reordering requires every page exactly once. This lets an agent distinguish pdf_reorder from the many PDF sibling tools without opening the schema.

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

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

The description explicitly frames when to call this tool ('pages in the order you give') and names the alternative for a different case: 'use pdf_pages for a subset.' This gives the agent a clear when-to-use and when-not-to-use signal. It does not discuss every sibling, but the most relevant alternative is addressed directly.

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

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

Annotations are all false, so the description carries the burden. It discloses that rotation is additive, that a new file is written, and that the free tier is limited to 30 pages. It doesn't mention whether the original file is left untouched, but 'writes a new file' implies it. The download link validity is in the schema, not the description, but the description adds useful behavioral context.

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

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

Three sentences, each earning its place: the action and direction, the additive behavior and use case, and the output and free-tier limit. Front-loaded with the core action.

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

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

For a 5-param tool with no output schema, the description covers the core behavior, the use case, and the free-tier limit. It doesn't explain the return value (download link) but the schema's out_path description covers that. It also doesn't mention overwrite behavior, but the schema covers it. Overall, complete enough for an agent to call correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds the meaning of positive degrees (clockwise) and that rotation is added to existing rotation, which complements the schema. However, it doesn't add much beyond the schema's parameter descriptions, so 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?

The description states a specific verb ('turn pages'), the resource (PDF), and the key constraint (multiple of 90 degrees, clockwise for positive). It also distinguishes itself from sibling tools by mentioning rotation and writing a new file, which is not covered by pdf_merge, pdf_split, pdf_reorder, etc.

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

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

The description gives clear context: use for sideways scans, rotation is added to existing rotation, and it writes a new file. It doesn't explicitly name alternatives or when not to use it, but the context is strong enough for an agent to select it appropriately among siblings.

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

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

The description adds meaningful behavior beyond the sparse annotations: the input is never modified, ranges are 1-based and open-ended, and the free tier has a 30-page limit. It does not address overwrite safety, but that is already covered in the input schema.

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

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

The description is three sentences with no fluff: it leads with the action, gives a concrete range example, then states safety and limits. Every sentence earns its place.

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

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

Given detailed per-parameter schema descriptions, the tool description plus schema cover required inputs, range syntax, overwrite behavior, output naming, and download links. The main omission is explicit guidance about when to prefer this tool over siblings, but the core calling context is 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 description coverage is 100%, so the schema already documents all parameters with examples. The description reinforces the range syntax with an expanded example but does not add significant new parameter meaning beyond what the schema provides.

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: 'write one new PDF per range.' This clearly distinguishes the tool from siblings like pdf_merge or pdf_reorder, and the concrete range example makes the split behavior 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?

The opening phrase 'Call this tool to write one new PDF per range' gives a clear trigger condition. However, it does not explicitly name alternatives or state when not to use the tool, leaving some inference to the agent regarding the sibling tools.

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

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

Beyond annotations, it discloses that the input file is untouched, that the output is a download link valid for one hour, that the default center position is drawn on a 45-degree diagonal, and that free tier restricts colors to preset PAID/DRAFT. These are genuinely useful behavioral traits not captured by the annotations.

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

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

Three sentences, zero waste. The core purpose and key constraints are front-loaded, and each sentence carries information without redundancy.

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

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

Given 9 parameters, the schema fully documents them and the description adds the critical operational details (output link expiry, free-tier limits, default diagonal). It does not mention error handling or prerequisites, but with a full schema and no output schema, this is a minor gap.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning for the 'text' parameter (preset behavior) and 'position' (diagonal default), enriching the parameter semantics slightly beyond the schema. It does not detail all params, but the schema already does that robustly.

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

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

The description states a specific verb ('draw'/'stamp'), a resource (PDF pages), and concrete examples (PAID, DRAFT). It clearly distinguishes this from other pdf_* tools like pdf_merge or pdf_split by focusing on stamping text across 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?

The purpose is unmistakable, and the free-tier limitation (PAID/DRAFT presets) gives a constraint on when certain values are usable. However, it does not explicitly contrast this with the sibling pdf_watermark_business or give a 'use this when...' vs alternatives, leaving some inference to 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?

The annotations already declare read-only and idempotent behavior, but the description adds valuable context beyond that: it discloses best-effort behavior, returns nothing for scans (no OCR), returns glyph indices for custom-encoded fonts, and states that the tool will indicate which case applies. It also mentions the unlimited free tier, which is helpful operational context.

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 concise, front-loaded with the primary purpose, and uses four short sentences with no wasted explanation. The 'Read-only' sentence is slightly redundant with the annotations, but the overall structure is tight and effective.

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 no output schema, the description adequately explains what to expect from the return value: normal extracted text, nothing for scans, or glyph indices for custom fonts, plus an indicator of which case applies. Combined with schema-documented parameters and annotations, the agent has enough information to use the tool correctly.

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

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

Schema description coverage is 100%, so the path and pages parameters are already documented in the input schema. The tool description does not add parameter-level detail beyond what the schema provides, so the baseline of 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?

The description clearly states the verb and resource: 'best-effort text extraction' from PDFs. It distinguishes the tool from siblings like pdf_info and pdf_pages by focusing specifically on text content rather than metadata or page operations, and it explicitly describes the scope and limitations.

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 explicitly tells the agent when to call it: 'Call this tool for best-effort text extraction from standard-font PDFs.' It provides clear context for use, though it does not name alternative sibling tools or explicitly state when not to use it beyond the scan/custom-font edge cases.

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 burden of behavioral disclosure. It explains persistence across calls, URL fetch constraints (public hosts, timeout, redirects, size cap), request body limits, and how server-written files are named and returned as download links. This gives a clear picture of side effects and limitations.

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 detailed and informative, but somewhat repetitive, particularly around the URL vs. base64 trade-off and the size limitations. It could be tightened without losing meaning, but the information is well-organized and directly relevant.

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

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

The description fully covers the operational context: how uploads are stored, how they are referenced, what limits apply, and how they can be listed or deleted. Since there is no output schema, this level of context is sufficient for an agent to use the tool correctly.

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

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

The description complements the schema by explaining the relationship between `pdf_base64` and `url`, emphasizing that exactly one must be provided. It adds practical guidance on base64 size limits, URL restrictions, and the naming format for `name`, all of which go beyond the schema's existing descriptions.

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 clearly states the tool's purpose: uploading a PDF to a hosted endpoint for later reference by name. It also distinguishes it from sibling tools by explaining that uploaded files are used as `path` arguments in other PDF operations.

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 provides explicit guidance on when to use this tool, including the choice between `pdf_base64` and `url`, the recommendation to use `url` for files over about 10 KB, and how uploaded names are reused across sibling tools. It also mentions related tools like `pdf_files` and `pdf_delete_upload` for managing uploads.

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

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

Annotations already communicate that this is a non-readonly, non-idempotent operation caused by a write. The description adds the source restriction but does not disclose side effects such as whether the input file is left untouched, whether overwrite applies, or the one-hour download validity, which are only implied in the parameter schema.

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

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

The core instruction is one efficient sentence that front-loads the action and use case. The trailing 'Pro.' is unnecessary and slightly weakens the otherwise lean 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 simple tool with four documented parameters, the description provides the missing context of when and on which documents to use it, and the schema covers the operational details. The lack of an output schema is mostly mitigated by the out_path parameter description mentioning the download link.

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

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

Schema description coverage is 100%, so the baseline applies; the description does not add meaningful parameter detail beyond what the schema already documents. It merely implies the business details come from the shared profile, which is not tied to any specific parameter.

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 clearly states the action (put business name and VAT id in the footer) and the resource scope (every page of documents from the shared profile mcp-invoice and mcp-docx write). It is specific enough to distinguish it from generic PDF operations, though it does not explicitly differentiate it from the sibling pdf_stamp 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?

It gives a clear usage context: apply before sending a document out, and only to documents created from the mcp-invoice and mcp-docx shared profile. It does not state when not to use it or mention alternatives, so it stops short of full exclusion guidance.

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