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

Annotations only provide 'openWorldHint' and 'idempotentHint', which already convey some behavioral context. The description adds the fact that the tool reduces file size and may cap dimensions, but it does not disclose important behavioral details like whether the operation is lossy, what happens if neither input parameter is provided, or whether the original image is modified. It does not contradict 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?

The description is a single, front-loaded sentence that states the primary purpose and the key optional behavior without any filler. It is appropriately sized for a tool whose parameter details are already covered by the schema.

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

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

Although the output schema exists and parameter descriptions are complete, the description fails to cover essential selection and invocation context. An agent cannot tell from the description that at least one image source must be provided, nor can it distinguish this tool from 'resize_image'. These gaps are significant for a six-parameter tool with zero required parameters and minimal annotations.

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 six parameters and their meaning. The description adds a general hint about capping dimensions, which maps to 'max_width' and 'max_height', but it does not provide any additional semantic clarity beyond the schema, especially around the mutually exclusive 'source_url' and 'file_base64' inputs.

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 ('Compress an image') and the intended outcome ('reduce file size, optionally capping dimensions'). It is specific about verb and resource, but it does not explicitly differentiate itself from the sibling tool 'resize_image', which also deals with image dimensions.

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 no guidance on when to use this tool versus alternatives like 'resize_image' or 'convert_file'. It does not mention preconditions, such as needing to supply either 'source_url' or 'file_base64', nor does it state when compression is preferable to resizing or format conversion.

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

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

The description adds no behavioral context beyond the operation's purpose; it does not disclose compression quality trade-offs, what happens if neither source_url nor file_base64 is provided, or how metadata removal affects the output. The idempotentHint and openWorldHint annotations exist, but the description itself does not add useful behavioral detail.

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 short, front-loaded sentence with no filler. It earns its place by clarifying that the tool reduces file size rather than merely 'compressing' ambiguously, though it leaves out other useful context.

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 a fully documented schema, an output schema, and annotation hints, the entry is minimally sufficient for a straightforward compression tool. However, it does not clarify that one of source_url or file_base64 must be supplied, nor does it warn about lossy quality trade-offs, which are meaningful 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 schema has 100% coverage and each parameter already has a meaningful description, so the tool description does not need to repeat parameter details. The description adds no new meaning beyond the schema, making the baseline 3 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 concrete action ('Reduce the file size') and a specific resource ('a PDF'), so an agent can identify the core purpose. It is reasonably distinct from siblings like compress_image and merge_pdfs, though it does not explicitly differentiate itself from other PDF 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?

No guidance is given on when to use this tool versus alternatives such as compress_image, convert_file, or the other PDF operations. The schema documents parameters, but the description provides no trigger conditions, prerequisites, 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?

Annotations provide only idempotentHint and openWorldHint, and the description adds no behavioral detail beyond the verb 'Convert'. It does not state whether the source file is modified, whether network access is needed (though source_url implies it), or any side effects. Since the description contributes nothing beyond the annotations, the transparency burden is largely unmet.

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 short sentence that is efficient and front-loaded with the verb 'Convert'. However, it is so under-specified that it borders on generic, listing input categories but no output formats, examples, or usage context. It earns its place as a minimal statement of purpose but lacks informative 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?

Given a rich schema (all parameters documented) and an output schema, the description needs only to provide overarching context and selection guidance. It fails to provide selection guidance or mention that target_format is required, relying on the schema for that. The coverage is adequate for basic invocation but incomplete for choosing among siblings.

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 each parameter already has a clear description. The tool description itself adds no parameter-level detail and does not clarify how filename, source_url, file_base64, or source_format interact. Per the baseline rule for high schema coverage, a score 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 states a clear verb ('Convert') and lists input types (document, spreadsheet, presentation, image, PDF, or data file), which conveys the general purpose. However, it does not distinguish this generic converter from specialized siblings like images_to_pdf, compress_pdf, or extract_pdf_text, so it lacks explicit differentiation.

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

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

There is no guidance on when to use convert_file versus any of the sibling tools. The description does not mention preferred scenarios, prerequisites, or exclusions, leaving an agent to infer usage purely from the schema. This is a significant gap given the crowded sibling set.

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 indicate idempotentHint=false, and the description's 'Create' is consistent with a non-idempotent operation. However, the description adds minimal behavioral context beyond purpose, such as potential side effects or link expiration, which is acceptable given the annotation coverage but not rich.

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 extraneous words. It states the action and purpose 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?

