Agent Tools MCP

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

Annotations already establish read-only, idempotent, closed-world and non-destructive behavior, so the bar is lower. The description still adds useful context beyond them: the 256px ceiling, the deterministic/synthetic nature of the output, and the negative disclosure that no image models, uploaded photos or external assets are used.

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, front-loaded with what is produced and the size limit, then usage, then the negative capability. Slightly redundant with the title but nothing is wasted.

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

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

With no output schema, the description carries the return-value burden and does say it returns SVG placeholder content. All four params are covered by schema, annotations cover the safety profile, and usage boundaries are stated; only the exact SVG shape/size behavior is left implicit.

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 seed, size, text and pattern are all documented at the schema level with ranges and enum values. The description only restates the 256px bound and gestures at determinism without adding format or interaction detail, so 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?

States a specific verb and resource ('Generate SVG placeholder avatar') plus a hard size constraint, so an agent knows exactly what artifact it produces. It does not name any sibling (e.g. generate-fake-data or generate-lorem) to disambiguate within the crowded generate-* family, which keeps it short of a 5.

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

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

Gives an explicit positive context ('for prototypes') and an explicit exclusion ('Not suitable for matching a real person's photograph'), which is real routing guidance. It stops short of naming an alternative tool for the photo-matching case, so no sibling redirection.

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 read-only, idempotent, non-destructive, closed-world behavior, and the description adds genuine context beyond them: output is Luhn/format-valid but synthetic, with no issued account or bank access. It does not disclose the return shape or whether seed makes output deterministic beyond what the schema says.

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

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

The core statement is front-loaded and clear, but the warning is restated three times ('Never use as real payment credentials', 'Never use to impersonate a payment credential', 'no issued account or bank access'), which is redundant for the space consumed.

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?

There is no output schema, so the description should clarify what is returned (a number only, or full card data with expiry/CVV) and how brand/seed shape the result; it instead repeats safety caveats. Adequate for a low-risk generator but leaves return-value questions open.

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 says nothing about the two parameters (seed, brand) or how they affect output, adding no 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?

States a specific verb and resource ('Generate Luhn-valid synthetic TEST card data') with the key property (checksum validity) that distinguishes it from generic generators. It does not, however, name or contrast against close siblings like generate-fake-data or is-card-safe, so differentiation is only partial.

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?

Gives an explicit intended use ('payment-form UI tests that need checksum-valid dummy data') and explicit exclusions ('never use to impersonate a payment credential or test real purchases'). It never names an alternative tool for card validation (e.g. is-card-safe), so routing guidance is present but incomplete.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds context beyond the annotations: it states the return format follows the selected notation and warns that generated colors are not automatically accessible, which is useful caveat behavior.

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

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

Three short sentences, front-loaded with purpose, then usage, then caveat. No filler and every clause carries a distinct obligation.

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

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

With no output schema, the description partially compensates by noting returns are palette values in the selected format and are not automatically accessible. Combined with 100% schema coverage and full annotations, an agent has enough to invoke it correctly, though return shape details remain unspecified.

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 five parameters (base, seed, count, format, scheme) are already documented in the schema with enums for format and scheme. The description only alludes to "base hue" and "selected format" without adding syntax or constraints, so the baseline 3 applies.

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

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

States a specific verb and resource ("Generate color palette") that clearly maps to the color-generation function, and the title elaborates it as an "illustrative color palette." It does not explicitly distinguish itself from any sibling, but no sibling in the list handles colors, so the purpose is unambiguous in practice.

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

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

"Use when a design prototype needs related colors from a base hue" gives an explicit when-to-use, and "Not an accessibility or WCAG contrast audit" gives an explicit when-not. This routing guidance is complete for the agent's decision.

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 readOnly, idempotent, non-destructive and closed-world behavior, so the bar is lowered. The description adds two useful bound statements — the hard eight-row ceiling and 'never accesses a production database' — which reinforce safety and scope for an agent deciding whether this is appropriate for a test pipeline. The production-database claim largely restates openWorldHint=false/readOnlyHint=true, keeping it just short of a 5.

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

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

Three short sentences, front-loaded with the core capability, then the use case, then the sibling alternative and the hard bound. No filler or restated tool name beyond the necessary scoping.

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?

There is no output schema, so the description carries some of the return-value burden; it does say the output is up to eight synthetic rows in one of the three formats, which is adequate for a generator. A brief note on response shape (e.g. single string vs. array of rows, and how seed affects reproducibility) would close the remaining gap.

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

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

Schema description coverage is 100%, and every parameter (seed, count, format, schema) is already documented in the schema, including ranges and enum values. The description only echoes the 8-row bound already present in 'count' and says nothing about seed determinism or the schema map, so this is baseline territory.

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?

Opens with a specific verb and resource — 'Generate up to 8 rows of synthetic JSON/JSONL/CSV' — and immediately gives the intended scenario (testing import/export flows). It explicitly routes the user away from the closest sibling, generate-fake-data, for entity-specific fixtures, so an agent can distinguish the two without opening either schema.

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

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

States when to use it ('testing CSV, JSON or JSONL import/export flows with fabricated data') and when to prefer an alternative ('For specific user/company/address fixtures, use generate-fake-data'). Both the positive trigger and the exclusion are explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: output is local synthetic fixtures, not real identities or verified business records, which reassures the agent nothing external is contacted or mutated.

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

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

Three short sentences, front-loaded with the scope constraint and the routing alternative. The second sentence partly restates the first ('made-up users, companies or addresses' repeats the opening), which is minor redundancy but not waste in a small definition.

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?

There is no output schema, yet for a fixture generator the key facts (what is produced, local-only, deterministic via seed) are covered. The only omission is any description of the returned record shape, which is a small gap given the tool's simplicity.

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

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

Schema coverage is 100%, so kind, seed and count are fully documented in the schema itself; the description only echoes the record cap of eight and the category list. No additional syntax or format meaning is layered on, so the baseline 3 applies.

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

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

States a specific verb (generate) plus resource (synthetic users, companies, addresses) and hard scope (up to 8), naming the sibling generate-dataset as the different path. An agent can distinguish this from generate-dataset and the many single-value generators without opening a schema.

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

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

Explicitly gives the use case ('seed demos with made-up users, companies or addresses') and the alternative with its selecting condition ('For a custom schema and CSV output, use generate-dataset'). Both when-to-use and when-to-use-something-else are present.

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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new context: it returns a digest and is explicitly not a password-hashing or key-derivation service, which clarifies capability boundaries 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?

Front-loads the core action and stays compact, but the password caution is repeated three times ('do not hash passwords here', 'directly for password storage', 'not a password-hashing...service'), which is mildly redundant.

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 read-only generator with no output schema, the description covers purpose, safety boundaries and return type adequately. Nothing essential is missing, though the return format is only named, not detailed.

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 algo enum with default is fully documented in the schema. The description echoes the algorithms but adds little syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (compute) and resource (SHA-256 or legacy MD5 hash of text), and the title confirms the digest scope. It also carves itself away from sibling tools by explicitly ruling out password hashing, which routes to generate-password or is-password-safe.

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?

Gives explicit when-to-use ('non-secret fixture digests or to compare public text content') and when-not ('do not hash passwords here', 'do not use the legacy MD5 choice for security'). The routing to alternatives is unambiguous.

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

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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the description only needs to add context. It does: the output is deliberately nonsensical filler and involves no fetching of articles or documents, which calibrates what the agent should expect to receive. Determinism via the seed is left to the schema, keeping this short of a 5.

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

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

Three short sentences, front-loaded with the core capability, then usage routing, then output expectation. Slight overlap between 'words, sentences or paragraphs' here and the units enum in the schema, but nothing is padded or redundant enough to hurt.

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 low-complexity, zero-required-parameter generator with no output schema, the description covers what it produces, when to use it, and what it does not do. Annotations carry the safety profile, so no essential information for invoking it correctly is missing; only return-shape detail is unaddressed, which is minor for filler text.

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 defines seed, count (1-8, default 3) and the units enum. The description's 'bounded' hints at the count ceiling and it names the three unit types, but it adds no format or interaction detail (e.g., how seed affects output) beyond the schema. 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?

Specific verb + resource ('Generate bounded lorem ipsum text') with explicit output scope: placeholder words, sentences or paragraphs. It also distinguishes itself from neighbors by stating the content is nonsensical sample text rather than fetched documents or real data, so an agent can separate it from siblings like generate-fake-data or generate-prompt.

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 states the use case ('for visual mocks') and an explicit negative case with an alternative ('For real editorial text, use a writing model instead'). The alternative is an external model rather than a named sibling tool, so routing guidance across this server's tools is absent, but when-to-use and when-not-to-use are both present.

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 cover the safety profile (readOnly, non-destructive, idempotent), and the description adds real value beyond them: the output surfaces as MCP text visible to the client, and seeded output is predictable while unseeded uses cryptographic randomness. That explains the idempotency claim rather than contradicting it.

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?

Purpose is front-loaded and the sentences are short, but "Never use seeded outputs as secrets" and "Never use seeded passwords as actual production credentials" are near-duplicate warnings, and the final client-visibility caution is a fourth consecutive caveat trailing the substance.

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-optional-parameter generator with no output schema, the description covers what it returns (MCP text), the randomness model, and the testing-only constraint. It is close to sufficient; only defaults and result length/format phrasing are absent.

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%, including the seed determinism warning, so the schema already carries parameter meaning. The description echoes the seed caveat but adds no syntax, default, or format details the schema lacks – 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?

"Generate a random password with WebCrypto" gives a specific verb and resource, and the fixtures/testing framing differentiates it from generate-token or generate-hash. However it never names a sibling or explicitly contrasts scope with them, so the differentiation is inferred rather than stated.

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

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

"Use to populate synthetic account fixtures" states a clear context, and the two warnings about seeded output mark a when-not-to-use boundary. No alternative tool is named as a substitute, 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context not in the annotations: the output is 'fictional strings, not callable phone numbers or subscriber lookups', which prevents a common misuse. It stops short of explaining the seed's determinism guarantee or output shape.

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

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

Three short sentences, front-loaded with the action and cap, then usage, then the sibling routing and the output disclaimer. Every sentence carries distinct information with no repetition.

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

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

With no output schema, the description correctly compensates by characterizing the return value as fictional, non-callable strings. Combined with fully documented parameters and rich annotations, an agent has what it needs; only the seed's repeatability behavior and return structure remain unstated.

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

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

Schema description coverage is 100%, so the schema already documents city, state, count and seed with enums and bounds. The description only echoes 'up to 8' and the US-format scope, adding no syntax or semantics beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Generate up to 8 fictional US-format phone numbers') and immediately bounds the scope with the count cap and the US format. It also names the sibling it is not ('To validate a supplied number, use is-phone-e164'), so an agent can distinguish it from is-phone-e164 without opening either schema.

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

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

It gives an explicit use case ('mock phone-number fields in US-based test data') and routes the agent to the correct alternative for the adjacent task ('To validate a supplied number, use is-phone-e164'). Both the when-to-use and the when-not-to-use case are covered.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds value beyond that by clarifying the tool does not invoke or bill a model and by warning to inspect template placeholders before use.

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

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

Three short sentences, the core purpose is front-loaded, and the return-value note earns its place since there is no output schema. The first two sentences overlap slightly in restating the template/variable-map idea, keeping it from a 5.

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

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

With no output schema, the description correctly states the return ('constructed prompt text'), and the schema fully documents parameters. The placeholder-inspection caveat covers the main failure mode. Only minor gaps remain (e.g., behavior with missing vars), so it is near-complete rather than exhaustive.

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 four parameters (template, vars, type, seed) are already documented in the schema with descriptions and an enum. The description only restates 'template and variable map' and adds no format or constraint detail beyond the schema; 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?

States a specific verb+resource ('Fill a prompt template with provided variables') and clarifies the mechanism ('assemble a prompt string from a caller-supplied template and variable map'). This is easily distinguished from siblings like is-prompt-minify or generate-lorem.

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?

Gives clear context ('Use to assemble a prompt string...') and an explicit negative scope ('It does not invoke or pay for any AI model'), which prevents a caller from mistaking it for an LLM execution tool. It does not name an alternative sibling (e.g., is-prompt-minify) 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond them: it discloses that transliteration/normalization happens locally and warns to verify preferred slugs before publishing permanent URLs, a behavioral caveat not present in the structured fields.

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

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

Three short sentences, all front-loaded: what it does, when to use it, then the sibling exclusion and behavioral caveat. No sentence is 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 simple pure-function generator with 100% schema coverage and no output schema, the description is nearly complete: it names the output (Unicode-aware slug) and the local-processing behavior. It stops short of describing edge-case output (e.g. truncation at maxLength or empty input), which leaves a small gap.

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

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

Schema coverage is 100% and the schema already documents both `text` (with a Café example) and `maxLength` bounds, so the description carries no additional parameter syntax or format detail. Baseline 3 is appropriate when the schema does 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?

States a specific verb and resource ('Produce Unicode-aware slug from a title') and immediately scopes it against the sibling is-url-safe, so an agent can distinguish it from the other generate-* tools without opening a schema.

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

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

Gives an explicit trigger ('Use when creating an SEO-friendly path segment from a title') and names the alternative for the adjacent case ('To check an existing full URL, use is-url-safe instead'), which is the exact when/when-not/alternative pattern that routes correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: it returns synthetic identifiers and explicitly does not query Social Security records, which is meaningful behavioral disclosure.

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

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

Four short sentences, front-loaded with the core action and capped with a safety constraint. The closing "Returns synthetic identifiers" is mildly redundant with "synthetic ... fixtures" earlier, a minor waste.

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

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

For a read-only generator with full schema coverage and no output schema, the description adequately signals the return shape and the safety boundary. An agent has everything needed to call it correctly, though return structure details remain implicit.

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 seed, count, valid, and formatted are all documented in the schema itself. The description only echoes the count ceiling ("up to 8") and adds no syntax or semantics beyond that, so the baseline 3 applies.

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

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

The description names a specific verb (generate) and resource (synthetic US SSN-style fixtures) and the title reinforces it. The resource is unique among siblings like generate-phone-number and generate-card-number, so an agent can tell it apart, though it does not explicitly contrast itself with any sibling.

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

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

"Use only to test formatting and field validation in demos" gives explicit when-to-use guidance, and "Never use a generated value as anyone's actual Social Security number" gives a clear when-not. It stops short of naming alternatives such as is-us-tin-safe for validation purposes.

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?

While annotations already declare readOnly/idempotent/non-destructive, the description adds genuinely useful context beyond them: the WebCrypto implementation, the security warning about deterministic seeds, and the critical fact that no token is registered with any service and the value is only visible to the client.

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

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

Three dense sentences, front-loaded with the action and security caveat. Semicolon-chained clauses make it slightly packed, but every sentence carries distinct, 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?

With no output schema, the description compensates by stating what is returned ('a generated value visible to the MCP client') and that nothing is registered externally—exactly the return/behavior context an agent needs for a three-parameter generator.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantic weight by framing the seed parameter's safety implications ('never use deterministic seed for real secrets')—meaning that isn't captured in the schema's terse 'reproducible test output only' note.

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 ('Generate tokens/UUIDs with WebCrypto') and explicitly differentiates from siblings by naming generate-hash for file digests. An agent can distinguish this from generate-password or generate-hash without opening schemas.

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

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

Gives explicit when ('temporary development fixtures or unseeded random UUIDs'), when-not ('Do not use seeded output as authentication credentials'), and an alternative ('for file digests use generate-hash'). Routing guidance is complete.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety bar is largely met. The description adds genuine value beyond that: 'Returns a local structural assessment; never contacts a bank' clarifies the operational behavior and confirms no external calls, plus the privacy warning about real card details.

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?

Five short, front-loaded sentences with no filler; the scope constraint and safety warning come first, followed by use/non-use cases and return behavior. Every sentence earns its place.

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

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

For a single-parameter, read-only check with full annotation coverage, the description covers purpose, misuse exclusions, input constraint, and return nature. No output schema exists, but the description adequately characterizes the response as a local structural assessment.

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?

Only one parameter, and schema description coverage is 100%, so the schema already documents the 'number' field and its synthetic-only constraint. The description reinforces the same idea but adds no new format or syntax detail, so the baseline 3 applies.

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

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

States a specific verb+resource: screening a synthetic card number for network/length plausibility and Luhn checksum. This is clearly distinguishable from siblings like is-iban-safe, is-us-tin-safe, or is-phone-e164, and the scope ('Luhn/brand format only') is precise.

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 states when to use it ('screen synthetic card fixtures for plausible network/length and Luhn checksum') and when not to ('Do not use for real payment-card authorization or fraud detection'). It also warns against submitting real card details, covering the main misuse path.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by warning that the output may normalize formatting and should be inspected before production use, which annotations cannot express.

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 tight sentences, front-loading what it does and the size limit before the routing hint and the output caveat. No filler or redundant restatement of the name.

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

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

For a simple two-parameter tool with full schema coverage and annotations, the only real gap would be return behavior; the description anticipates this with 'returns an optimized representation; may normalize formatting.' Nothing an agent needs to call 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 description coverage is 100% and the enum on format is self-explanatory, so the schema carries the burden. The description adds only the repeated 4096-character limit, though that constraint is usefully restated as an operational bound.

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

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

States specific verbs (clean/minify) and resource (JSON/JSONL/CSV data) plus the 4096-character scope, and explicitly distinguishes itself from the sibling is-json-safe. An agent can tell it apart from the other is-* validity tools without opening either schema.

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

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

Gives an explicit use case (compacting small JSON/JSONL/CSV samples) and names the alternative tool with the condition that selects it ('For ordinary JSON validity checks, use is-json-safe'). Little is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description still adds real value by confirming no email is sent and no DNS requests are made, i.e. no network side effects and no deliverability implication. It stops just short of describing the exact result shape, so it is not a full 5.

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

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

Three sentences, zero padding, front-loaded with the scope limitation before the usage guidance and the negative capability disclosure. Every sentence earns its place.

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

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

For a single-parameter boolean-style validator with no output schema, the description covers scope, the negative case (no mailbox verification, no DNS), and the return nature ('syntax-only result'). An agent has everything needed to invoke and interpret 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?

There is one parameter with 100% schema description coverage, including the maxLength and ASCII-only constraint, so the schema already carries the semantics. The description's 'ASCII format only' phrasing corroborates but does not extend the schema, which is the baseline-3 case.

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

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

The description names a concrete verb-and-resource action (reject malformed email strings / return a syntax-only result) and explicitly bounds the scope as 'ASCII email format, without mailbox verification.' That scope statement cleanly separates it from unrelated validators in the sibling list (is-phone-e164, is-iban-safe, is-ip-safe) without needing their schemas.

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

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

It states the use condition ('before a form or fixture is processed') and an explicit exclusion with a routing instruction ('For mailbox existence or deliverability, use a separate verification service'). An agent knows both when to call it and when not to, even though the alternative is external rather than a sibling 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new context beyond them: the output must be reviewed before production, and consent/tracking correctness is explicitly out of scope and must be verified downstream. It does not repeat the idempotency guarantee, which is a minor omission rather than a contradiction.

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

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

Sentence one states the action and the review requirement up front, which is well front-loaded. However, sentence two ('Use when transforming an already supplied Google Analytics tag snippet') largely restates sentence one's 'existing Google Analytics tag snippet' phrase and could be merged, making the description mildly redundant for its 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?

With no output schema, the description correctly fills the gap by stating what is returned (rewritten snippet text) and by flagging that the caller must validate consent and tracking afterward. For a single-input transformer this is nearly complete; only the parameter's format expectations are left entirely to the 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?

There is one parameter and schema description coverage is 100%, so the schema already defines 'html' as the existing snippet (max 4096 chars). The description adds no further syntax, format, or size guidance, so the baseline 3 applies.

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

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

The description names a specific verb and resource: rewriting/optimizing an existing Google Analytics tag snippet. It is clear and unambiguous, though it never contrasts itself with any sibling (the closest-named ones, is-html-minify and is-json-safe, are unrelated, so the 'is-' prefix could momentarily mislead an agent into expecting a checker rather than a transformer).

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 an explicit trigger ('Use when transforming an already supplied Google Analytics tag snippet') plus three negative boundaries (does not configure GA4 accounts, install tracking, or verify consent). That is strong when/when-not guidance; only the absence of a named alternative for the cases it excludes keeps it from a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds substantial behavioral context: the transformation is heuristic, explicitly not a standards-compliant HTML parser, and the agent should regression-test and review output before production. That is exactly the kind of quality caveat annotations cannot express.

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, front-loaded with the core action and its safety caveat, then the sibling routing, then the fidelity warning. No sentence is redundant and each adds distinct information.

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

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

For a single-parameter pure transformation with full annotation coverage and no output schema, the definition covers purpose, alternatives, and fidelity limits. The only minor gap is that it does not state the return shape (minified HTML text), though that is strongly implied by the tool name.

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 a single documented parameter, so the schema already carries the semantics. The description reinforces the 'controlled fragment' scope but adds no syntax, format, or encoding detail beyond what the schema states.

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 ('HTML minification', 'reduce whitespace in a controlled HTML fragment') and explicitly distinguishes itself from the is-minify-css and is-minify-js siblings by name. An agent can route correctly without opening any schema.

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

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

'Use to reduce whitespace in a controlled HTML fragment before delivery' gives clear context, and 'For CSS or JavaScript, use is-minify-css or is-minify-js' names the alternatives with their selecting condition. The scope word 'controlled fragment' implicitly excludes whole documents, but no explicit when-not rule is stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description reinforces this with 'bundled country registry, with no bank or network lookup.' It goes further than the annotations by disclosing what the check does NOT establish (ownership, bank existence, transferability), which is genuinely useful behavioral context.

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

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

Three tight sentences: what is checked, when to use it, when not to. Front-loaded and free of filler, with every clause carrying load-bearing information.

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

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

For a single-parameter predicate tool with no output schema and full annotation coverage, the description supplies everything needed: input expectations, scope of validation, and explicit exclusions. Nothing material 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?

With a single parameter at 100% schema description coverage, the schema already documents format and the 'do not submit real private bank account details' warning. The description's 'fabricated or public IBAN' phrasing echoes rather than extends this, 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 names the exact resource and checks performed (format, country length, checksum against a bundled registry), which an agent can distinguish from a naive regex validator. It stops short of explicitly contrasting with the sibling validators (is-card-safe, is-vat-safe), but the family pattern makes scope clear.

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

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

'Use to check a fabricated or public IBAN's country length and check digits' names the intended input, while 'Do not use to confirm account ownership, bank existence or actual transferability' gives explicit exclusions. Both when-to-use and when-not-to-use are stated directly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by reinforcing the closed-world claim with concrete operational detail: 'Local syntax validation only; performs no DNS or network request,' which tells the agent there is no latency or network failure mode to handle.

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

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

Four short sentences, zero waste, and the core purpose ('Validate IPv4 or IPv6') is front-loaded ahead of the exclusions. Every clause earns its place by either defining scope or ruling out a misuse.

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?

There is no output schema, so the description could arguably state the return shape (a validity boolean), which it only implies with 'check whether'. Otherwise, for a single-parameter, annotation-covered validation tool, the definition covers purpose, scope, and exclusions fully.

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 single 'ip' parameter is already documented with concrete IPv4/IPv6 examples in the schema itself. The description's 'supplied string' phrasing adds no syntax or format constraints beyond what the schema provides, so this sits at the baseline.

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

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

States a specific verb (Validate) and resource (IPv4 or IPv6 address syntax), and the 'without lookup' qualifier immediately distinguishes it from network-probing siblings. An agent can tell it apart from is-url-safe or is-google-tag without further reading.

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 says when to use it ('check whether a supplied string is structurally an IP address') and when not to ('Do not use it to geolocate a host or test network reachability'). Both the positive and negative conditions are stated, leaving nothing to inference.

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

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

Annotations already establish the safe-read profile (readOnly, idempotent, non-destructive), so the description only needs to add scope detail — and it does: leap-day validity, Gregorian-only checking, and no timezone lookup. The one thing left unstated is the return shape (presumably boolean given the is-*-safe family and the absent output schema).

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

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

Four tight clauses with zero filler; the format and scope constraint are front-loaded before the alternative-parser note. It reads as a compact spec rather than prose, which suits a single-parameter predicate tool.

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

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

For a one-parameter predicate with full annotation coverage and no output schema, the description covers format, intent, and boundaries (no timezone, Gregorian only). The only gap is an explicit statement that the result is a boolean validity verdict.

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

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

There is a single parameter and schema description coverage is 100%, so the schema already documents the 'date' field, its format, and the 2024-02-29 example. The description restates YYYY-MM-DD but adds no syntax, constraint, or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

The description names a specific resource and format: a canonical Gregorian date in YYYY-MM-DD, and frames the tool as a validity check including leap days. It distinguishes itself from time-aware parsers, so an agent can tell it apart from timestamp-handling tools. It does not explicitly differentiate from other is-*-safe siblings, but its scope is unambiguous.

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

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

'Use before accepting YYYY-MM-DD dates' gives a clear triggering context, and 'For timestamps, offsets or date/time conversion, use a time-aware parser instead' names an explicit when-not and an alternative. No sibling is named among the listed tools, but the routing guidance is concrete rather than implied.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real context beyond them: bounded depth and key counts, and that input is neither executed nor persisted. It stops short of saying what happens on invalid input (error vs. false result), which matters for a validator with no output schema.

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

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

Three short sentences, front-loaded with purpose and routing, with no filler. The opening clause 'Parse JSON using upstream safety limits' slightly overlaps the later 'Checks JSON syntax with bounded depth and key counts', a small redundancy rather than a flaw.

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, annotation-rich, output-schema-less validator, the description supplies the needed scope and non-mutation guarantees. The remaining gaps are the concrete limit values and the return shape on failure, both minor for a self-describing safety check.

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

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

Schema coverage is 100% and the single parameter already documents the 4096-character cap and the depth/key-count limits, so the description's mention of 'bounded depth and key counts' largely restates the schema. Baseline 3 applies when the schema does 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?

States a specific verb and resource ('Parse JSON ... test whether text is valid JSON') plus the scope of the check ('within depth/key constraints'). It also names the sibling it is not ('For CSV/JSONL cleanup, use is-dataset-minify instead'), so an agent can separate it from the other is-* validators without opening a schema.

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

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

Gives an explicit trigger ('Use to test whether text is valid JSON within depth/key constraints') and an explicit redirect to an alternative with the condition that selects it ('For CSV/JSONL cleanup, use is-dataset-minify instead'). This mirrors the pattern of the strongest calibration example.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: it is a heuristic rather than a full CSS parser, output should be visually regression-tested, and results reviewed before production. This qualifier is exactly the kind of caveat annotations cannot express.

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

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

Front-loads what the tool is, then scope, then alternatives, then the caveat — four dense clauses, none wasted. Every sentence carries actionable information.

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

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

With no output schema, the description could say more about the return shape, but the 'visually regression-test the output' note plus annotations covering safety make it adequately complete for a single-parameter transformation tool.

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

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

Schema coverage is 100% and the single 'code' parameter is fully documented in the schema, including the 4096-character limit. The description adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Conservative CSS minification') and immediately differentiates itself from siblings by naming is-minify-js for JavaScript and a CSS-aware build tool for complex stylesheets. An agent can route correctly without opening any schema.

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

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

Explicit scope ('small CSS snippets where basic whitespace cleanup suffices') plus two named alternatives with the conditions that select them. Both when-to-use and when-not-to-use are covered, leaving nothing to inference.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds meaningful non-obvious traits: it is heuristic rather than AST-aware, may change behavior, and recommends regression-testing output. It could say more about output shape, but the caveats are substantive.

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

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

Front-loads the core purpose and packs caveats and alternatives into a few short sentences with no filler. Slightly telegraphic, but every sentence earns its place.

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

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

For a single-parameter, no-output-schema tool with rich annotations, the description supplies the key behavioral caveats (heuristic, verify output) needed to call it safely. Nothing critical is missing, though return-value expectations are left implicit.

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 a single, well-documented 'code' parameter including its 4096-character limit, so the schema carries parameter semantics. The description adds nothing about the input format beyond that; 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?

States a specific verb and resource ('Conservative JS minification') and immediately scopes it with 'Not a parser.' It also names the sibling it is not (is-minify-css) and contrasts with real parsers, so an agent can select it without opening the schema.

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

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

Explicitly prescribes the use case ('small JavaScript snippets where basic whitespace cleanup suffices'), names the CSS alternative (is-minify-css), and warns off production bundling toward a real parser/minifier. Both when-to-use and when-not-to-use are covered.

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 read-only, idempotent, non-destructive and closed-world behavior, and the description usefully corroborates the closed-world claim by stating there is no external lookup. It also discloses the qualitative nature of the result ('heuristic assessment, not a breached-password check'), which annotations alone cannot convey. It stops short of describing the actual output shape.

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-loads the action ('Evaluate strength'), but two of its four clauses say essentially the same thing about not sending real credentials to an external/third-party endpoint, which is redundant padding rather than an additional constraint.

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 validator with full schema coverage and rich annotations, the safety and scope context is adequate. However, there is no output schema, so the description carries the burden of explaining the return value and only says it is a 'heuristic assessment' without indicating whether the result is a boolean, a score, or a strength tier.

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?

With a single parameter at 100% schema description coverage, the schema already documents the 'password' field including the dummy-value warning. The description restates the same warning rather than adding format, length, or validation semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a clear verb+resource ('Evaluate strength') and qualifies it as a heuristic assessment rather than a breached-password lookup, which sets it apart from a network-backed checker. It does not explicitly contrast with the is-*safe sibling family (is-email-safe, is-uuid-safe, etc.), so sibling differentiation is implicit through the naming pattern rather than stated.

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 concrete usage conditions: use only with dummy passwords, to evaluate upstream password rules, and never with real user credentials. That is a strong when-to-use/when-not-to-use constraint, though no alternative tool is named for cases where a real breach check is actually wanted.

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 (readOnly, idempotent, non-destructive, non-open-world). The description adds real context beyond them: processing is done 'locally', 'sends no SMS', and it does not confirm subscriber ownership. That last point is useful scoping an agent could otherwise misjudge.

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

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

Front-loads purpose, then usage, then scope exclusions in three short sentences with no filler. The opening fragment 'International phone format with normalization' is slightly clipped but still functional as a lead.

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?

There is no output schema, so the description is the only place to learn what a call returns — and it never says whether the result is a boolean, a normalized string, or an error shape. For a single-param validator this is the main remaining gap; safety behavior is otherwise well covered.

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

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

Schema coverage is 100% and the single 'phone' parameter is documented with an example (+66812345678), so the schema carries the parameter burden. The description adds only the notion of E.164 normalization and does not clarify syntax, accepted variants, or how invalid input behaves — baseline 3 is appropriate.

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

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

States a specific verb+resource: checking/normalizing a candidate phone number into E.164 style, with the explicit trigger 'before storing a test record'. It is clearly distinct from the generate-* siblings by being a validation/normalization tool, though it never names a sibling explicitly.

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

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

'Use to check a candidate international number in E.164 style before storing a test record' gives a concrete usage context, and the note that it does not verify subscriber ownership defines a boundary. No alternative tool is named for the case where you need generation (generate-phone-number) rather than checking, so it stops short of explicit routing.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, idempotent, closed-world), so the description's real contribution is the lossiness disclosure: "semantic equivalence not guaranteed" and "may change phrasing and semantics." That is exactly the non-obvious trait an agent needs before substituting a compressed prompt, though no return format or size behavior is described.

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?

