toolforte

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

The phrase 'byte-exact' is a useful behavioral guarantee beyond the readOnlyHint and idempotentHint annotations; it signals that the transformation preserves bytes without charset conversion or normalization. It does not contradict the annotations, and the read-only/idempotent traits are already covered by 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?

One compact sentence states the full operation and adds the meaningful 'byte-exact' qualifier. There is no redundant wording or filler; 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?

For a simple two-parameter utility with full schema coverage, annotations, and an output schema, the description is nearly complete. It could mention failure behavior for invalid Base64 input or padding requirements, but these are minor gaps for such a straightforward tool.

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

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

Schema description coverage is 100%, and both parameters are already well documented: 'mode' enumerates encode/decode and 'text' explains its role. The description adds no additional parameter-level detail beyond the schema, 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 clearly identifies the exact operation: encode text to Base64 or decode Base64 back to text. The verb pair 'encode/decode' plus the resource 'Base64' makes the tool's purpose immediately obvious and distinguishes it from siblings like url_encode.

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 for when to use the tool: whenever Base64 encoding or decoding is needed. It does not explicitly name alternatives or exclusion criteria, but the operation is specific enough that an agent can confidently select 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?

Annotations already mark the tool as read-only and non-destructive. The description adds meaningful behavioral detail by stating the exact outputs: 'net, VAT, and gross amounts rounded to cents.' This goes beyond the schema and gives the agent a clear expectation of the result.

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 exactly two sentences, with the core operation front-loaded and no filler. Every clause contributes value: the two modes, rate flexibility, a real-world example, and the return format.

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, stateless calculation tool with full schema coverage, a read-only annotation, and an output schema, the description is complete. It states inputs, modes, rate range implication, and the rounded output values, leaving no significant gap 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?

Schema description coverage is 100%, and the schema already fully documents amount, rate, and mode, including the meaning of the add/extract enum values. The description adds a small useful example ('21 for Dutch BTW') but does not meaningfully expand parameter understanding beyond the schema, 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 states a specific verb and resource: 'Add VAT to a net amount or extract VAT from a gross amount.' It also clarifies the rate flexibility with the example '21 for Dutch BTW', making the tool's purpose immediately obvious and distinct from the unrelated 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 gives clear context for when to use the tool by naming the two modes ('add' and 'extract') and the broad applicability ('at any rate'). It does not explicitly mention exclusions or compare to sibling tools, but no close alternative exists among the siblings, so the guidance is adequate.

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 the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by stating the check is syntax-only and does no VIES lookup, and by listing the supported country prefixes. No contradictions with annotations were found.

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 sentences carry all essential information: the operation, the limitation, and the full supported-prefix list. Nothing is wasted, and the key boundary (no VIES lookup) 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?

For a simple one-parameter, read-only validation tool with full schema coverage and an output schema present, the description is complete. It provides the scope, constraints, and supported values an agent needs to invoke 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 schema fully documents the vatNumber parameter with an example, so the baseline is 3. The description adds useful context about accepted country prefixes but does not provide additional format-level details beyond what the schema example already shows.

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: checking the format of EU/GB/CH VAT numbers. It clearly distinguishes itself from a VIES registration lookup and enumerates supported country prefixes, making its scope unambiguous relative to siblings like validate_email and calculate_vat.

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 limits the tool to syntax-only validation and notes that it does not perform VIES registration lookup, giving clear guidance on what it should and should not be used for. It does not explicitly name alternative tools, but the context is sufficient for an agent to choose 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds that the conversion uses 'exact math,' which is a useful behavioral detail beyond the schema and annotations. With the output schema provided, not spelling out return values is acceptable.

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, focused sentence states the operation, the input domain, and a distinguishing precision guarantee. Every word earns its place and there is no redundant filler or repetition of schema fields.

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

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

For a one-parameter, read-only, idempotent conversion tool with an output schema, the description is complete. It states supported formats and precision, while the annotations and output schema cover safety and return structure. Nothing essential is missing for an agent to select and invoke 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 single parameter with an example, but the description adds value by explicitly enumerating all supported color spaces (HEX, RGB, HSL, HSB). This goes beyond the schema's example, which only mentions HEX and RGB, and clarifies acceptable input forms.

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 ('Convert') and clearly identifies the resource: CSS colors between HEX, RGB, HSL, and HSB. It also adds a meaningful qualifier ('exact math') that conveys precision expectations. This makes it easy to distinguish from image conversion tools in the sibling list.

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 implicates when to use it: whenever a color needs conversion among the listed CSS color formats. While it does not explicitly name alternatives or exclusions, there is no competing color-conversion tool in the sibling set, so the context is sufficient without more 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?

The annotations already establish that the tool is read-only, idempotent, and non-destructive, so the description does not need to restate that. It adds 'exact' and a list of outputs, but it does not explain how words, sentences, or paragraphs are tokenized, or how reading time is calculated.

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 compact sentence that front-loads the concrete output metrics and contains no filler. It is appropriately sized for a low-complexity utility.

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?