With zero parameters and an output schema present, the description provides sufficient information for an agent to invoke the tool. It names the resource and purpose, covering the essentials. Missing usage differentiation is captured under usage guidelines rather than completeness.

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 has no parameters, so the description has no obligation to explain them. Baseline of 4 applies because the schema is empty and the description correctly avoids inventing 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?

The description states a specific verb ('Create'), resource ('Stripe Billing Portal link'), and purpose ('for payment method and subscription management'). It is clear and distinct from sibling checkout tools by naming 'Billing Portal', though it does not explicitly contrast with them.

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 guidance is provided on when to use this tool versus alternatives like create_subscription_checkout or create_credit_pack_checkout. It lacks any context for selection or exclusions, leaving the agent to infer based on the name alone.

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 indicate idempotentHint=false and openWorldHint=true, so the description does not need to restate those traits. It adds value by identifying Stripe as the external processor and clarifying that the result is a checkout link rather than a direct charge, but it does not disclose additional behavioral details such as link expiration or repeated-call effects.

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?

One sentence with no filler, front-loading the core purpose and the key differentiator ('one-time extra credits'). Every word contributes to selecting or invoking the tool correctly.

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

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

For a simple two-parameter tool with enums, a full output schema, and annotations covering idempotency and open-world behavior, the description is largely sufficient. The only minor gap is the lack of explicit guidance contrasting this with create_subscription_checkout or manage_auto_recharge, but the description's clarity compensates.

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

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

Schema coverage is 100%, and both params have clear enum descriptions. The description adds no pack-specific or currency-specific detail beyond the schema, but it does provide helpful context that the credits are 'extra' and 'one-time.' Baseline 3 is appropriate because the schema handles the parameters well.

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 ('Create') and resource ('Stripe-hosted checkout link') and narrows the scope with 'one-time extra credits'. This clearly distinguishes it from subtools like create_subscription_checkout, which handles recurring billing rather than one-time credit purchases.

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 conveys a clear usage context: use this when the user wants to purchase extra credits as a one-time Stripe-hosted checkout. It does not explicitly name alternatives or say when not to use it, but the one-time vs. subscription distinction is sufficiently clear given the sibling tool set.

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 it creates a Stripe-hosted checkout link, which implies a mutating operation consistent with idempotentHint=false. However, it adds no detail about side effects, required authentication, or what the link entails beyond the annotation hints. Since annotations already flag openWorld and non-idempotent behavior, the description contributes minimal additional transparency.

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, efficient sentence that states the core purpose without filler. The key action and target audience are front-loaded, giving an agent immediate understanding.

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?

Despite the lack of usage guidance, the tool's simplicity (3 params, all documented) and the presence of an output schema mean the description is mostly sufficient. It clearly identifies the purpose and plan scope, and nothing essential about how to invoke it is missing. Slight deduction for not providing any context on when to prefer this over sibling checkout tools.

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%, with all three parameters having explicit descriptions. The description adds no new parameter details beyond what the schema already provides—the 'Pro or Scale' reference merely echoes the plan_id enum. Baseline 3 applies because the schema fully documents the 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?

The description specifies a concrete action (create) and resource (checkout link), and clearly scopes it to Pro or Scale subscriptions. This distinguishes it from siblings like create_credit_pack_checkout and create_billing_portal_link without needing to inspect schemas.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, conditions, or compare with related tools such as create_credit_pack_checkout. The selection must be inferred purely from the name and description.

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 include openWorldHint and idempotentHint, but the description adds no behavioral context beyond those. It does not disclose that the tool may fetch a URL or decode base64 input, nor does it mention potential network dependencies or timeouts. The description is neutral and adds no extra insight.

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 front-loads the action and output. No filler words or redundant 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?

The tool has four optional parameters, but the description does not explain that a PDF source (either URL or base64) must be provided, which is a critical operational detail. The output schema exists, so return structure is covered, but the input requirement gap makes the description incomplete for 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 coverage is 100%, with all four parameters described in the schema. The description does not add any additional meaning beyond what the schema already provides, such as clarifying that source_url and file_base64 are alternatives and at least one is required. Baseline of 3 is appropriate given high schema coverage.

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 (extract), the resource (PDF), and the output format (structured JSON), and it distinguishes this tool from siblings like merge_pdfs or compress_pdf. The mention of optional tables adds specificity without ambiguity.

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 to extract text from PDFs but provides no explicit guidance on when to use it over alternatives (e.g., convert_file) or any exclusions. No prerequisites are mentioned, such as needing to supply either source_url or file_base64.

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 idempotentHint and openWorldHint annotations already cover the key behavioral traits, and the description does not contradict them. It adds little beyond 'current' indicating live data, but no additional behavioral context such as caching, rate limits, or side effects is 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 wasted words. Every word adds semantic value and the key output fields are 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 zero parameters, an output schema present, and annotations covering idempotency/open-world behavior, the description is fully adequate. Nothing an agent needs to invoke this tool correctly is missing.

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

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