Purpose and usage are correctly front-loaded, but the same caution is stated three times ("semantic equivalence not guaranteed," "Do not assume the rewritten prompt preserves all nuances," "May change phrasing and semantics"). Emphasis is understandable for a lossy transform, but two of those sentences could be merged without losing 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 trivial one-parameter, annotation-rich tool this is nearly complete: what it does, when to use it, and the critical fidelity caveat are all present. The remaining gap is that, with no output schema, the description never says the call returns the compacted prompt string, leaving the return shape to inference.

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

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

Single required parameter with 100% schema description coverage ( "Prompt text to compact, up to 4096 characters"), so the schema already carries the semantics. The description adds no format, encoding, or length guidance beyond the schema, which is the expected baseline 3 for a fully documented one-param tool.

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?

"Compress prompt whitespace and filler" gives a concrete verb plus a clearly bounded resource, so an agent immediately knows this is a text-compaction tool for prompts. It does not, however, name or contrast with adjacent minify siblings (is-minify-css, is-minify-js, is-dataset-minify), leaving the differentiation to be inferred from the word "prompt".

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

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

"Use to shorten prompt text before passing it to a model when token budget matters" states the trigger condition explicitly and places the tool in a concrete workflow position. It offers no explicit when-not guidance or named alternative (e.g., pass the original prompt unchanged when fidelity matters), 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful context: it runs locally, does not parse log entries, and does not alter meaning. It omits any mention of the 4096-character input cap or what happens on overflow, which is the one behavioral gap.

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

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

