ToolForte

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive). The description adds 'byte-exact', which is a meaningful behavioral guarantee about losslessness beyond the annotations. It does not mention error behavior for invalid Base64 input, but this is a minor gap for such a simple pure function.

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

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

A single sentence that front-loads the core operation and includes the important byte-exact caveat. Every word earns its place, with no redundancy or 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?

Given the tool's low complexity, fully annotated safety profile, complete parameter schema, and presence of an output schema, the description is sufficient. It covers both encode and decode modes and the byte-exact guarantee, leaving no critical information 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?

Schema description coverage is 100%, with both parameters already well-documented (mode enum meanings and text purpose). The description does not add parameter-specific details beyond 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 explicitly states the tool's action ('Encode text to Base64 or decode Base64 to text') with a specific resource and operation. It clearly distinguishes itself from siblings like url_encode by naming the exact Base64 format, and adds the byte-exact guarantee to the 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?

The description gives clear context for when to use the tool: whenever Base64 encoding or decoding is required. It does not explicitly name alternatives or exclusions, but the tool's purpose is so unambiguous that an agent can easily select it over siblings without additional 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral details beyond annotations: it returns exact net, VAT, and gross amounts and rounds to cents, which is the key behavioral trait an agent needs to know.

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

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

Two tight sentences: the first states the dual operation and rate flexibility, the second states the output and rounding. There is no repetition, filler, or redundant details, and the most important information is front-loaded.

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

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

For a simple calculator with a complete input schema and an output schema, the description covers everything an agent needs: the two possible operations, the rate domain, and the exact return contents with rounding. No missing behavioral or usage aspect is material enough to warrant a lower score.

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 description is not required to explain the parameters. It does add a minor semantic link by mentioning 'net amount' and 'gross amount', but this is already captured in the mode enum descriptions, so no significant value beyond the schema is provided.

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 specific verbs ('Add VAT', 'extract VAT') against concrete resources ('net amount', 'gross amount'), making the operation immediately clear. It also implicitly distinguishes itself from sibling tool check_vat_number_format by being a calculation tool rather than a validation tool.

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

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

The two modes ('add' and 'extract') give explicit situational context for how to invoke the tool, and 'at any rate' clarifies the tool's flexibility. It does not name specific alternatives or when-not-to-use conditions, but for a simple deterministic calculator this is acceptable.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safe/idempotent nature is covered. The description adds valuable behavioral context: it validates syntax only, performs no VIES lookup, and restricts support to the listed country prefixes.

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, stating the core purpose in the first sentence. The country prefix list is the only longer section, but it is necessary and each item provides direct functional 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?

For a single-parameter, read-only, idempotent validation tool with an output schema present, the description covers the key aspects an agent needs: what the tool does, what it does not do, and which values are accepted. Nothing essential 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 provides the parameter name, type, max length, and an example, so schema coverage is complete. The description adds semantic value beyond this by enumerating the accepted country prefixes, which clarifies the allowable value space for the vatNumber parameter.

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

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

The description uses a specific verb-resource pair ('Check the format of an EU/GB/CH VAT number') and clearly scopes the operation to syntax only, explicitly excluding VIES registration lookup. It also lists the supported country prefixes, making the tool easy to distinguish from sibling validation 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 clear context by stating this is a format-only check and not a registration lookup, which tells the agent what it should and should not be used for. It does not name a specific alternative tool, but the boundaries are explicit enough for correct 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?

Annotations already provide readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds 'exact math', which suggests deterministic, precise conversions, and lists the supported formats. However, it does not mention edge cases, invalid inputs, or the return structure, though the output schema partially covers that.

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: 'Convert a CSS color between HEX, RGB, HSL, and HSB with exact math.' Every word earns its place, with no redundancy or filler.

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

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

For a one-parameter utility with an output schema, the description covers the key conversion scope and supported formats. The only minor ambiguity is the phrase 'between', which could imply a target selector, but the single-parameter schema and output schema make the behavior discoverable. Overall, sufficient for an agent to select and invoke the 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?

The schema covers 100% of the single parameter 'color' with an example, but only mentions HEX and RGB. The description expands this by naming HSL and HSB as well, giving the agent a fuller understanding of accepted input formats. This adds meaningful value 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?

The description uses the specific verb 'Convert' and names the exact resource ('CSS color') plus the supported formats ('HEX, RGB, HSL, and HSB'). This clearly distinguishes it from sibling tools like image_convert, which handle image file conversions, making the tool's purpose 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 implies that the tool is used for converting CSS colors, but it does not explicitly state when to use it versus alternatives or when not to use it. Sibling tools such as image_convert exist, but there is no direct comparison or route-finding 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 cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds that counts are exact and includes reading time. However, it does not disclose how reading time is calculated or define boundaries for sentences/paragraphs, which would add value.

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 13-word sentence that is front-loaded with the core outputs and avoids redundancy. Every word contributes meaning.

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 complexity is low, and an output schema exists to describe the return structure. The description lists all major outputs, but omits minor behavioral details like reading-time assumptions and paragraph definition. These are not critical for correct invocation.

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

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

Schema coverage is 100%, so the schema already fully documents the text parameter. The description repeats the 'text' scope but adds no further parameter-level detail such as encoding, language handling, or whitespace behavior.

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 specifies the resource (text) and the exact outputs: word, character, sentence, paragraph counts plus reading time. This is a distinct utility among siblings like text_diff or generate_slug, so an agent can immediately understand 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?

The description implies use for obtaining text statistics but provides no explicit when-to-use guidance or alternatives. While the tool is self-explanatory, it does not state exclusions or compare to related text-processing siblings.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations by disclosing delimiter auto-detection and quoted-field handling, which are important parsing behaviors an agent would otherwise not know.

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

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