This is a simple, one-parameter tool with full schema coverage, an output schema, and read-only/idempotent annotations. The description combined with the structured metadata provides everything needed for an agent to select and invoke 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 input schema fully documents the single `text` parameter, including its maxLength and description. The description's mention of 'a text' adds no meaningful information beyond what the schema already provides, 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 clearly states what the tool does: it produces exact counts for words, characters, sentences, and paragraphs, plus reading time. This is specific enough to distinguish it from sibling tools like summarize_text or calculate_readability.

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 intended use is implied: an agent should choose this tool when it needs quantitative text statistics. However, the description does not explicitly contrast it with related siblings such as calculate_readability or text_analysis, nor does it give any when-not-to-use 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 already establish that this is read-only, non-destructive, and idempotent. The description adds value by disclosing parser behavior beyond the annotations: delimiter auto-detection and quoted-field handling, which are the key behaviors an agent needs to understand.

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 that states the core action and two meaningful behavioral details. There is no filler or redundant repetition of schema 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 read-only conversion tool with a simple two-parameter schema, an output schema, and safety annotations, the description is sufficiently complete. The auto-detection and quoted-field behavior are the non-obvious details that matter, and they are included.

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 documents both parameters with 100% coverage, including descriptions and defaults. The description reinforces delimiter auto-detection but does not add new parameter detail, so the schema carries the load.

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: 'Parse CSV data into JSON,' and adds distinguishing behaviors (delimiter auto-detection, quoted-field handling). This clearly differentiates it from sibling conversion tools like format_json or markdown_to_html.

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 intended use is implied by the description: use this tool when you need to convert CSV text into JSON. However, it does not explicitly state when not to use it or point to any alternatives, so usage guidance is adequate but not explicit.

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 cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds behavioral context by stating the tool handles movable feasts and King's Day rules rather than returning a naive static list, which is useful beyond the structured 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 concise and front-loaded: it states the core function, the special cases it covers, and the recommended usage in two short sentences. There is no redundant 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?

This is a simple single-parameter, read-only tool with a full input schema, an output schema, and annotations covering idempotency and non-destructiveness. The description is complete enough for an agent to select and invoke 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 fully describes the 'year' parameter with a clear range and description, so the description does not need to add much. It does not go beyond the schema, but the schema already covers the parameter meaning 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 clearly states what the tool does: it returns the exact public holidays for a year, and it specifically calls out movable feasts and King's Day rules. This is more specific than the title alone and distinguishes the tool from generic date or holiday calculation utilities.

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 a clear usage signal: 'Use this instead of computing Dutch holidays yourself.' This tells the agent when the tool is appropriate, though it does not reference sibling tools such as working_days_between or list 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 already carry readOnlyHint=true, idempotentHint=true, and non-destructive status, so the bar is lower. The description adds genuine value beyond annotations by disclosing both output paths: success yields formatted JSON, and failure yields 'the exact parse error' — which tells the agent invalid input returns a diagnostic rather than crashing or silently passing through.

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 sentences and roughly 16 words with zero filler. The primary action is front-loaded, and the second sentence earns its place by clarifying both success and failure return behavior.

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

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

For a simple 2-parameter utility, everything needed is present: the output schema relieves the description of explaining return structure, annotations cover safety and idempotency, the schema documents all parameters at 100%, and the description discloses the error path. No material gap remains.

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 input schema already documents both the 'json' string and the 'indent' integer with range and default. The description's 'pretty-print' only loosely maps to the indent parameter and adds no parameter-level detail 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-resource pair ('Validate and pretty-print JSON') and adds a differentiator ('with a real parser') that distinguishes it from regex-based hacks. No sibling tool formats or validates JSON, so there is zero ambiguity about what this tool is for.

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 rather than explicit: the agent can infer 'use this when a JSON string needs validation or formatting,' and 'with a real parser' hints it is the reliable option. However, there is no explicit when-to-use/when-not-to-use statement or named alternatives, though none of the 37 siblings compete directly with this tool.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=false, destructiveHint=false), so the bar is lower. The description adds value beyond those annotations by disclosing the determinism mechanism ('Deterministic per seed'), the output-validity guarantee (BSNs that pass the elfproef and are accepted by real systems), and a scale limitation (the 50-person threshold). No statement contradicts 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?

Four sentences, purpose first, with every sentence earning its place: what it generates, when to prefer it over inventing data, the determinism guarantee, and the scale/routing alternative. There is zero filler and the most decision-relevant facts 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?

For a 7-parameter tool with nested lifeEvents configuration, rich annotations, and an output schema, the description covers the essentials: purpose, validity rationale, determinism, and the scale boundary with an alternative endpoint. A minor gap is the unspecified behavior at the 50-count boundary (clamping versus error), but the REST-API redirect resolves that decision point for the agent; output schema and annotations cover return values and safety.

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 reported at 100%, so parameters are already documented and the baseline is 3. The description adds modest semantic value by tying seed to determinism and the >50 limit to the count parameter, but it does not add syntax-level detail for dateFormat, referenceYear, or the lifeEvents weight object that the schema's enums and valid-id list already cover.

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 first sentence states a specific verb and resource: 'Generate Dutch BRP/GBA test persons with valid BSNs, families, addresses and life events', enumerating concrete features. This clearly distinguishes it from the closest sibling, generate_test_bsn, which by name only produces individual BSNs rather than full persons with families and life events.

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 explicit when-to-use guidance: 'Use this instead of inventing Dutch personal data: made-up BSNs fail the elfproef and are rejected by real systems.' It also names a specific alternative with its triggering condition: 'For more than 50 people or CSV output, use the REST API at https://toolforte.com/api/v1/tools/brp-test-data-generator.' An agent does not need to infer when to select this tool.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it explicitly promises deterministic handling of unicode and diacritics, which informs an agent about consistency and input normalization 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?

One sentence with no filler: it states the core transformation, the target format, and two important behavioral qualifiers (unicode handling and determinism). Every element earns its place and the main purpose 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?

For a simple, read-only, idempotent transformation tool with a single well-documented parameter and an output schema available, the description is largely complete. It could be slightly more specific about slug formatting conventions (e.g., separator or lowercase behavior), but the combination of description, schema, and annotations is sufficient for correct selection and 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 single parameter 'text' is fully described in the schema (100% coverage) as 'The title or phrase to turn into a URL slug'. The description does not add parameter-specific detail beyond the schema, but it doesn't need to because the schema already carries the meaning. 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 and resource: 'Convert text into a URL-safe slug'. It also adds meaningful scope by mentioning unicode and diacritics handling, which sets it apart from a generic url_encode sibling. An agent can immediately understand what the tool produces.

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

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

