Verified.net

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

Beyond the annotations (openWorldHint=true, idempotentHint=true, destructiveHint=false), the description adds two genuinely useful behavioral facts: the lookup is live/number-portability sourced, and it costs 3 credits with no charge when data is unavailable. It does not address the bypass_cache behavior or latency, but the cost and live-source disclosure is real added value.

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

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

A single dense sentence with scope and returned fields front-loaded and no filler. The telegraphic compression ('ported, port date, current line type and VoIP') is efficient but slightly terse to parse.

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

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

With no output schema, the description usefully enumerates what comes back, and annotations already cover the safety profile, so the main remaining gap is the two undocumented optional parameters. For a 3-param read-style lookup this is close to complete.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, yet it never mentions bypass_cache or default_country. Only the required number parameter is indirectly explained by the US/Canada scope note; the two optional parameters remain opaque in both schema and description.

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 (carrier lookup for US/Canada numbers) and enumerates the returned facts: current carrier, ported status, port date, line type, VoIP. It is clearly distinguishable from siblings like validate_phone or reverse_phone, though it never names an alternative 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?

There is no guidance on when to choose this over validate_phone or reverse_phone, nor any stated prerequisites or exclusions beyond the implicit US/Canada scope. The credit note is cost context, not usage guidance, so the agent must infer the use case from the purpose alone.

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

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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive. The description adds real behavior beyond that: the billing model (charged per unique value, reverse lookups only when found) and the asynchronous 'returns the job, then poll' contract. It omits whether repeat calls create duplicate jobs and whether items can be re-submitted, which would matter given idempotentHint=false.

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

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

Two tight sentences, front-loaded with the scale and async nature, followed by the exact polling path. No filler and no repetition of the title or annotations.

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 correctly covers the async return and polling path plus billing. However, for a 5-parameter mutation tool at 0% schema coverage it leaves key inputs (webhook_url, default_country, tier, allowed type values) unexplained, so an agent could not configure a job confidently from this text alone.

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

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

Schema description coverage is 0% across 5 parameters, so the description carries the full burden and mostly does not: tier, webhook_url, default_country, and the meaning of the type enum values are all unexplained. Only 'up to 100,000 values' hints at an items constraint, leaving most parameters undocumented in both places.

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 ('Check up to 100,000 values in the background') with scope and scale, and explicitly distinguishes itself from the single-lookup flow it bills against. It also names the follow-up siblings (get_bulk_job, get_bulk_results), so an agent can place it in the workflow 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?

Clearly signals the batch/async use case and routes the agent through poll get_bulk_job then get_bulk_results, which is strong sequencing guidance. It does not state when to prefer single lookups instead, or when a bulk job is inappropriate (e.g. tiny item counts), so it falls short of explicit when/when-not/alternatives.

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 still adds real value beyond them by disclosing the returned data (balance plus 30-day usage) and the billing model ('Free'), which is not encoded anywhere 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?

Two short fragments, zero waste, with the resource and return contents front-loaded and the cost note last. Nothing could be removed 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?

With no output schema, the description correctly takes on the job of stating what comes back, and it does so concretely. It is sufficient for a no-argument read tool, lacking only explicit usage routing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline 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?

Names a specific resource (account) and states exactly what it returns: credit balance and usage for today and the last 30 days. It clearly separates itself from the verification/lookup siblings, though it never explicitly says so.

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

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

No when-to-use or when-not guidance, and no alternatives are named. The trailing 'Free' hints at a cost consideration but does not tell the agent when to prefer this tool over anything else.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the non-annotation fact that the call is free, which is genuinely useful for an agent deciding whether to poll, but says nothing about job lifecycle states, terminal conditions, or whether repeated polling is expected.

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

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

Two terse fragments, front-loaded with the resource and what is returned. Nothing is padded, though the second fragment ('Free') is arguably a separate concern rather than part of the core 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-parameter read tool with annotations covering safety, the description is close to sufficient, but with no output schema the agent gets no idea of what a status response contains (counts, state enum, timestamps) or how to poll it. 'Status and progress' gestures at the return shape without committing to 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?

There is one required parameter (job_id) and schema description coverage is 0%, so the schema provides only a bare type. The description never mentions job_id, its origin (presumably from create_bulk_job), or its format, so it fails to compensate for the coverage gap.

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 resource (bulk job) and the specific aspect retrieved (status and progress), which implicitly separates it from get_bulk_results. It does not explicitly name or contrast with that sibling, so an agent must infer the boundary between status and results.

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

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

