Validators MCP

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 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), 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 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), 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.