The description is a single concise sentence that front-loads the core action ('Parse CSV data into JSON') and appends the two distinguishing details. No filler or redundant information is present.

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 annotations covering readOnly/idempotent behavior, the description plus structured data provides a complete picture for most usage. Minor missing context includes how malformed CSV is handled or behavior when firstRowHeaders is false, but these are not critical for correct invocation.

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

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

Schema description coverage is 100%: both the 'csv' and 'firstRowHeaders' parameters are documented in the schema. The description adds only the 'quoted-field handling' detail, which is helpful but not essential to parameter understanding, 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 ('Parse') and resource ('CSV data into JSON'), and adds distinctive details ('delimiter auto-detection and quoted-field handling') that clearly differentiate it from sibling conversion tools. An agent immediately understands what this tool does.

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

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

The description implies the tool should be used when CSV data needs to be converted to JSON, especially when delimiters are unknown or quoted fields are involved. However, it provides no explicit guidance about when to prefer alternatives or when not to use the 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 establish that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by stating results are exact and cover movable feasts and King's Day rules, which is meaningful beyond 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 two sentences with no filler. The core purpose is front-loaded, followed by important rule specifics and a clear usage recommendation.

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 tool with an output schema present, the description is complete. It covers the main holiday edge cases an agent would worry about and the schema handles the year bounds.

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 fully describes the only parameter, year, including its valid range of 1900 to 2200. The description adds only 'for a year', which does not meaningfully extend the schema's documentation, so the 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 clearly identifies the resource (Dutch public holidays) and scope (a year), and highlights key specifics like movable feasts and King's Day rules. It lacks an explicit main verb like 'returns' or 'gets', but the intent is unmistakable and distinguishes it from 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 phrase 'Use this instead of computing Dutch holidays yourself' explicitly tells agents when to use the tool and discourages manual implementation. It does not name sibling alternatives, but no sibling directly duplicates this holiday lookup.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds value by specifying behavior beyond those: validation with 'a real parser' and the return shape ('formatted JSON or the exact parse error'). This gives the agent useful expectations about both success and failure modes.

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 that front-load the core purpose and then state the return behavior. There is no redundant information, and every sentence contributes meaningful guidance.

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, side-effect-free formatting tool, the description, combined with annotations and output schema, is complete. It covers purpose, behavior, success and error output, and the annotations handle safety and idempotency concerns.

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 input schema already fully documents both parameters. The description does not add parameter-level detail beyond the schema, which meets the baseline for high coverage but adds no extra semantic 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 states a specific verb and resource: 'Validate and pretty-print JSON with a real parser.' It is further differentiated by mentioning 'Returns formatted JSON or the exact parse error,' which clearly distinguishes it from generic or approximate formatters.

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 JSON needs validation or pretty-printing. It does not explicitly name alternatives or exclusions, and no sibling tool competes directly with this function, but the usage context is still clear enough for an agent to select it appropriately.

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 useful behavioral context beyond the annotations: deterministic output per seed and BSNs that pass elfproef validation. The annotations already cover read-only and idempotent behavior, so the description does not need to repeat those, but it does enhance understanding of what the generated data will be like.

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

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

The description is concise: three sentences, front-loaded with the core function, followed by rationale and scale limitations. Every sentence contributes useful decision-making information with no filler.

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

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

The tool has 7 parameters and a nested lifeEvents object, but the schema covers 100% of parameter semantics and an output schema is present. The description fills the remaining gaps: domain validity, determinism, and the boundary for when to switch to the REST API. This is complete for selection and correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some high-level context about seeds and life events, but it does not need to repeat parameter-level details because the schema already documents each field 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 states a specific verb ('Generate') and a precise resource ('Dutch BRP/GBA test persons with valid BSNs, families, addresses and life events'). This clearly differentiates the tool from generic data generators and from the sibling generate_test_bsn, which focuses only on BSNs.

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 says to use this tool instead of inventing Dutch personal data because made-up BSNs fail the elfproef check. It also names an alternative path for larger or CSV needs: the REST API. This is clear when-to-use and 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral guarantees: deterministic handling of unicode and diacritics and a URL-safe output format. It does not mention edge cases like empty input or output truncation, but these are minor given 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?

A single concise sentence that states the core function and key behavioral guarantees without any filler. The information is front-loaded and directly useful.

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 function with one required parameter, complete schema coverage, a provided output schema, and comprehensive annotations, the description is sufficient. An agent has everything needed 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?

Schema description coverage is 100% and the input schema already documents text as 'The title or phrase to turn into a URL slug.' The description adds general algorithmic context but no additional parameter-level meaning beyond what the schema provides.

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

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

The description states a specific verb and resource: convert text into a URL-safe slug. It also adds differentiating detail by mentioning unicode and diacritic handling, which helps distinguish it from sibling tools like url_encode or test_regex.

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 tool is for turning text into URL-safe slugs, which gives an agent a clear context for when to use it. However, it does not explicitly name alternatives or state when not to use 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 and destructiveHint=false, so safety is covered. The description adds meaningful behavioral detail beyond annotations by explaining that generated BSNs pass the elfproef yet are not tied to real people, which is essential for an agent deciding to use the output.

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 validity constraint are front-loaded, and the usage restriction is included without extra 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 simple, has one optional parameter, an output schema, and annotations covering read-only and non-destructive behavior. The description fully covers what the output represents and the intended use case, so an agent has enough context 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?