The description clearly implies the use case — turning text into a URL-safe slug — but it does not explicitly state when to choose this over alternatives like url_encode or other text-conversion tools. There is no when-not-to-use guidance, though the purpose is self-evident from the phrasing.

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 (readOnlyHint, destructiveHint), the description discloses that the generated numbers are fake and belong to no real person, and that they satisfy the elfproef check. This adds meaningful behavioral context about the output's validity and safety.

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 concise sentences with no filler. The core action and key behavioral guarantees are front-loaded, and every sentence adds value.

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?

This is a simple one-parameter tool with an output schema and safety-relevant annotations. The description covers the purpose, the validation property, and the approved environment. Nothing critical is missing 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 single count parameter is already fully documented in the schema with type, default, range, and description. The tool description does not add parameter-specific semantics, 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 uses a specific verb ('Generate'), names a precise resource ('Dutch BSN test numbers'), and adds distinguishing detail: they pass the elfproef but belong to no real person. This clearly separates it from sibling tools like generate_brp_test_data or generate_uuids.

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 phrase 'For development and test data only' gives clear contextual constraints on when the tool should be used. It does not explicitly name alternatives or list exclusions, but the restriction is unambiguous and sufficient for a simple generation tool.

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 readOnlyHint=true annotation, the description discloses meaningful behavior: correct mod-97 check digits, country-specific layouts, and the national check digit for BE and FR. It also states that the output passes validate_iban in full, which is useful behavioral context for an agent deciding whether this output is fit for purpose.

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 and scope, then adds the validation/check-digit details, and closes with a clear usage restriction. 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?

For a generator with only two optional, fully documented parameters and an output schema, the description covers what an agent needs: scope, validity guarantees, non-production intent, and the relationship to validate_iban. No critical behavioral gaps remain.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema by explaining what the country parameter controls: country-specific layout, mod-97 check digits, and BE/FR national check digits. This helps an agent reason about country-dependent behavior rather than just treating country as an enum value.

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

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

The description opens with a specific verb and resource: 'Generate structurally valid test IBANs' for a defined set of countries. It clearly states the generated IBANs belong to no real bank account and explicitly connects to validate_iban, making the tool's role and boundary unmistakable.

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 usage context: 'For development and test data only' and notes the IBANs are not tied to real accounts, which acts as an exclusion of production use. It does not explicitly contrast with sibling generators like generate_test_bsn, but the tool name and content make the intended scenario clear.

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

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

Discloses behavioral traits beyond annotations: 'Deterministic per seed' (reproducibility), 'XML is large' (output size warning), and the bulk API suggestion. Annotations already provide safety hints, and the description adds practical runtime context without contradicting 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?

Two sentences carry the core purpose, determinism, output-size caveat, and bulk alternative without wasted words. The most critical information (what it generates) 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?

For a tool with 8 parameters and nested objects, the description captures the essential choices (periods, schemes, defects), important caveats (large XML, summary vs full), and routing guidance (REST API for bulk). Since an output schema exists, describing return values is unnecessary.

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 all 8 parameters (seed, count, format, months, defects, startYear, schemeType, startMonth) are well documented in the schema. The description only echoes 'one or more periods' and 'defects', adding no meaningful new parameter meaning. Baseline 3 per the high-coverage rule.

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 ('Generate'), resource ('UPA pension declaration XML'), and scope ('for one or more periods, with employments, schemes and optional deliberate defects'). It clearly distinguishes this from other generate_* tools by naming the exact Dutch payroll-to-pension-fund message and its purpose.

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

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

Provides explicit when-to-use guidance: 'ask for the summary format unless you need the file contents' and 'for bulk use the REST API'. This tells the agent exactly when to prefer a lighter output or an alternative endpoint, which is valuable for correct invocation.

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=true and destructiveHint=false. The description adds meaningful context by specifying that the randomness is cryptographic and that values conform to the v4 variant. No contradiction with 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?

A single, front-loaded sentence communicates the core function with zero filler. Every word earns its place and no additional structure is needed for such a simple 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 stateless utility with one well-documented parameter, an output schema, and annotations covering the safety profile, the description is completely sufficient. Return values are covered by the output schema, so no further explanation is required.

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% for the single parameter (count), including type, default, min/max, and a description. The tool description adds no parameter-specific meaning beyond what the schema already provides, 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 (Generate) and a concrete resource (cryptographically random UUID v4 values). It clearly distinguishes this utility from all the listed sibling tools, none of which produce random identifiers.

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 its usage: call it whenever random UUIDs are needed. However, it does not explicitly state when to use it versus alternatives or mention any exclusions, though there are no closely related sibling tools to disambiguate.

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?

It discloses behavior beyond the annotations: output is a hosted download URL valid for 24 hours, demo is limited to 3 renders/day, API key authentication format is provided, and each render consumes 25 units. This gives the agent a clear sense of side effects, costs, and constraints without contradicting 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 concise and front-loaded with the core purpose. Every sentence adds useful information: rendering behavior, output characteristics, and usage limits. 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?

With an output schema present and the input schema covering all parameters, the description supplies the remaining operational details an agent needs: real PDF quality, download URL expiration, demo limits, authentication, and pricing. Nothing critical 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 schema description coverage is 100%, so the parameter meanings are fully documented in the schema. The description adds no new parameter-specific semantics, which is acceptable given the schema already handles that burden.

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: 'Render an HTML document to a real PDF with headless Chrome'. It also clarifies capabilities like full CSS support and print backgrounds, which distinguishes it from image-based conversions and sibling tools like url_to_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 description clearly conveys when to use the tool: when an HTML document needs to become a PDF with high fidelity rendering. It also provides important operational context such as the free demo limit and API key requirement, though it does not explicitly name sibling alternatives or 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?

With no annotations supplied, the description carries the full burden of behavioral disclosure, and it handles this well. It states the operation (re-encode as JPEG), the output (hosted download URL valid for 24 hours), the rate limit (3 renders/day demo), and auth/pricing (Bearer tf_... key, 25 units per render). No contradictions with annotations exist.

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 with the core action before moving to output, demo limits, and API key/cost details. Every sentence adds necessary operational information; there is no filler.

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

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