Four short sentences, front-loaded with the action, then usage, then the sibling redirect, then the scope limit. No sentence is redundant and there is no filler.

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

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

For a single-input, no-output-schema text transform, the description covers purpose, when to use it, an alternative, and the limits of the transformation. The only missing piece is the maxLength behavior, which matters for large terminal logs but is secondary.

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?

Only one parameter and schema description coverage is 100%, so the schema already explains that 'text' is terminal output possibly containing ANSI sequences. The description adds no format or size guidance beyond that; 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?

States a precise verb+resource: 'Strip ANSI escape sequences.' It also conflicts nothing with the title and explicitly distinguishes itself from a named sibling (is-dataset-minify), so an agent can pick it without opening any schema.

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

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

Gives the triggering scenario ('turning colorized terminal logs into clean text for indexing or display'), an explicit alternative for a different input type ('For structured datasets, use is-dataset-minify instead'), and a boundary statement about what it does not do.

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 (readOnly, non-destructive, idempotent, closed-world), and the description adds genuinely new behavior: 'never fetches, crawls or resolves the URL' plus a warning about what the result does not imply. This is the kind of non-obvious operational context annotations cannot express.

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

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

Three short sentences, front-loaded with what it is, then when to use, then the negative boundary. No filler and no repetition of the title.

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 validator with no output schema, the description covers scope, limitations and side-effect profile. The one remaining gap is the return shape (presumably a boolean) and how strict 'conservative' actually is, which the agent must infer from the name.

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 itself explains the accepted form ('Absolute HTTP(S) URL string; other schemes such as javascript: are not supported'). The description adds only the word 'conservative', with no detail on which edge-case URLs pass, so it is baseline-adequate rather than additive.

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

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