The only guidance is the cost note 'Free', which tells the agent nothing about when to call this versus get_bulk_results or create_bulk_job. No prerequisites, no polling guidance, no exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds genuine but thin context beyond that: the pagination contract via has_next and the cost signal 'Free'. It does not describe behavior when the job is incomplete, missing, or invalid.

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

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

A single front-loaded sentence with no filler; the pagination hint is parenthetically tucked in without bloating the line. Sentence-fragment phrasing ('Results of a bulk job...') is terse but readable, costing it a point.

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

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

The tool is simple (two parameters, no nesting), but no output schema exists and schema coverage is 0%, so the description should carry more of the payload contract. It covers the key operational detail (paging via has_next) yet says nothing about the shape of the returned results or error states, leaving gaps for a no-output-schema tool.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it only partially compensates. Pagination is implied through 'one page at a time', loosely covering the page parameter, but its default of 1 and the meaning/format of the required job_id are never explained. Mentioning has_next is a return field, not an input parameter, so it does not rescue parameter semantics.

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 resource and scope: the results of a bulk job, paginated one page at a time. An agent can infer it differs from get_bulk_job (job metadata) versus results, but the description never names that sibling, so the differentiation is left to inference. It is a noun phrase rather than a verb+resource, 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?

Usage is implied rather than stated: you call this to fetch the output of a bulk job. It gives useful pagination guidance (has_next tells you to ask for the next page) but no when-to-use versus get_bulk_job/create_bulk_job, and no prerequisites such as requiring the job to be finished.

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 openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is largely covered. The description usefully adds the cost disclosure ('1 credit'), which is not in the schema or annotations. However it says nothing about what the '1 credit' spend or the cache state implies, and it does not explain the mismatch of a pure lookup carrying readOnlyHint=false.

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

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