For a single-required-parameter tool with no output schema, the description is complete enough: it covers input constraints, output format/lifetime, authentication, rate limits, and cost. An agent can correctly invoke the tool and understand the result without additional context.

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

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

Schema coverage is effectively 100%: url is described as 'Public URL of the source image' and quality has type, default, min/max, and a description. The description adds the source size cap (15MB) and the fact that output is a hosted download URL, but it doesn't materially expand parameter semantics beyond 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?

Description uses a specific verb and resource: 'Re-encode an image... as JPEG at a chosen quality' and states the goal 'to shrink it.' It clearly separates it from sibling tools like image_resize or image_convert by specifying re-encoding/compression rather than resizing or generic conversion.

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 intended use case is implied by 'to shrink it' and the JPEG re-encoding detail, but the description never explicitly says when to choose image_compress over image_resize or image_convert, nor gives exclusion conditions. It provides functional context (public URL, max 15MB) but no alternative routing.

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

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

The description richly discloses behavior beyond the annotations: output is a hosted URL valid for 24 hours, demo usage is limited to 3 renders/day, API-key usage costs 25 units per render, and pixels are unchanged. It also mentions the 15MB source limit. This is extensive and material behavioral information for an agent deciding whether to call the tool.

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

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

The description is three sentences, front-loads the core operation and scope, and every sentence adds non-redundant value: conversion scope, output behavior, and cost/auth model. There is no filler or repetition of schema fields.

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

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

For a two-parameter conversion tool with an output schema present, the description covers the essential context: input requirements, output behavior/expiration, authentication options, usage limits, and unit cost. An agent has enough information to invoke the tool correctly and understand the consequences.

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 both parameters with 100% coverage, so the baseline is 3. The description adds meaningful extra semantics by specifying the 15MB source-size constraint for 'url' and enumerating the allowed output formats for 'format'. It does not add detailed parameter syntax, but the extra constraints are genuinely useful.

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

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

The description opens with a specific verb and resource: 'Convert an image (public URL, max 15MB) to another format (png, jpeg, bmp, gif, tiff)'. It also adds the scoping constraint 'pixels unchanged', which distinguishes it from sibling tools like image_compress and image_resize. The purpose is immediately clear and actionable.

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 states the input must be a public URL, the size limit, and the available output formats, which defines when the tool is appropriate. It provides cost and authentication context (demo limit vs. API key usage) but does not explicitly name alternatives or say when to choose another tool such as image_resize or image_compress. This is clear context without explicit 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?

The description is rich in behavioral detail beyond the annotations: it returns a hosted download URL valid for 24 hours, explains the free demo limit (3 renders/day), and discloses authentication requirements and cost (25 units per render with an API key). This gives the agent everything it needs to set expectations before calling.

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 action and output format appear in the first sentence, followed by necessary constraints, output details, and auth/cost information. Every sentence earns its place without fluff.

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 relatively simple 3-parameter tool with an output schema and rich annotations, the description covers the key operational factors: input constraints, dimensional behavior, output type and expiry, rate limits, authentication, and pricing. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the relationship between width and height ('one side keeps the aspect ratio') and by adding the 15MB source-image constraint, which is useful for validation before invocation.

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 ('Resize') and resource ('an image'), plus the output format (PNG). It does not explicitly distinguish itself from sibling tools like image_convert or image_compress, which would have earned a 5.

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

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

The description gives clear operational guidance: the image must be a public URL under 15MB, width and height can be provided alone or together, and aspect ratio is preserved when only one is given. It does not mention when to choose this tool over image_convert or image_compress, so it stops short of a 5.

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

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

The description goes well beyond annotations by disclosing output behavior (hosted download URL, 24-hour validity), usage limits (3 free demo renders/day), authentication expectations (Bearer tf_... key), and cost (25 units per render). This gives an agent a realistic model of side effects and requirements.

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 dense sentences with no filler. The core function is front-loaded, followed by output behavior and then auth/cost details. Every sentence contributes actionable 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 tool with an output schema, the description covers all essential invocation context: input constraints, output format, expiration, availability limits, and authentication. An agent can correctly decide whether and how to call this tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful detail beyond the schema: the 15MB per-image limit, the JPEG/PNG format requirement, and the one-image-per-page mapping. This enriches the agent's understanding of what the urls parameter should contain.

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

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

States a specific verb and resource: combining 1-20 public image URLs into one PDF, one image per page. Clearly distinguishable from sibling tools like html_to_pdf, url_to_pdf, and pdf_merge by the input type and 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?

Provides clear context for when to use the tool: when images need to be converted into a single PDF. It also gives practical constraints (public URLs, max size, 24-hour link validity, rate limits) that help an agent decide if this tool fits. It does not explicitly name alternatives or exclusion conditions, but the 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?

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety traits. The word 'deterministically' adds a small behavioral guarantee, but it is largely aligned with the existing idempotence hint and no other behavioral details (e.g., markdown dialect, sanitization) are 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, front-loaded sentence with no filler or redundant information. Every word earns its place and the core action is immediately clear.

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 conversion tool with one fully documented parameter, an output schema, and annotations covering safety and reproducibility, the description is complete. Nothing essential is missing for an agent to select and invoke 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 schema has 100% coverage for the single required parameter, with the description 'The Markdown text to convert'. The tool description adds no parameter-specific detail beyond what the schema already provides, 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 the exact transformation ('Convert Markdown to HTML') with a clear verb and output format. The sibling set includes similar converters like markdown_to_pdf and html_to_markdown, and the explicit HTML target makes the tool's role 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 the use case (when Markdown needs to be converted to HTML) but does not explicitly contrast with alternatives such as markdown_to_pdf or html_to_markdown. No exclusions or conditions are given, so the agent is left to infer routing from the name and 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 already declare destructiveHint=true and idempotentHint=true, so the deletion behavior is known. The description adds valuable context beyond that: it requires a free API key, entries remain private, and deletion helps manage quota. This is meaningful additional behavioral disclosure with no 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?