The tool has zero parameters and the schema is 100% covered, so there are no parameter semantics to explain. Description cannot add value here beyond the schema, and the baseline for zero parameters is 4.

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 ('Return') and names the exact resource and fields: current plan, subscription status, and remaining credits. This clearly distinguishes it from billing siblings that create checkouts, portal links, or manage auto-recharge.

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 usage is implied by what the tool returns: an agent needing plan, subscription status, or remaining credits would naturally select this tool. However, it does not explicitly state when not to use it or mention alternatives like manage_auto_recharge or create_subscription_checkout.

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 include idempotentHint=true, which implies repeated calls produce the same result, and openWorldHint=true, suggesting unknown inputs may be accepted. The description does not contradict these but also does not add behavioral context beyond them. It doesn't disclose, for example, that it creates a new file, whether it overwrites existing files, what happens if no images are provided, or memory/performance constraints. With annotations present, the bar is lower, and the description adds no extra behavioral depth.

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 sentence with zero waste. It is front-loaded with the core action and resource. Every word contributes to understanding the tool's purpose. No redundancy or 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?

The tool has an output schema (not shown but implied by context signal), multiple input sources, and no required parameters. The description is minimal and relies heavily on the schema. It does not explain key ambiguities: what happens if both files_base64 and source_urls are provided, whether filenames are optional overrides, or how page_size 'fit' behaves. For a 5-parameter tool with 0 required params, the description could provide more operational context, though the output schema may cover return details.

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 every parameter (filenames, page_size, output_name, source_urls, files_base64). The description does not add meaning beyond what the schema provides. It doesn't clarify relationships between parameters, order of precedence, or constraints like whether filenames must match files_base64 indices, which is only hinted in the schema. Baseline 3 is appropriate because the schema carries the heavy lifting.

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

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

The description clearly states the action (Combine) and the resources (multiple images into one multi-page PDF). It is specific and immediately distinguishes it from siblings like merge_pdfs (which combines PDFs) and compress_image/resize_image (which work on single images). The verb 'Combine' plus object 'images' and result 'multi-page PDF' leaves no ambiguity.

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 says what the tool does but provides no guidance on when to use it instead of alternatives. It does not mention that it accepts base64 or URLs as inputs, nor when one input source might be preferred over another. Sibling tools like merge_pdfs are clearly different but not referenced. The usage context is implied from the name and schema but not explicitly 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?

Annotations already disclose idempotentHint (no state modification) and openWorldHint (may interact externally), and the description does not contradict them. It adds the scope 'every conversion slug supported by the MCP server,' which clarifies the exhaustive nature of the result, but provides no additional behavioral context such as rate limits, auth, or exception cases.

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 extraneous words. It conveys the entire purpose efficiently 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 the tool's simplicity (no parameters, no nested objects) and the existence of an output schema, the description is adequate. It states the action and scope, leaving return-format details to the output schema. It could mention a typical workflow (e.g., using this list to validate slugs for convert_file), but that is more usage guidance than completeness.

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, so there is nothing to add beyond the input schema. The baseline of 4 applies, and the description correctly omits parameter details because none exist.

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 ('List') and resource ('every conversion slug supported by the MCP server'), making the tool's purpose clear. It is distinct from sibling tools, which are all action-oriented (compress, convert, create, etc.), but it does not explicitly name a sibling or contrast itself, so it falls short of 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?

Usage context is implied rather than stated: listing supported conversion slugs is a natural discovery step before using conversion tools like convert_file, but no explicit 'use this when' or 'use instead of' guidance is provided. The description does not mention alternatives or exclusions, so an agent must infer the intended use.

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 the annotations, the description adds meaningful behavioral context: the tool both reads and mutates auto-recharge settings, and its output can include last recharge attempts and a manual payment link when a charge required auth or was declined. It does not mention all side-effect caveats, but it does not contradict the annotations and gives useful non-obvious 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?