The only parameter, count, is fully documented in the schema with type, range, default, and description, so schema coverage is 100%. The tool description does not repeat parameter details, which is acceptable because the schema already carries the 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 uses a specific verb and resource: 'Generate Dutch BSN test numbers'. It also adds the key constraint that the numbers 'pass the elfproef (11-check) but belong to no real person', which clearly separates it from sibling tools like generate_test_iban and generate_brp_test_data.

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 states the intended context: 'For development and test data only.' This gives clear usage context and implicitly warns against production use, though it does not explicitly name alternatives or state when not to use this tool relative to specific siblings.

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

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

Annotations already convey read-only and non-destructive behavior. The description adds meaningful context beyond that: generated IBANs are not real bank accounts, include correct mod-97 check digits, and for BE/FR include the national check digit, making them safe and valid for test usage.

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 focused sentences cover action, scope, validation guarantees, and intended use. The most important facts are front-loaded and there is no redundant text.

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

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

For a simple generator with two optional parameters, full output schema, and annotations that already document side effects, the description gives the agent everything needed: purpose, supported countries, validity guarantees, and the development/test-only boundary.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the country list but adds no parameter-level details beyond what the schema already documents for count and country.

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 'generate' and resource 'test IBANs', enumerates supported countries, and distinguishes it from validation tools by noting the IBANs belong to no real bank account and pass validate_iban. This clearly separates it from siblings like validate_iban.

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?

Explicitly scopes the tool to 'development and test data only' and clarifies it produces data that passes validate_iban in full. It does not name alternatives, but the test-data restriction and supported-country list give clear usage context.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context on top: determinism per seed and the large size of XML output. It does not describe rate limits or error behavior, but the output schema and annotations reduce the burden; the added context is useful and consistent.

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

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

The description is three sentences with no filler: the first states core purpose and scope, the second adds determinism, and the third gives practical format and bulk-use guidance. It is front-loaded with the most important information and every sentence earns its place.

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

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

Given the tool's 8 parameters, nested defects object, and full schema descriptions plus an output schema, the description is complete enough for an agent to select and invoke it correctly. It adds the essential real-world constraints—summary vs XML size and bulk API alternative—that are not inferable from the schema alone.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add much parameter-level meaning beyond what the schema already provides for seed, count, format, months, defects, startYear, schemeType, and startMonth. It reinforces the format guidance and mentions deliberate defects, but the schema is already doing the heavy lifting.

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

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

The description names a specific verb (Generate), a specific resource (UPA pension declaration XML), and the domain (Dutch payroll-to-pension-fund message), making it clearly distinct from sibling generator tools like generate_brp_test_data or generate_test_bsn. It also adds key detail about deliberate defects and determinism, leaving no ambiguity about 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 explicitly guides format selection: 'ask for the summary format unless you need the file contents' and warns that XML can be very large. It also names an external alternative for bulk use, the REST API, which is a clear when-not-to-use-this-tool instruction. This is strong, actionable guidance beyond what the schema provides.

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 useful behavioral context beyond the readOnlyHint annotation by specifying cryptographically random UUID v4 generation, which implies each call produces new, unpredictable values. It is consistent with the annotations and no contradictions 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 a single focused sentence with no filler. It front-loads the action and result, making it immediately scannable for an agent.

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 utility with a full input schema, an output schema, and safety annotations, the description is complete. An agent has everything needed to select and invoke the tool correctly without further clarification.

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 full coverage of the single count parameter, including default, range, and description, so the description adds little beyond saying UUIDs are generated. 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 gives a specific verb and resource: it generates cryptographically random UUID v4 values. It clearly differentiates itself from sibling generation tools like generate_slug and generate_test_bsn by naming the exact output format.

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 clearly by the description, but there is no explicit guidance about when to use this tool versus alternatives or when not to use it. No sibling comparison or exclusion criteria are mentioned.

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 empty annotations by disclosing authentication requirements (Bearer tf_...), rate limits (3 free renders/day), pricing (25 units per render), and the output behavior (hosted URL valid for 24 hours). It also explains rendering fidelity (full CSS support, print backgrounds), giving the agent a clear behavioral model.

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

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

Three sentences deliver purpose, output characteristics, and pricing/auth in a front-loaded, organized way. Every sentence earns its place; there is no filler or repetition of schema content.

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 annotations are all false/neutral and the schema is thorough, the description provides the essential extras: output URL validity, authentication, rate limits, and cost. An agent has everything it needs to decide whether to call the tool and what to expect from the response.

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 covers 100% of the parameters with descriptions and enums, so the description does not need to repeat parameter details. The description adds context about rendering quality but does not add new meaning to the parameters themselves. This matches 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 clearly states a specific verb ('Render') and resource ('HTML document to a real PDF'), and adds meaningful detail about headless Chrome, full CSS support, and print backgrounds. This makes it easy to distinguish from siblings like url_to_pdf or images_to_pdf based on input type.

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

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

The description implies when to use the tool: when you have an HTML document that needs PDF rendering. However, it does not explicitly mention alternatives or when not to use it, such as pointing out that url_to_pdf is for URLs or images_to_pdf for image inputs. This leaves usage guidance 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?

The description carries the full behavioral burden since no annotations are provided. It discloses the JPEG re-encoding behavior, the 24-hour expiry of the hosted download URL, the 3-renders/day demo limit, the API key authorization format (Bearer tf_...), and the 25 units per render cost. This is rich, transparent operational detail beyond what a schema could convey.

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-loaded with the core action and parameters, followed by output expiration and cost details. Every sentence adds distinct, necessary information with zero 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 no output schema and no annotations, the description covers all essential context: input requirements, output format, URL expiration, auth mechanism, rate limits, and cost. Nothing an agent needs to invoke the tool correctly is missing.

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

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