Two sentences with no filler. The operation is front-loaded, followed by the usage rationale and authentication requirement. Every sentence contributes useful 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 simple one-parameter deletion tool, the description covers the operation, when to use it, the auth requirement, and the privacy/quota context. The annotations cover destructiveness and idempotency. Minor gaps like return value or behavior for nonexistent keys are not critical given the tool's simplicity.

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 fully describes the only parameter, key, with type string, maxLength 200, and description "The key to delete." The description adds no further semantic detail about the parameter, so with high schema coverage 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 opens with a specific verb and resource, "Delete a stored key," which unambiguously states the operation. It is clearly distinct from the sibling tools memory_set, memory_get, and memory_list, which handle writing, reading, and listing respectively.

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 explicit usage context: "Use it to clean up entries you no longer need, since each API key has a quota." This explains when deletion is appropriate, but it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

The annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond those: it returns null for nonexistent keys, requires an API key, and scopes entries to the same API key. This gives the agent a realistic model of cross-session 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?

Three short sentences, with the core purpose front-loaded, then the null-result behavior, then the authentication requirement. Every sentence earns its place; no redundant or vague wording.

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 a simple single-parameter read operation, and the description provides everything needed to invoke it correctly: what it reads, how to reference stored values, the not-found behavior, and the auth requirement. Since output schema exists, return value details beyond null do not need to be described.

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?

Input schema coverage is 100% and the key parameter is already documented as 'The key to read'. The description adds the memory_set linkage but no additional details about key format, naming conventions, or constraints beyond the schema, so it stays at the baseline for 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 uses a specific verb-resource pair: 'Read back a value' stored with memory_set. It clearly distinguishes this from sibling write (memory_set), deletion (memory_delete), and listing (memory_list) tools, and specifies the null-return behavior for missing keys.

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 indicates this tool is for retrieving a previously stored value, explicitly linking it to memory_set. It does not explicitly contrast with memory_list or memory_delete, so it lacks full when-not/exclusion guidance, but the usage context is clear and unambiguous.

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 read-only, idempotent, and non-destructive, and the description adds genuinely new behavioral facts: newest-first ordering, retrieval of keys and sizes rather than values, and the API-key requirement for private storage. No contradiction with 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?

Every sentence earns its place: action and sort order, intended use, return payload shape, and authentication requirement. The most decision-relevant facts 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?

For a read-only, optional-parameter list tool with an output schema, the description covers discovery use case, ordering, filtering, response content, and authentication. Nothing necessary for correct invocation 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%, so the schema fully documents limit and prefix. The description independently notes prefix filtering but adds no parameter syntax or format detail beyond the schema, so the baseline score 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 opens with a specific verb and resource — 'List the keys you have stored' — and adds ordering, optional filtering, and an explicit note that it returns keys and sizes, not values. This clearly distinguishes it from memory_get, memory_set, and memory_delete.

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

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

'Use this to discover what a previous session left behind before deciding what to read' gives a clear when-to-use context and implies memory_get is for reading values. It does not explicitly name sibling alternatives or state when not to use it, so it stops just short of full routing 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 already flag the operation as non-read-only, idempotent, and destructive, so the description doesn't need to restate those. It adds meaningful context by disclosing persistence across sessions and the API-key/private-storage requirement. It could have explicitly said that setting an existing key overwrites the old value, but the destructiveHint covers the risk.

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

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

The description is front-loaded with the core action and purpose, then adds concrete examples and the auth requirement. It is efficient, though the motivational sentence about losing everything and the example list are slightly expandable; still, nothing is redundant enough to drop the score to 3.

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 an output schema and informative annotations, the description covers what, why, when, and the authentication prerequisites. The only notable gap is the lack of an explicit overwrite warning, but that is substantially covered by destructiveHint=true and the normal semantics of setting a key.

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 fully documents key and value, including namespacing and JSON serialization. The tool description adds only generic 'store under a key' wording and no parameter detail beyond the schema, which matches 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 opens with a specific verb and resource: 'Store a value under a key,' and states the persistence purpose ('read it back in a LATER session'). This clearly identifies it as a write/persist operation and differentiates it from siblings like memory_get and memory_delete.

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 explicit use cases ('what you already processed, a running list, a decision, intermediate results') and stresses the consequence of not using it ('everything you learn is lost'). It doesn't explicitly say when not to use it or name alternative memory tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the output nature (human-readable text plus next scheduled run times) but leaves details like the number of returned run times and timezone handling unspecified. No contradiction with 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?

Two short sentences with zero filler. The action is front-loaded ('Parse a cron expression'), and the second sentence adds meaningful routing guidance 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?

For a simple, deterministic, read-only utility with one well-documented parameter, the description conveys the essential contract: parse a cron expression into a description and next run times. The only slight gap is the unspecified count or format of the returned run times, but the rich annotations and simple schema keep this 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%: the only parameter, 'expression', already has a description and an example ('0 9 * * MON-FRI'). The tool description adds no further parameter-level detail, 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 states a specific verb and resource ('Parse a cron expression') and the exact outputs ('a human-readable description and the next scheduled run times'). The phrase 'Exact cron semantics' further signals that this is the authoritative tool for cron interpretation, distinguishing it from the many unrelated sibling utilities.

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 explicitly advises 'use this instead of interpreting cron syntax yourself,' which tells the agent when to defer to this tool over self-implementation. It does not name alternatives or exclusions, but no sibling offers cron parsing, so this context is sufficient for selection.

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 the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explicitly stating 'Do not log or store the password' and clarifies the in-memory analysis approach. This goes beyond the structured hint metadata and is important for sensitive data handling.

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

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