The description is compact and front-loaded, leading with the core verb and resource, then listing the key behaviors and the no-argument usage hint. Every clause earns its place; there is no filler or redundancy.

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

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

Given only two optional parameters, an existing output schema, and the description's coverage of both read and write behavior plus the noteworthy payment-link output detail, an agent has enough information to decide when and how to call the tool. No critical calling information is missing.

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

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

Schema description coverage is 100%, and the schema already explains both parameters, including 'Omit to leave unchanged.' The description adds overall context about thresholds and attempts but does not provide param-specific semantics beyond what the schema states, 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 names a specific operation, 'check or change', on a specific resource, 'automatic credit-pack recharge', and enumerates the exact aspects involved (on/off, threshold, last recharge attempts, manual payment link). This clearly differentiates it from billing/checkout siblings by scoping it to auto-recharge management.

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 an explicit usage instruction: 'Call with no arguments to just check the current state,' which effectively distinguishes the read path from the change path. However, it does not explicitly name alternatives or exclusions, such as using get_billing_status for general billing status or create_credit_pack_checkout for manual purchases.

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 the annotations (openWorldHint, idempotentHint), the description adds the behavioral trait of preserving input order. It does not, however, disclose whether source files are modified, what happens to an existing output file, or how invalid/missing inputs are handled. With minimal safety-related annotations, this is a moderate gap.

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 no filler; the core action and the key ordering constraint are front-loaded. Every word 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 schema and output schema cover most details, but the description leaves the mutually-required nature of source_urls/files_base64 ambiguous: both default to null, so an agent could invoke the tool without any input sources. Stating that at least one source array is required would close this meaningful 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%, and the schema descriptions already explain output_name, source_urls, files_base64, and the ordering of inputs. The tool description adds no parameter-specific semantics beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Merge multiple PDFs into a single PDF') and adds the ordering constraint, making it clearly distinct from siblings such as split_pdf, images_to_pdf, and rotate_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?

Usage is implied by the purpose: use this when you need to combine PDFs. However, the description names no alternatives and gives no guidance on when to prefer source_urls over files_base64 or how to avoid conflicts with convert_file/images_to_pdf, leaving this to inference.

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

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

Annotations declare openWorldHint=true and idempotentHint=true, which the description does not contradict. However, the description adds no behavioral detail beyond the basic action—it does not state whether the original PDF is modified, whether a new file is returned, or any side effects like fetching from a URL. With annotations covering some traits, a score of 3 is appropriate.

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 sentence, front-loaded with the core action, and contains no extraneous words. It is efficient and 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?

The description is minimal and does not mention the critical requirement that a PDF must be supplied via source_url or file_base64. While the schema documents these parameters, the description could guide the agent on how to provide the input. The output schema exists, so return values are covered, but the input source requirement is a notable gap for a tool with optional 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?

The input schema has 100% parameter description coverage, so the baseline is 3. The description does not elaborate on parameters, such as the necessity of providing either source_url or file_base64. It adds no extra meaning 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 clearly states the action: 'Add password protection (encryption) to a PDF.' It specifies a verb (Add), a resource (password protection), and a target (PDF), which distinguishes it from siblings like unlock_pdf (removing protection) and compress_pdf (compressing). The purpose 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?

The description implies usage when password protection is needed, but it does not explicitly mention alternatives or exclusions. An agent must infer that this tool is for encrypting a PDF, not for other PDF operations. There is no guidance on when not to use it or how it differs from unlock_pdf or other PDF tools, so the guidance is only implied.

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 mark it as non-idempotent and open-world. The description adds no further behavioral detail (e.g., that it sends a one-way message, no confirmation). It does not contradict annotations, but it provides no extra disclosure beyond the verb.

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 zero fluff. It states the action and recipients clearly, making it highly efficient for an agent 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 feedback tool with fully documented parameters and an output schema present, the description covers the essential purpose. It could mention expected side effects or return behavior, but these are adequately implied by the tool's role and schema coverage.

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 has 100% coverage with descriptions for all four parameters. The tool description does not add any parameter-specific guidance beyond the schema, so it sits at the baseline for fully documented schemas.

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 'Report' with clear targets (bug, missing conversion, quality issue) and identifies the recipient team. It unambiguously distinguishes from all sibling tools, which are conversion/manipulation actions.

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 implies when to use it (when encountering a bug or quality issue), and no sibling tool serves this function. However, it does not explicitly state when not to use it or mention 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?