States a specific verb+resource ('Conservative HTTP(S) URL syntax') and immediately disambiguates from an actual network check with 'no HTTP request'. Within a sibling family of is-*-safe validators, the resource (HTTP(S) URL) is 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?

Gives an explicit use case ('before displaying or saving it') and an explicit anti-use case ('Do not use this to establish that a site is safe, accessible or trustworthy'). The most likely agent misreading of a tool named 'is-url-safe' is neutralized directly.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: it is format-only with no government lookup, and it warns against submitting real identifiers, which is privacy context annotations cannot 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?

Four short clauses, all front-loaded around the scope and safety constraint. 'Do not submit real identifiers' and 'synthetic ... fixtures' partially overlap, a minor redundancy in an otherwise tight description.

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-param read-only validator with no output schema, the description covers scope, safety, and the key limitation (no government lookup, no identity confirmation). It does not say the tool returns a boolean/pass-fail result, a minor gap given no output schema exists to state it.

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

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

Schema coverage is 100% and the single param is fully documented in the schema. The description adds a little by naming EIN/SSN/ITIN as accepted families, but does not describe expected input format or lengths beyond the schema's maxLength, so 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 — format-only checks on US EIN/SSN/ITIN identifiers — and names the exact identifier families accepted. An agent can distinguish it from sibling validators like is-ssn-safe or is-vat-safe without opening the schema.

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

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