The input schema already documents both parameters with descriptions, giving a baseline of 3. The description adds valuable constraints not in the schema, notably the 15MB source size limit and the effect of quality on the re-encoding process, thereby enhancing parameter interpretation.

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

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

The description clearly states the tool's function with a specific verb ('Re-encode') and resource ('an image (public URL, max 15MB)'), and specifies the output format (JPEG) and purpose ('to shrink it'). This distinguishes it from sibling tools like image_convert or image_resize, which have different transformation intents.

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

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

The description provides clear context for usage: it requires a public URL, has a 15MB limit, a quality range of 1-100 with default 70, and explains the demo vs. API key options. It does not explicitly compare with alternatives or state exclusions, but the input constraints and output characteristics give an agent enough guidance to decide when this tool applies.

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?

Goes well beyond the annotations by disclosing the 15MB input cap, 24-hour hosted download URL validity, free demo quota of 3 renders/day, API key authentication format, and 25-unit cost per render. No contradiction with readOnlyHint=false, openWorldHint=true, or other annotations.

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

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

Three focused sentences with no filler. Each sentence delivers essential operational information: input scope and output behavior, download URL lifetime, and quota/auth/cost details.

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 and annotations, the description covers inputs, constraints, output URL behavior, rate limits, authentication, and pricing. Nothing essential is missing 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?

Schema already covers both parameters with descriptions and an enum for format. The description adds valuable URL-specific constraints ('public URL, max 15MB') and reinforces the target format list, enriching the parameter meaning beyond the schema alone.

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: converting an image to another format, names the five supported target formats, and adds the scope constraint 'pixels unchanged'. This clearly distinguishes it from sibling tools like image_resize and image_compress.

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: use for format conversion of a public image URL with pixel preservation. It does not explicitly name alternatives or give when-not-to-use instructions, but the 'pixels unchanged' phrase implicitly excludes resizing and compression use cases.

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

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