The description is two short sentences with no redundant wording. The primary action and scoring method are front-loaded, and the privacy warning is a necessary addition. 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?

For a single-parameter read-only tool with a full input schema and an output schema, the description is complete. It covers what the tool does, how it evaluates, and the critical privacy constraint. No important 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%, so the schema already fully documents the only parameter, including the in-memory/no-storage behavior. The description adds no additional parameter-level detail beyond what is already in the schema, so the baseline 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 uses a specific verb ('Analyze') with a clear resource ('password strength') and specifies the method ('entropy-based scoring') and output ('concrete feedback'). It is unambiguous and distinguishes the tool from the sibling validators and converters by its unique focus on password strength.

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 intended use is implied by the name and description: use when password strength analysis is needed. However, there are no explicit when-to-use, when-not-to-use, or alternative tool guidance. The description does not mention any exclusions or competing 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?

The description goes well beyond the annotations by disclosing the hosted download URL expiry (24 hours), the free demo quota (3 renders/day), the required Authorization header format, and the cost per render (25 units). This gives the agent a realistic picture of side effects, rate limits, and authentication needs.

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 operation and constraints come first, followed by output behavior, then authentication and quota details. Every sentence contributes necessary information without fluff or repetition.

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 single parameter, the existing schema coverage, and the presence of an output schema, the description provides all essential context: input constraints, output format, authentication, quotas, and pricing. An agent has enough information to decide whether to call the tool and how to format the 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 schema already documents the urls parameter with min/max items and merge order, so the baseline is 3. The description adds meaningful constraints not present in the schema, specifically the 10MB size limit per PDF and the 2-10 count range, which helps the agent validate inputs before calling.

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 ('Merge'), a specific resource ('2-10 PDFs'), and the outcome ('into one PDF'). It clearly distinguishes this from sibling tools such as pdf_split, images_to_pdf, and html_to_pdf by emphasizing merging existing PDFs from URLs.

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 whenever PDFs need to be merged and gives concrete constraints (public URLs, 10MB limit, 2-10 files). However, it does not explicitly describe when to prefer this tool over related siblings like pdf_split or images_to_pdf, nor does it state any 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?

Beyond the annotations, the description reveals meaningful behavior: output is a hosted download URL valid 24 hours, free demo quota is 3 renders/day, and paid API usage costs 25 units per render. It also discloses the 10MB input limit. No contradiction with 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 compact and front-loaded with the core function, then adds defaulting, URL expiry, quota, and auth details. A few sentences contain necessary operational constraints; none are wasted.

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

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

For a moderately complex tool with 3 parameters and an output schema, the description covers the key usage constraints, return behavior (hosted URL), expiry, quota, and authentication. Nothing essential for correct invocation 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%, so the schema already documents url, from, and to. The description adds the inclusive/1-indexed framing and the default for 'to', which is helpful but not a substantial compensation beyond an already complete schema.

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

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

States a specific verb (extract) and resource (page range from PDF) with precise details: 1-indexed, inclusive, output is a new PDF. It clearly distinguishes this from sibling PDF tools like pdf_merge or images_to_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?

Specifies when the tool applies: public URL, max 10MB, and that 'to' defaults to the last page. It does not explicitly name alternatives or exclusions, but the source/target/range constraints make the intended use clear.

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

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

The description discloses several non-obvious behaviors beyond the annotations: the result is a hosted download URL valid for 24 hours, demo usage is capped at 3 renders/day, and authorized usage costs 25 units per render. It also gives the exact Authorization header format and where to obtain the key. This substantially exceeds what annotations alone communicate.

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 with the primary purpose, followed by outcome, demo limit, auth, and pricing. Every sentence provides distinct, useful information with no fluff or repetition.

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 key operational facts an agent needs: output format, URL expiry, demo constraints, authentication method, and cost per render. Combined with a fully documented schema and an output schema, there are no major missing pieces for invoking 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 schema already documents both text and size adequately. The description does not add parameter-level meaning beyond the schema, but it doesn't need to; the schema carries the load. Baseline 3 is appropriate here.

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

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

The description opens with a clear, specific action: 'Generate a QR code as a downloadable PNG image.' It identifies both the resource (QR code) and output format (PNG), which distinguishes it from image manipulation siblings like image_resize or image_convert. The title 'QR code image' aligns with the description and adds 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 provides clear operational context: there is a free demo limited to 3 renders/day, and using a ToolForte API key consumes 25 units per render. It does not explicitly list alternatives or when-not-to-use cases, but the tool's purpose is unique enough among siblings that this is not a significant gap.

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 this as read-only and non-destructive, and the description adds valuable behavioral context: JavaScript is executed, navigation/cookie banners are stripped, and output includes title, description, content, and links. It also discloses rate limits and authentication requirements, which are beyond the annotations. There is no contradiction between description and 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 reasonably concise with the core purpose and key differentiator front-loaded. The usage guidance, output summary, and rate-limit information all earn their place, though the API-key and pricing details could be considered slightly extraneous. It remains structured and readable without being verbose.

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?

An output schema exists, so return values are covered. The description covers when to use, how it behaves differently from plain fetches, what output users can expect, and includes authentication/rate-limit details. For a tool with three simple parameters, this is fully sufficient for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents url, format, and maxChars well. The description does not add significant new meaning for parameters beyond what the schema provides. It mentions clean text vs. Markdown, but the schema already explains the format enum values, so the baseline 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 specific verb and resource: reads a web page as clean text or Markdown, with JavaScript execution. It distinguishes itself from plain fetch and sibling URL tools by highlighting the JS execution and clean output. The mention of 'clean text or Markdown' also differentiates it from screenshot/PDF tools among the siblings.

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

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

The description gives an explicit condition for use: when a plain fetch returns an empty shell or loading spinner, particularly for client-side rendered sites. It clearly explains the context but does not explicitly mention when not to use it or name alternatives like url_screenshot or url_to_pdf. This earns a 4 rather than a 5.

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

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