It gives explicit when-to-use (only with synthetic EIN/SSN/ITIN fixtures) and when-not-to-use (do not confirm identity or IRS registration), which is exactly the routing guidance an agent needs. The scope limit is unambiguous.

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

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

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds value by disclosing negative scope: it does not check UUID uniqueness and does not resolve referenced resources, which prevents false expectations about what a 'pass' means.

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 and a leading fragment, front-loaded with the core action. It is tight overall, though the opening fragment ('Canonical UUID, optionally filter by version') partially duplicates the following sentence rather than adding new 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 validator with no output schema, the description covers the action, the version filter, the create-alternative, and the important non-behaviors. It does not mention the boolean return shape, but that is minor for a predicate-style tool whose annotations already establish it is a safe read.

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 both parameters are already documented with their formats and the 1-8 version range. The description only restates 'optionally filter by version' without adding syntax or default semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (verify) and resource (a canonical UUID string), and immediately distinguishes itself from the sibling that creates UUIDs by naming generate-token. An agent can tell it apart from the other is-*-safe validators because the resource (UUID) is explicit.

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

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

Provides explicit usage context ('Use to verify a UUID string, optionally limiting acceptance to a specific version') and routes the agent to the correct alternative ('To create new UUIDs, use generate-token'). It also states exclusions (no uniqueness check, no resolution), leaving little to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior context beyond that: validation is local/syntactic only, with no VIES or tax-agency lookup, so the agent knows a pass does not imply a live registered VAT number.

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

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

Three short sentences, no filler, with the core constraint (format-only) front-loaded before the usage and exclusion guidance. Every sentence carries distinct information.

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

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

For a single-parameter, closed-world, read-only validator with no output schema, the description covers everything an agent needs: what is checked, what is deliberately not checked, and where to go for the fuller check.

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

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

There is a single parameter with 100% schema description coverage ('Country-prefixed VAT number string such as DE123456789'), so the schema already documents the format and example. The description reinforces 'country-specific format' but adds no syntax or normalization detail 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?

States a specific verb (validate/screen) and resource (EU VAT ID, country-specific syntax) and explicitly bounds the scope to format rather than registration status. An agent can distinguish it from siblings like is-iban-safe or is-us-tin-safe by the named jurisdiction and check 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?

Gives an explicit when-to-use ('screen a test VAT ID for country-specific syntax') and an explicit when-not with the alternative ('to confirm tax registration or active status, query an official VAT register separately'). The routing decision is fully specified.

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