Annotations are sparse (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description carries the behavioral burden. It discloses source limitations (public URL, 15MB), output type (PNG), link expiration (24 hours), and rate/cost details (3 renders/day free, 25 units per render with API key). It does not disclose failure behavior for oversized images or invalid URLs, but it covers the main operational traits beyond 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 three sentences, each earning its place: first defines the operation and output, second explains dimension semantics, third covers auth/cost/limits. It is front-loaded with the core action and constraints, and the cost/API details are cleanly appended. No fluff or repetition of the schema.

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

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

For a 3-parameter tool with complete schema coverage and a clear output type, the description covers the essential usage contract: input constraints, dimension semantics, output format, link expiry, and cost model. The sibling list shows many conversion tools, but the description is specific enough to avoid confusion. Minor gaps like explicit error cases and why openWorldHint=true are present but not critical.

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 fully documents url, width, and height with bounds and descriptions. The description adds the aspect-ratio rule ('one side keeps the aspect ratio') and the 'give width, height, or both' flexibility, which is genuinely useful. However, since schema coverage is complete, the baseline is 3 and the description's added meaning is moderate rather than extensive.

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 verb ('Resize'), the resource (an image via public URL), and the key constraints (max 15MB, returns PNG). It distinguishes itself from sibling utilities like image_compress and image_convert by specifying a hosted download URL output and 24-hour validity. An agent can confidently select this tool over the many image/file 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 provides clear guidance on parameters: supply width, height, or both, with aspect ratio behavior when one side is given. It also gives explicit authentication context (free vs. API key) and a cost rate. It doesn't explicitly name alternatives like image_compress or image_convert, but the sibling list makes this tool's purpose distinct enough. It lacks an explicit when-not-to-use statement, but the context is strong.

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 only indicate readOnly=false, destructive=false, and idempotent=false; the description adds substantial operational context: 1-20 images, 15MB max per image, one image per page, 24-hour download URL, demo rate limit, required Authorization header format, and unit cost. This goes well 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 dense but every sentence earns its place: core function, output deliverable, and auth/quota constraints are each covered in a single sentence. Information is front-loaded with the main action before operational details.

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 details: input count and type, size limit, page order, output URL expiry, authentication method, and rate/cost limits. An agent has enough to decide and call this tool correctly without additional documentation.

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 urls parameter already describes public JPEG/PNG URLs in page order. The description adds extra semantic value by specifying the 15MB per-image cap, page ordering behavior, and the 'one image per page' output format.

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

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

The description names a specific verb and resource: 'Combine 1-20 images ... into one PDF.' It also states the per-page behavior and output type, clearly distinguishing this from siblings like pdf_merge, html_to_pdf, and 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 gives clear context for when the tool is appropriate: combining public JPEG/PNG image URLs into a single PDF. It does not explicitly name alternative tools or state when not to use it, but the limits and input format make 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?

The word 'deterministically' discloses a behavioral guarantee—same input yields same output—that is not captured by the readOnly/idempotent/destructive annotations. It does not contradict any annotation and adds useful confidence for retries or caching.

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

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

The description is a single concise sentence with no filler. It front-loads the action and object, and 'deterministically' earns its place by adding behavioral 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 one-parameter pure transformation with full schema coverage, an output schema, and annotations declaring safety, the description is sufficient. Nothing critical for an agent to invoke it correctly is missing.

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

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

Schema coverage is 100% because the only parameter, 'markdown', is described as 'The Markdown text to convert'. The description adds no additional parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Convert') and names both source and target resources ('Markdown to HTML'), making the action unmistakable. The determinism qualifier adds precision, and no sibling tool overlaps with this markdown-specific 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 description makes the general use case clear, but it gives no explicit guidance about when to choose this tool over alternatives or when not to use it. The use case is implied by the name and description rather than stated as 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 indicate destructive and idempotent behavior, and the description adds useful context about the API key quota and privacy implications. It does not describe what happens when the key does not exist, but the annotation coverage lowers the burden and the provided auth context is valuable.

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

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

The description is three sentences with no filler. The core action is front-loaded, the quota rationale justifies the cleanup use case, and the auth requirement is included as a necessary operational detail without excessive length.

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 delete tool, the description covers purpose, when to use it, and the required authorization. The presence of an output schema and annotations covers return behavior and safety, so nothing essential 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 fully documents the single 'key' parameter with 'The key to delete,' and the description does not add extra parameter-level detail beyond that. With 100% schema description 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 'Delete a stored key,' a specific verb and resource that clearly states what the tool does. The title 'Forget a value' reinforces this and the sibling context with memory_get, memory_list, and memory_set makes the delete operation 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 gives concrete guidance: use it to clean up entries you no longer need, with the added rationale that each API key has a quota. It does not explicitly contrast with alternatives like memory_set or memory_get, but the use case is clear and actionable.

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 meaningful behavior beyond that: it returns null for missing keys, requires a free API key, and clarifies that values are private to that API key yet shareable across sessions using the same key. This is exactly the kind of extra context 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 two sentences long with no filler. It front-loads the core action, documents the null behavior, and then covers the authentication/privacy requirement. Every sentence contributes necessary 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 tool with one parameter, an output schema, and a clear read-only safety profile, the description covers all essential operational aspects. It explains what happens when the key is missing, which is the most common failure mode, and it documents the required auth context. There are no significant gaps.

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

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

The schema already describes the single key parameter at 100% coverage, including its string type and maxLength. The description adds that the key refers to a value stored earlier with memory_set, but this is light value on top of the schema. A baseline of 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 clearly identifies the tool as retrieving a value previously stored via memory_set, using a specific key. It distinguishes this read operation from the write tool memory_set and from memory_list/memory_delete by focusing on exact key-based recall. The scope limitation to the same API key adds useful precision.

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

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

The description implies the tool should be used after memory_set and for retrieving a specific stored value. It also notes the API key requirement and cross-session visibility. However, it does not explicitly compare against siblings like memory_list or memory_delete, so an agent must infer when this tool is preferable.

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 operation safe (readOnly, idempotent, non-destructive). The description adds meaningful behavioral context: sort order, filtered listing, returns keys and sizes rather than values, and the API-key requirement with a link. This goes beyond what annotations or schema convey.

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: action and core behavior first, then usage guidance, then return contents, then auth. Every sentence adds value without repetition or 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 simple list tool with a full output schema and complete annotations, the description covers all essential context: what the tool returns, how to use it, auth requirements, and how it fits into the workflow. Nothing important 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 parameters are already well documented. The description adds only a small semantic nuance by mentioning 'optionally filtered by prefix' and the ordering, but it does not materially extend the schema's parameter documentation.

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 ('List'), the exact resource ('keys you have stored'), an ordering guarantee ('newest first'), and an optional filter ('prefix'). The phrase 'not values' further distinguishes it from memory_get, and the title aligns with the description.

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?

Explicitly tells the agent when to use this tool: 'discover what a previous session left behind before deciding what to read.' It implies the alternative (use memory_get for reading values) by stating this returns keys and sizes, not values, though it does not name the sibling directly.

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

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

It discloses that the tool requires a free API key and that entries are private to the caller, which is useful operational context beyond the annotations. The annotation set already marks the operation as idempotent and destructive, so the description is not required to repeat overwrite semantics; it also adds the cross-session behavior. 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 short and front-loaded with the primary action and persistence guarantee. The 'Without it...' sentence is slightly motivational, but the overall length is still appropriate and every sentence adds either behavior or auth context.

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

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

For a simple two-parameter write tool with a full input schema and an output schema present, the description covers the key facts: what is stored, why to use it, how long it lasts, and the required authentication. The only notable omission is explicit overwrite behavior, but the destructiveHint annotation covers that signal.

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 both parameters are described in the schema (key as identifier with namespacing, value as a JSON-serialised string). The description only restates 'under a key' without adding parameter details, so the schema is doing the work; baseline 3 applies.

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

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

The description states a specific verb and resource ('Store a value under a key') and adds the key behavior of cross-session persistence ('read it back in a LATER session'). It is clearly differentiated from sibling tools like memory_get, memory_delete, and memory_list by focusing on the write side of the memory API.

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 provides explicit use context: remember anything worth keeping, with concrete examples (processed items, running list, decision, intermediate results), and motivates persistent storage ('Without it, everything you learn is lost'). It does not explicitly list exclusions or contrast with memory_delete/list, but those are not competing operations for writing a value, so the guidance 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 disclose read-only, idempotent, and non-destructive behavior. The description adds meaningful context by specifying the two outputs (human-readable description and next scheduled run times) and claiming 'exact cron semantics.' This goes beyond the structural metadata, though it does not detail edge cases like timezone 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 concise sentences that front-load the core purpose and output, then add a usage directive. Every sentence earns its place with no redundant 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?

With a single well-documented parameter, rich annotations, and an output schema provided, the description covers everything an agent needs to invoke the tool correctly. The tool is simple enough that no additional context 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?

The input schema provides 100% coverage for the single 'expression' parameter, including a type, maxLength, and an example. The description does not add anything beyond 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 states a specific verb ('Parse'), a specific resource ('a cron expression'), and the exact output ('a human-readable description and the next scheduled run times'). This clearly distinguishes parse_cron from all sibling tools, none of which perform cron parsing, and reinforces that it is the authoritative parser.

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 an explicit directive: 'use this instead of interpreting cron syntax yourself,' which tells the agent when to delegate parsing rather than implementing it. It does not name alternative tools, but no sibling overlaps with cron parsing, so the guideline 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds an important behavioral directive beyond annotations: 'Do not log or store the password,' which is critical privacy context for handling sensitive input.

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 first sentence states the core function and method, and the second provides the essential privacy constraint. Information is front-loaded and every sentence earns its place.

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

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

Given a single required parameter, full schema coverage, an output schema, and annotations covering safety, the description is complete. The privacy warning addresses the main risk of this tool, and return details are covered by the output schema.

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

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

Schema coverage is 100%, and the schema already explains that the password is analyzed in memory and not stored. The description adds no significant parameter-level detail, but the schema carries the necessary semantics, so a baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Analyze'), a clear resource ('password strength'), and a defined method ('entropy-based scoring and concrete feedback'). It is distinct from all sibling tools, none of which analyze 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 description makes the tool's purpose clear enough that an agent knows when to select it: whenever password strength analysis is requested. No explicit exclusions or alternatives are provided, but no sibling tool overlaps functionality, so this is acceptable.

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 discloses important behavioral details: the output is a hosted download URL valid for 24 hours, the free demo is capped at 3 renders/day, and API-key usage costs 25 units per render. This gives the agent a realistic picture of side effects, rate limits, and authentication 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?

The description is compact, front-loaded with the core operation and constraints, and contains no filler. Every clause adds useful information: input requirements, count/size limits, output lifetime, demo limit, and API-key usage.

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, this description is comprehensive. It covers input constraints, authentication, rate limiting, cost, and the output contract. Nothing essential for an agent to decide whether and how to invoke this tool 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 the 'urls' array, min/max items, and merge order, so the baseline is 3. The description adds the important runtime constraint that each PDF must be a public URL and at most 10MB, which is not present in the schema and materially affects invocation accuracy.

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

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

The description uses a specific verb and resource: 'Merge 2-10 PDFs ... into one PDF.' It clearly separates this from sibling tools like pdf_split and images_to_pdf by emphasizing public URLs, count limits, and a single merged output.

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 conditions for use: merging 2 to 10 PDFs from public URLs, with size limits, and explains the demo versus API-key paths. It does not explicitly name alternative tools or state when not to use it, so it stops 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?

The description goes well beyond the sparse annotations by disclosing output behavior (hosted download URL valid 24 hours), rate limits (3 free renders/day), and authentication/billing (Bearer TF_... key, 25 units per render). These are exactly the cost and side-effect details an agent needs beyond the annotations.

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

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

Three sentences, each earning its place: the first gives the core operation and constraints, the second explains default behavior and output, and the third covers auth and billing. 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 PDF-splitting tool, the description covers input requirements, defaults, output URL lifetime, rate limits, and cost model. With an output schema present, return-value details are already structurally documented, so nothing critical is missing for selecting and 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 coverage is 100% and each parameter already has a clear description. The description adds the max 10MB source URL limit, which is new and useful, but otherwise repeats the 'to' default and 1-indexed/inclusive semantics already present in the schema. This matches 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 states a specific action ('Extract a 1-indexed, inclusive page range from a PDF ... into a new PDF') with clear resource and scope. This distinguishes it from siblings like pdf_merge and images_to_pdf, which handle different PDF operations.

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

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

The description provides clear context: use it when you need to split a PDF by extracting a page range. It also specifies important preconditions (public URL, max 10MB, default behavior of 'to'). However, it does not explicitly name alternative tools or exclusion conditions, so it falls just short of full guidance.

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

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

The description goes well beyond the basic annotations by disclosing that it returns a 24-hour-hosted URL, imposes a 3-renders/day free demo limit, and costs 25 units per render with authentication. These are critical behavioral traits not present in 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 compact and front-loaded: the core function and output type appear first, followed by usage limits and pricing. Each sentence delivers distinct, necessary information without redundancy.

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

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

For a tool with only two parameters, no meaningful annotations, and an output schema, the description covers all essential operational details: output format, URL validity, demo limit, authentication, and cost. Nothing critical is missing for an agent to use it correctly.

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

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

Schema coverage is 100%, and both parameters (text and size) are already well-described in the input schema. The description does not add extra parameter-level meaning, 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 states a specific verb and resource: 'Generate a QR code as a downloadable PNG image.' It clearly distinguishes the tool from all sibling image-processing tools, which do not generate QR codes, and adds the key output detail (hosted download URL).

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 usage context: free demo limits (3 renders/day), API key requirements, and per-render cost. It does not explicitly name alternatives, but no sibling tool serves the same QR-code generation purpose, so the omission is acceptable.

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, and the description adds meaningful behavioral detail: JavaScript is executed, navigation and cookie banners are stripped, and it returns title, description, content, and links. It also discloses rate limits and required API key authorization, which is valuable context not present in 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 front-loaded with the core purpose, then gives a concrete use case, then the output shape, and finally authentication/pricing details. It is more detailed than minimal, but pricing and rate-limit information is genuinely useful for an agent deciding whether to invoke the tool.

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

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

Given the tool's moderate complexity and the presence of an output schema and annotations, the description is reasonably complete. It covers when to use it, what behavior to expect, what is returned, and auth requirements. It does not mention potential failures or timeouts, but the provided context is strong enough 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?

Schema description coverage is 100%, so the schema already fully documents the url, format, and maxChars parameters. The description reinforces that output can be clean text or Markdown, but it does not add significant new parameter-level meaning beyond what the schema provides. 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 clearly states the tool reads a web page as clean text or Markdown and explicitly calls out JavaScript execution, which is the defining behavior that separates it from plain fetching or other URL-based tools. It also names the output elements (title, description, readable content, links), making the tool's resource and result 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 explicit when-to-use guidance: use this when a plain fetch returns an empty shell or loading spinner for single-page apps, dashboards, and client-side rendered sites. It does not explicitly name sibling alternatives or state when not to use it, but the use case is clearly scoped.

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 indicate readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by emphasizing that it uses a real JavaScript regex engine and returns all matches including capture groups and indices, which goes 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 two sentences with no filler. It front-loads the core action, specifies the engine, and immediately follows with the return value. Every clause earns its place.

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

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

The description is complete for a simple read-only utility. The input schema documents all parameters, the output schema exists, and the annotations cover side-effect risks. Nothing essential for an agent to select and invoke the tool correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description does not add new meaning about parameter formatting, flags syntax, or edge cases, but it does not need to because the schema carries the full burden. 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 uses a specific verb and resource: 'Run a JavaScript regular expression against a test string.' It also states the concrete output: 'Returns all matches with capture groups and indices.' This clearly distinguishes the tool from the other utility siblings and removes ambiguity about what it does.

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 that this tool is for testing regex behavior against a string, so an agent can infer when to use it. It does not explicitly name alternatives or exclusion cases, but none of the sibling tools overlap with regex testing, so the usage context is sufficiently 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?

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds behavioral specificity beyond that: the comparison is exact and line-based rather than character-based or fuzzy, and it reports add/remove/unchanged categories.

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. It states the operation, the input relationship, the algorithm granularity, and the output stats in under fifteen 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?

For a simple two-string tool with full schema documentation, an output schema, and safety annotations, the description covers everything an agent needs to select and invoke it correctly. No critical behavioral or usage context 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 coverage is 100%, with clear descriptions for 'original' and 'modified' as before/after texts. The description does not add parameter-level detail, but the schema already carries the semantic weight, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Compute') and identifies the resource and method: an exact line-based diff between two texts. It also names the result dimension (add/remove/unchanged stats), which clearly distinguishes it from the text-formatting and conversion 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 clearly implies the tool is for comparing two text versions to obtain line-level changes. No sibling tool offers diff functionality, so explicit alternatives are unnecessary; there are no exclusions or competing use cases 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds only the qualifier 'exact percent-encoding,' which gives a hint of precision but does not detail encoding edge cases, decode failures, or Unicode 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 one concise sentence with the core operation front-loaded and no filler. 'With exact percent-encoding' adds meaningful precision without bloating the text.

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

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

For a simple two-parameter utility with strong annotations and an output schema, the description is largely sufficient. It does not discuss edge cases or alternative usage, but those are not critical for basic invocation.

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

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

Schema description coverage is 100%, so the schema documents both parameters thoroughly. The description adds no extra parameter semantics beyond restating that the tool encodes or decodes a string.

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: URL-encode or decode a string with exact percent-encoding. It is clear and distinguishes the operation from unrelated siblings, though it does not explicitly differentiate it from similar encoders like base64.

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. Sibling tools like base64 and generate_slug are not mentioned, and no conditions or exclusions are provided.

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 discloses important behaviors: headless Chrome rendering, hosted download URL with 24-hour validity, demo render limits, required Authorization header format, and unit cost per render. This gives the agent actionable knowledge about side effects and constraints.

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 tightly written in four sentences, each providing essential information: what it does, what it returns, demo limitations, and authentication/cost. No filler or redundant content is present.

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 annotations and full schema, the description covers all critical invocation context: URL requirements, output format, response lifetime, authentication, availability, and pricing. An agent can select and call this tool without missing key prerequisites.

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 fully documents url, width, and fullPage. The description only restates that the URL must be public and http(s), adding no new parameter-level meaning 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?

The description opens with a specific verb and resource: 'Take a PNG screenshot of a public web page with headless Chrome.' This clearly differentiates the tool from siblings like url_to_pdf and read_page by naming output format and capture method.

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 clearly states the tool is for public web pages and gives context about demo limits and API key usage. It does not explicitly name sibling alternatives 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?

Beyond the annotations, the description discloses crucial runtime behavior: output is a hosted download URL valid for 24 hours, free demo is limited to 3 renders/day, API key auth is required for paid usage, and each render costs 25 units. This covers auth, rate limits, and billing side effects, exactly the context the annotation block does not 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 two sentences are tight and information-dense, covering the core operation and output. The final sentence packs auth, demo limits, and unit cost into one long clause, which is relevant but slightly awkward and dense; otherwise there is no wasted text.

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

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

For a 3-parameter tool with an output schema, the description provides the essential behavioral contract: public URL input, hosted PDF output, 24-hour validity, and cost/auth conditions. It does not mention when to prefer a sibling such as html_to_pdf, but that is a usage-guidelines shortfall rather than a completeness gap for invoking this tool correctly.

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

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

Schema description coverage is 100%, and the schema already documents url, format, and landscape with defaults and enums. The description adds no parameter-level detail, so it stays at the baseline 3 rather than earning extra credit.

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 action-resource pair: 'Render a public web page to PDF with headless Chrome.' It clearly distinguishes this from sibling tools like html_to_pdf and images_to_pdf by emphasizing 'public web page' and 'URL'. The title and tool name reinforce the same target.

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 'public web page' sets an explicit precondition and tells the agent it cannot render private/local content. It does not name alternative tools or explicitly say 'use html_to_pdf instead for HTML strings', so it stops short of a full when/when-not, but the context is clear enough.

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 as read-only, idempotent, and non-destructive. The description adds useful behavioral context by clarifying that validation covers syntax and common typos, which implies a local, deterministic check rather than 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?

The description is a single compact sentence that front-loads the core purpose and uses a concrete example ('gmial.com') to illustrate the typo-detection behavior. 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 simple single-parameter, read-only validator with an output schema, the description covers the relevant behavior and input requirements sufficiently. The only potential omission is a note about not checking mailbox existence, but this is reasonably implied by emphasizing 'syntax' and 'typos'.

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 'email' parameter with a clear description, so schema coverage is 100%. The tool description adds no additional parameter-level information, 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 ('validate'), a specific resource ('email address'), and adds a concrete secondary behavior ('detect common domain typos'). This makes the tool's purpose unmistakable and clearly distinguishes it from siblings like validate_iban.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The usage context is implied through the clear purpose, but an agent must infer when this tool is the right choice.

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 idempotent, and the description adds substantial behavioral detail: the national check digit handling for twelve countries, the meaning of absent nationalCheck, Dutch bank-code naming behavior, territory prefix behavior, and the limitation that a valid IBAN can still reference a nonexistent bank code. It goes far beyond the annotations 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?

Although the description is long, it is front-loaded with the core purpose and every sentence adds genuinely useful edge-case information. No filler or repetition is present, and the flow moves from basic checks to limitations to special cases to call-to-action.

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

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

The description is complete for a tool of this complexity. It explains what the tool returns, what the return values mean in ambiguous cases, how nationalCheck should be interpreted, and what the tool does not guarantee. The presence of an output schema further reduces the need to describe exact return fields, so nothing essential 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 already provides 100% coverage for the single parameter, 'iban', so the baseline is 3. The description adds meaningful context about what the input undergoes—length checks, character checks, mod-97 checksum, and national check-digit verification—so it does add value 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?

The description uses a specific verb and resource: 'Check whether an IBAN is well formed' and enumerates the exact checks performed (mod-97, country code, length, character positions). It clearly distinguishes itself from sibling tools by framing the result as a format check, not a bank or account validity check.

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 usage direction: 'Never guess whether an IBAN is well formed: use this tool.' It also states when the tool should not be over-interpreted, saying a pass is not confirmation that money can be sent and that this is not a bank check, which effectively defines exclusion conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds account scoping, authentication requirements (API key and Authorization header), and the specific returned fields. This goes beyond the annotations 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?

The description is front-loaded with the core purpose and then adds necessary context about workflow_run, returned data, and authentication. It is slightly longer than strictly required, but 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 read-only list tool with one optional parameter, an output schema, and robust annotations, the description covers scoping, authentication, returned fields, and the relationship to workflow_run. 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 schema description coverage is 100%, and the only parameter, limit, is fully documented with default, minimum, maximum, and ordering semantics. The description does not add parameter-specific detail, but the baseline of 3 applies because the schema already carries the weight.

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: 'List the workflows saved to the ToolForte account this API key belongs to.' It clearly distinguishes this tool from the sibling workflow_run by explaining that workflow_run needs an id obtained here.

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 says 'Call this first: workflow_run needs an id from here,' giving the agent a clear when-to-use instruction and the relationship to the main alternative tool. The workflow-orchestration framing also explains the broader context.

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

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

Beyond the annotations' safety hints, the description reveals important runtime behavior: per-step credit costs, how the call's own credit interacts with the first step, sequential execution with stop-on-first-failure, failure reporting, and the substitutions field's meaning. It also discloses the API key requirement and exact auth header format.

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 longer than average but every sentence carries necessary operational information: cost, ordering, failure behavior, substitutions, and authentication. Details are front-loaded and no filler is present.

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 inputs, outputs, failure semantics, costing, substitutions warnings, and authentication. An agent has enough context to call it correctly and interpret unexpected results.

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

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

Schema coverage is 100%, and both parameters are already described in the schema, including where to find the id and input keys. The description reinforces this but does not add significant new meaning 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?

The description opens with a specific verb and resource: 'Run one saved workflow by id' and states the return value ('what every step produced'). It clearly distinguishes itself from the sibling workflow_list by explaining where to obtain the id and input 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 gives actionable guidance: get the id and input keys from workflow_list, and it explains prerequisite authentication. It does not explicitly state when not to use the tool or name alternatives, but the context is otherwise clear and 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 establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond those hints: the counting is inclusive, weekdays are defined as Mon-Fri, and Dutch public holidays can optionally be excluded. No contradiction with annotations 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 two sentences with no filler. The first sentence front-loads the core behavior and scope, while the second briefly gives practical intent. Every sentence earns its place.

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

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

Given the tool's low complexity, the annotations cover safety, the schema covers all parameters and defaults, and an output schema exists, the description provides enough purpose and use-case context for correct invocation. Nothing important 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 all three parameters, including the YYYY-MM-DD format and the default for excludeDutchHolidays. The description does not add meaningful detail beyond referring to the date range and optional holiday exclusion, so the baseline of 3 for full schema coverage 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: 'Count working days (Mon-Fri) between two dates inclusive', with the optional Dutch holiday exclusion clearly scoping the behavior. It is also semantically distinct from the sibling tool dutch_public_holidays, which returns holiday dates rather than a day 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 gives clear usage context by naming concrete scenarios ('SLA, payroll, and planning questions') and emphasizing 'exact date math'. It does not explicitly say when not to use the tool or point to an alternative, but the intended use cases are reasonably clear.

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