Annotations already cover safety with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by noting it runs 'using a real regex engine' and returns 'all matches with capture groups and indices.' There is no contradiction with 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?

Two sentences, front-loaded with the tool's purpose and followed by the key output behavior. Every phrase earns its place; 'real regex engine' adds important execution semantics without padding.

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

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

For a simple three-parameter utility with full schema descriptions, an output schema, and safety annotations, the description is complete enough for correct invocation. Invalid-regex behavior is not described, but the output schema and real-engine semantics make this a minor omission, not a blocker.

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

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

Schema coverage is 100%, so the schema already documents pattern, text, and flags, including the default 'g' flag and the 'without the slashes' constraint. The description adds little new parameter-level meaning, but it does not need to because the schema carries that load.

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 states a specific verb, resource, and scope: 'Run a JavaScript regular expression against a test string using a real regex engine.' It also clearly specifies the observable result: 'Returns all matches with capture groups and indices.' Although it does not explicitly name a sibling, no sibling tool is a regex tester, so it is clearly differentiated.

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 does not explicitly state when to prefer this tool over alternatives or give any exclusions. The 'real regex engine' wording implies it is for validating actual JS regex behavior, but that guidance is implicit. A sentence routing an agent to this tool versus similar utilities would improve 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond those annotations by specifying that the diff is exact, line-based, and produces add/remove/unchanged statistics. No contradiction exists.

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

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

The description is a single sentence that front-loads the core action and result. It contains no redundant phrasing or extraneous 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 simple two-parameter, read-only utility with a complete input schema and an output schema, this description covers the essential behavior: line-based diffing and the statistics returned. Nothing critical 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 input schema already documents both parameters, original and modified, with clear descriptions, so schema coverage is essentially complete. The tool description adds no parameter-specific semantic detail beyond the general line-based nature of the operation.

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, 'Compute', and names the exact resource and granularity: a line-based diff between two texts with add/remove/unchanged stats. This clearly distinguishes it from the listed sibling tools, none of which perform diffing.

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 intended use is implied: an agent would use this when an exact line-level comparison of two texts is needed. However, there is no explicit when-not-to-use guidance or mention of alternatives such as word-level or fuzzy diffing.

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=true and idempotentHint=true, covering safety and repeatability. The description adds 'exact percent-encoding,' which hints at strict encoding behavior, but it does not clarify edge-case behavior such as malformed percent sequences during decode or which characters are encoded.

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 redundant words. It states both the action and the key precision qualifier efficiently, making it easy 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 pure transformation tool, the description, schema, and annotations cover most of what an agent needs: parameters are documented, the operation is read-only and idempotent, and the return value is implicitly the encoded/decoded string. A slightly fuller mention of return behavior or invalid-input handling would make it fully complete.

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

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

Schema coverage for both parameters is essentially 100%: 'mode' is explained as 'encode or decode' and 'text' is described as the string to encode/decode. The description adds no substantive parameter meaning beyond what the schema already provides, 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 clearly states the specific action ('URL-encode or decode') and the resource ('a string'), and adds the meaningful qualifier 'with exact percent-encoding.' This distinguishes it from sibling transformation utilities and makes the tool's purpose immediately understandable.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. An agent must infer applicability purely from the tool name and description, with no explicit routing to or away from 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?

The description discloses important behaviors beyond the annotations: output is a hosted URL valid for 24 hours, demo limits are 3 renders/day, and a ToolForte API key costs 25 units per render. It also names the authorization header format. No contradiction with the annotations is present.

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 long and front-loaded with the primary action. The output URL behavior, demo limit, API key instructions, and cost are packed into two additional sentences with no wasted words.

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 input schema and output schema, the description covers all necessary operational context: what it does, what it returns, how long the result is valid, authentication requirements, and cost. An agent can correctly invoke this tool without additional research.

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 url, width, and fullPage in detail. The description adds the 'public' constraint and auth context but does not need to repeat per-parameter meanings. This meets 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 clearly states the action and output: 'Take a PNG screenshot of a public web page with headless Chrome.' It is specific enough to distinguish this tool from siblings like url_to_pdf or read_page by naming the format (PNG) and method (screenshot).

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

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

It gives clear context for use: public web pages, PNG output, and hosted download. It does not explicitly name alternative tools or exclusion criteria, but the purpose and constraints are evident without needing to inspect 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?

The description goes well beyond the generic annotations (readOnlyHint=false, idempotentHint=false) by disclosing concrete behavior: the hosted download URL expires in 24 hours, free demo limits to 3 renders/day, and paid renders cost 25 units each. It also specifies authentication with a Bearer tf_ API key. These are exactly the operational details an agent needs.

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 tightly packed sentences with no redundancy. It front-loads the primary action, then adds output lifetime, then authentication and cost details. Every sentence provides distinct, necessary information without repeating schema definitions.

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 3-parameter tool with full schema coverage and an output schema, the description covers the essential operational context: output URL expiry, free-tier limits, authentication format, and per-render cost. It does not need to explain return values because the output schema handles that. The 'public web page' wording also correctly scopes the accepted input.

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%, with each parameter already well-documented including defaults and enums. The tool description adds no new parameter-level meaning beyond restating that the URL is 'public,' which the schema also says. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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: 'Render a public web page to PDF with headless Chrome.' This clearly distinguishes it from sibling tools like html_to_pdf (raw HTML input) and url_screenshot (image output). The title 'Web page to PDF' reinforces the purpose 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 usage for public URLs and notes the API key/demo constraints, but it does not explicitly say when to use this tool over alternatives such as html_to_pdf or read_page. There are no when-to-use or when-not-to-use statements, so the selection guidance remains implicit rather than explicit.

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 and idempotentHint, so safety is covered. The description adds meaningful context by scoping behavior to syntax checking and common domain typos, which clarifies that it is not a deliverability or mailbox-existence check.

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 communicates the full purpose with a helpful example and no wasted words. It is compact and immediately scannable.

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

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