Annotations include openWorldHint and idempotentHint but do not characterize side effects, source handling, or output behavior. The description adds no behavioral context beyond restating the action; it does not say whether the original is preserved, how source_url/file_base64 are resolved, or what happens when both are provided.

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 sentence with no filler and the main verb/object are front-loaded. It is efficient, though too terse to carry helpful usage or behavioral context.

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 six optional parameters, two possible image source fields, and an output schema, the description leaves critical invocation details unstated. An agent cannot tell from the description alone whether one of source_url/file_base64 is required, how width/height/fit interact, or what a minimal valid call looks like.

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 each parameter already has a meaningful definition. The description only reinforces width/height and adds no extra semantics for fit, format, or source selection, so the baseline score 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 states a specific verb ('Resize'), a clear resource ('an image'), and the key operation ('to the given width/height'). It does not explicitly differentiate from sibling conversion/compression tools, but the action is distinct enough from compress_image and convert_file.

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 about when to use this tool versus compress_image, convert_file, or images_to_pdf, and no prerequisites or exclusions are mentioned. Any usage direction is only implicit in the tool 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?

Annotations declare openWorldHint and idempotentHint, but the description adds no behavioral context beyond the operation itself. It does not state whether a new PDF is returned, how the source is consumed, what side effects occur, or 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 a single sentence with no fluff and is front-loaded. It is concise, but it is so terse that it largely restates the tool's title, providing minimal added substance for an agent trying to understand the 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 4 parameters and an output schema, the description is too thin. It does not explain how to select between source_url and file_base64, does not resolve the ambiguity that only angle is required, and provides no context about expected output or edge cases, making it incomplete for 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?

The input schema has 100% coverage with descriptive parameter details for angle, pages, source_url, and file_base64, so the description does not need to repeat them. However, it also adds no additional meaning, such as whether source_url and file_base64 are mutually exclusive or if one is required, so it stays at the baseline.

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 a specific verb ('Rotate') and resource ('pages in a PDF'), which distinguishes it from sibling tools like merge_pdfs, split_pdf, or protect_pdf. However, it adds little beyond the title and omits the angle choices, relying on the schema to carry that detail.

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 tool versus alternatives, no mention of which input source (source_url vs file_base64) is needed, and no exclusions or prerequisites. Usage must be inferred entirely from the schema and tool 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?

The annotations include openWorldHint and idempotentHint, which cover some behavior. However, the description adds no additional behavioral context, such as whether the original PDF is modified, whether the output is a new PDF, or how out-of-range pages are handled. It does not contradict annotations but fails to add value beyond them.

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 waste. However, it is perhaps too brief to convey important usage context, but for a simple tool it is appropriately sized and front-loaded with the 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?

The tool has 3 parameters, an output schema, and is part of a larger set of PDF tools. The description lacks context on when to use it, how to select between source_url and file_base64, and what the output represents. Given the available schema and annotations, the description is insufficiently complete for an agent to confidently use the tool without additional 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?

The schema description coverage is 100%, with clear descriptions for all parameters. The tool description does not add extra meaning beyond what the schema already provides, but it does align with the pages parameter. Given high coverage, a 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 'extract' and the resource 'PDF', and specifies it deals with pages/ranges. This distinguishes it from sibling tools like merge, compress, rotate, etc. It is specific and 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 description provides no guidance on when to use this tool vs alternatives, nor does it explain the choice between source_url and file_base64. It is a single declarative sentence without any usage 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?

The annotations provide idempotentHint and openWorldHint, but the description adds no behavioral context beyond restating the operation. It does not disclose whether a new file is produced, whether the input is modified, or any side effects of the unlock 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 a single, front-loaded sentence with no filler. Every word is informative, and the operation is 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?

The input schema and output schema already cover parameter and return details, and the tool is simple enough that a one-line description suffices for selection. The only minor omission is explicit guidance about choosing between source_url and file_base64, but the schema describes both.

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 parameters are already well documented by the input schema. The description adds no additional parameter semantics, which is acceptable given the baseline for full schema coverage.

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 ('Remove') and names the resource ('password protection from a PDF'), clearly stating the tool's function. It is readily distinguishable from sibling tools, especially protect_pdf, because it performs the inverse operation.

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 guidance is given about when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The intended use is implied by the name and description, but the description never explicitly states when it should be selected.

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