A single, front-loaded sentence that lists the returned fields efficiently with no filler. The trailing '1 credit' is slightly orphaned but does earn its place as cost 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 enumeration of returned fields (ASN, Tor exit, risk score, recommendation) is a valuable stand-in. But leaving 'bypass_cache' unexplained and omitting any note on error behavior or credit implications for repeated lookups leaves gaps for a tool that consumes paid credits.

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 0%, so the description carries the full parameter burden. The 'ip' argument is self-evident from 'Check an IPv4/IPv6 address', but 'bypass_cache' is never mentioned — the agent gets no information on when freshness matters, whether bypassing costs extra credits, or how cache affects results.

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 ('Check') with a precise resource ('IPv4/IPv6 address') and enumerates the concrete data returned (geolocation, ASN, Tor exit, datacenter/hosting, risk score, recommendation). The IP resource has no overlap with siblings like verify_email, reverse_phone, or carrier_lookup, so differentiation is effectively implicit, though it is not stated 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the ten sibling tools. The agent must infer that this is the tool for IP reputation work purely from the tool name and resource.

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 (destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds genuinely useful behaviour beyond them: the data source (domain registration records) and a concrete cost model ('10 credits if found, free otherwise') that an agent needs for budget-aware decisions. It does not explain the surprising readOnlyHint=false, but that gap is minor.

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

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

Two tight sentences, front-loaded with the identity of the resource and followed by the cost consequence. No filler, nothing 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 lookup with annotations covering safety, the description gives the return content (names, phone numbers) and the billing model, which is much of what matters. However, with 0% schema coverage it leaves bypass_cache unexplained and says nothing about result shape or miss behaviour beyond the free/charged distinction.

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 0% for two parameters. The description implies the 'email' input but adds no format expectations, and 'bypass_cache' is completely undocumented in both the schema and the description, leaving an agent unable to judge when to force a fresh lookup.

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: reverse-look up an email address to find the person behind it, returning names and phone numbers from domain registration records. That is clear and distinguishable from verify_email, but the description never explicitly names verify_email or reverse_phone as the near neighbours an agent might confuse it with.

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

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

There is no when-to-use or when-not-to-use guidance. An agent has to infer from the phrase 'who is behind an email address' that this is an identity/attribution lookup rather than a deliverability check, and nothing tells it when to prefer verify_email or reverse_phone instead.

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 (readOnlyHint=false, idempotentHint=true, openWorldHint=true), and the description adds genuinely useful context beyond them: exact credit costs per tier and the fact that a null result is free. It also discloses the premium data source (domain registration records). It stops short of explaining what the tier or cache flags do to 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?

Compact and front-loaded: the core purpose leads, then tier definitions and pricing in tight parentheticals. Every clause earns its place, though the pricing parenthetical is dense enough to require a second read.

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 must carry more weight, and it partially does by naming the returned fields per tier (caller ID name, emails, phones). However, it says nothing about response shape, empty-result handling beyond 'free', or the two undocumented input parameters, leaving real gaps for a 4-parameter tool.

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

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

Schema description coverage is 0%, so the description carries the burden, and it only documents the tier parameter (standard vs premium). The phone, bypass_cache, and default_country parameters are unexplained in both schema and text; bypass_cache in particular is opaque given the credit-based pricing.

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 resource and outcome: identifying who is behind a US/Canada phone number, with a scope limit (US/Canada). It is clear enough to distinguish from reverse_email, but it never names siblings like carrier_lookup or validate_phone, so the agent must infer the boundary between 'who owns this number' and 'which carrier serves it'.

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 explains what each tier returns and costs, which effectively guides the standard-vs-premium choice, but there is no explicit when-to-use-this-tool versus alternatives (carrier_lookup, validate_phone, verify_contact) and no stated preconditions or exclusions. Usage context is implied rather than declared.

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 (idempotent, non-destructive, openWorld), so the bar is lower, and the description adds genuinely new context: the 1-credit cost and the country-code fallback requirement. It also enumerates the returned fields, which matters because there is no output schema. It does not explain caching behavior despite exposing bypass_cache.

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 tightly packed sentences with no filler; the output list and the country-code constraint are both front-loaded and immediately actionable. The output enumeration is slightly long but justified given no output schema exists.

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

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

For a stateless validation call with no output schema and no nested objects, the description covers inputs, output fields and cost adequately. The only meaningful omissions are the bypass_cache parameter and any note on latency or result caching behavior.

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 0%, so the description must carry the parameter burden. It explains `number` (the required param) and `default_country` with an example, adding real semantics beyond the bare schema, but `bypass_cache` is never mentioned, leaving one of three parameters undocumented.

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 (validate/check) plus resource (phone number) with an enumerated list of what is checked: validity, E.164, line type, region, time zone, carrier, VoIP, risk score, recommendation. It is clear what the tool does, but it never distinguishes itself from overlapping siblings like reverse_phone or carrier_lookup, so an agent cannot tell from the description alone which one to pick.

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

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

The description gives one input prerequisite (numbers without '+' need default_country) but no when-to-use guidance and no routing to alternatives such as reverse_phone or carrier_lookup, which cover adjacent phone data. With three sibling tools in the same domain, the absence of any selection criteria is a real gap.

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

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

Annotations cover the safety profile (idempotent, non-destructive, open-world) but the description adds genuinely new operational facts: results are match levels only, underlying records are never returned, and each call costs 1 credit. The credit cost is the most valuable disclosure for an agent planning calls.

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 operation, then the return contract, then the cost. No filler or restatement of the tool 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?

With no output schema, the description usefully defines the return shape (match / partial / no_match) and the credit cost, which is exactly what an agent needs here. The one gap is default_country, which neither the description nor the schema explains.

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 0%, so the description carries the full burden. It conveys that email identifies the records and name/phone are the compared fields, but default_country is never mentioned or explained, and no format hints (phone normalization, country codes) are given.

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 (check) plus the exact resource and comparison basis: name/phone against domain registration records that list the email. That scoping is distinctive enough to separate it from siblings like verify_email, reverse_email, and validate_phone.

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

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

The description implies the use case (contact verification) but never states when to choose this over verify_email, reverse_email, or validate_phone, nor any precondition or exclusion. The 'name and/or phone' phrasing hints at the inputs but not the routing 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 cover the safety profile (openWorldHint=true, idempotentHint=true, destructiveHint=false), and the description adds two pieces of context the annotations don't: the per-call cost ('1 credit') and the best-effort caveat that mailbox verification only happens 'when the server allows'. It still doesn't explain latency, failure modes, or why readOnlyHint is false for what reads like a lookup.

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

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

Two sentences, front-loaded with the verb and resource, then a compact enumeration of outputs plus the credit cost. The output list is long but each item carries information; nothing is padded.

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 so by listing every signal returned, including the accept/review/reject recommendation. It is only incomplete on the undocumented bypass_cache parameter and on error/timeout behavior.

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 0% for two parameters. 'address' is self-evident from its name, but 'bypass_cache' is never mentioned anywhere, so the description leaves half the parameter surface unexplained when it is the only source that could compensate.

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 (check/verify) and resource (email address) and enumerates exactly what is examined: syntax, mail server, mailbox, disposable, role account, typo suggestion, risk score, and a recommendation. That enumeration cleanly separates it from siblings such as reverse_email (which goes the other direction) and validate_phone/verify_contact.

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

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

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. An agent must infer that this is the tool for validating an address it already holds, which is implied but never stated.

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