For a one-parameter, read-only, idempotent tool with an output schema, the description fully supports correct selection and invocation. Nothing essential is missing for an agent to understand what this tool does and how to call it.

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 only parameter at 100% coverage, so the description adds no additional parameter-level detail. The description does clarify what will be checked against the email, but the schema carries the semantic load.

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

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

The description names the exact verb and resource: 'Validate email address syntax' plus the extra typo-detection behavior with a concrete example. It clearly distinguishes this from sibling validation tools like validate_iban by explicitly targeting email addresses.

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 the tool: whenever an email address needs syntax validation or common domain typo detection. It does not explicitly name alternatives or exclusion criteria, but the email-specific scope makes the intended use unambiguous.

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 this as read-only and idempotent, so the description's job is to add behavioral nuance. It does this richly: mod-97 cannot catch a capital O substituted for zero, nationalCheck only applies to twelve listed countries, and a passing IBAN can still reference a non-existent bank. This is far beyond what annotations alone provide.

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

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

The first half is dense and valuable, but the description becomes bloated near the end. The sentence about 'A territory borrows another country's IBAN prefix' is confusing and ungrammatical, and the final two admonitions largely repeat the earlier 'format check, not a bank check' caveat. The definition would be stronger if trimmed after 'Absent nationalCheck means not implemented.'

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 return values (validity, country, bank identifier, nationalCheck), explains the main false-positive risk, and even mentions an edge case about territory IBAN prefixes. Combined with the single parameter and existing output schema, an agent has enough context to invoke the tool correctly, though the confusing tail adds noise.

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 only parameter is documented as 'The IBAN to validate,' so the baseline is 3. The description adds useful semantic context about what well-formed means, but it does not specify input formatting details such as uppercase requirements or whether spaces are accepted.

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

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

The description opens with a specific verb and resource: 'check whether an IBAN is well formed,' and enumerates the exact validation dimensions (mod-97, country code, length, character rules). It clearly separates itself from a bank or account check, though it does not explicitly distinguish 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 gives clear when-to-use guidance ('Never guess whether an IBAN is well formed: use this tool') and when-not-to-interpret guidance ('This is a format check, not a bank check'). It does not name alternative sibling tools, but none are direct IBAN-validation equivalents.

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, the description adds auth requirements ('Requires an API key', header format), account scoping, and what the response includes (id, inputs, steps, cost). This is valuable behavioral context that annotations do not cover.

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

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

The description is front-loaded with the core purpose and every sentence earns its place: workflow context, return contents, call ordering, and auth setup. It is detailed without being bloated.

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 with one optional parameter, an output schema, and safety-related annotations. The description fully covers scope, auth, return value, and how it relates to workflow_run, leaving no practical gap for an agent.

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

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

Schema coverage is 100% and the single parameter 'limit' is fully documented with default, minimum, maximum, and behavior ('newest first'). The description adds no additional parameter semantics, 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 opens with a specific verb and resource: 'List the workflows saved to the ToolForte account this API key belongs to.' It also distinguishes this tool from its main sibling by naming workflow_run as the downstream consumer.

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 explicitly tells the agent when to use the tool: 'Call this first: workflow_run needs an id from here.' This provides clear sequencing guidance and makes the relationship to the sibling tool unambiguous.

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 substantial behavioral detail beyond the annotations: each step costs credits, the call's credit counts as the first step's cost, steps run in order and stop at the first failure, the result reports the stopping step and spend, and the substitutions field warns when values were replaced. It also discloses the API key requirement and authentication mechanism, which is significant for a non-read-only tool.

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

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

The description is dense but every sentence carries operational value: purpose, prerequisites, cost model, execution order, failure behavior, substitution warning, and auth. It is front-loaded with the core purpose and then layers essential details without fluff.

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 complex execution tool, the description covers the critical non-obvious aspects: where to get identifiers, credit accounting, stopping conditions, substitution semantics, and API key requirements. Since an output schema exists, it does not need to describe return values, and nothing essential for an agent to call this tool correctly appears 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 input schema already provides 100% description coverage for both parameters. The description adds meaningful sourcing guidance by telling the agent to get workflowId and input keys from workflow_list, which helps the agent know where to discover valid values. This goes slightly above the baseline for fully schema-covered 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 opens with a specific verb and resource: 'Run one saved workflow by id and return what every step produced.' It clearly distinguishes workflow_run from the related workflow_list by telling the agent to get ids and input keys from workflow_list, so the agent understands workflow_run executes a saved workflow rather than listing one.

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 for using the tool: obtain the id and input keys from workflow_list, and understand the credit cost and failure behavior before invoking it. It does not explicitly state when not to use this tool or name an alternative for executing workflows, but with only workflow_list as a related sibling, the intended usage is adequately conveyed.

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=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral detail beyond that: inclusive date boundaries, weekday-only counting, and the optional exclusion of Dutch public holidays. No contradictions with the annotations are present.

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 redundant filler. The core behavior is front-loaded, followed by the optional holiday flag and intended use cases. 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?

For a simple, read-only calculation tool with a complete input schema and an output schema present, the description fully supports correct invocation. Nothing critical about the inputs, scope, or behavior 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%, so the schema already documents all parameters and their formats. The description does not provide significant additional parameter-level detail beyond what the schema contains, so a baseline 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 opens with the specific verb+resource ("Count working days between two dates") and clearly defines the scope: weekdays Mon-Fri, inclusive dates, and optional Dutch holiday exclusion. This clearly differentiates it from siblings like dutch_public_holidays, which returns a holiday list rather than computing a count.

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 names concrete use cases ("SLA, payroll, and planning questions"), which tells an agent when this is relevant. It does not explicitly state when to prefer an alternative or exclude other tools, but the context is clear enough for straightforward tool selection.

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