Abstract API MCP by usefulapi

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely non-derivable operational context: it consumes 1 credit of the VAT Validation plan per request (including failed requests) and requires the VAT Validation API key. It does not mention error conditions such as unsupported country codes, keeping it from 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?

The core purpose is front-loaded in the first sentence, the reverse-calculation note follows immediately, and the cost/auth note closes it out. Every clause carries information; there is no filler.

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

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

With no output schema, the description correctly compensates by naming the return values, and it covers billing and auth prerequisites. Given the tool's simplicity and full schema coverage, an agent has what it needs; only edge-case behavior (invalid country, reduced-category fallback failures) 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 all four parameters (amount, country_code, is_vat_incl, vat_category) are already documented in the schema, which sets the baseline at 3. The description's restatement of is_vat_incl as the 'reverse calculation' adds only a slight gloss on the existing schema text and no new constraints.

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

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

The description uses a specific verb+resource ('work out the VAT-compliant price for an amount in a country') and even enumerates the returned quantities (net, gross, VAT amount, rate), so the agent knows exactly what the tool produces. It does not explicitly distinguish itself from the closely related sibling abstractapi_validate_vat, so it stops 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?

It states the reverse-calculation mode ('set is_vat_incl to true'), which is useful conditional guidance, but that is parameter-level rather than tool-selection guidance. There is no statement of when to use this tool instead of abstractapi_validate_vat or abstractapi_list_vat_rates, so usage is only 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 declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuinely new operational context: 1 credit consumed per request including failures, and the Exchange Rates API key requirement. It stops short of describing the response 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 tight sentences, front-loaded with the core action and immediately followed by cost/key constraints. No filler or repetition of the schema.

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

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

For a read-only conversion call with full schema coverage and rich annotations, the description covers cost, auth, and the date/latest-rate choice. With no output schema, it could mention what comes back (converted amount and rate), but this is a minor 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%, so base, target, date, and base_amount are already documented with patterns and defaults. The description echoes 'base', 'target', 'amount', and 'past date' without adding format, multi-currency, or amount-limit details beyond the schema, 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?

Names a specific verb (convert) and resource (currency amount) with scope qualifiers: 'from a base currency to one target currency'. It implicitly separates itself from get_exchange_rates/get_historical_rates by converting an amount rather than listing rates, but it never names those siblings 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?

It gives context for the two modes (latest rate vs a past date) and discloses the credit cost and API key requirement, which guides the decision to call. However, it never states when to prefer this over abstractapi_get_exchange_rates or abstractapi_get_historical_rates, so the routing choice 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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful operational context the annotations do not: one credit consumed per request, failed requests still billed, and a Timezone API key requirement.

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 conversion behavior and constraints. The standalone 'Timezone API.' fragment is slightly wasteful but harmless, and nothing important is buried.

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

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

For a 3-parameter read-only tool with no output schema, the definition covers purpose, default behavior, billing, and auth. The only real gap is the shape of the returned converted datetime, which the absence of an output schema makes less critical.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks by clarifying what a 'location' can be (place name, coordinates, or IP address). It does not, however, elaborate on the datetime pattern or the maxLength bounds.

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 ('Convert a date and time from one location to another') and broadens the input space to 'places, coordinates or IP addresses.' It does not explicitly distinguish itself from the sibling get_current_time, which the default-to-now behavior superficially overlaps with, so sibling differentiation is only implicit.

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 explains the fallback ('Without base_datetime the current time is converted') and the cost/credential requirements, which implies when this tool applies. However, it never states when to prefer it over get_current_time or how it relates to the other timezone siblings, leaving alternative selection 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful context they cannot convey: per-request credit consumption, that failed requests also consume credits, and the required API key.

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 returned data, then tacks on plan/credit/auth notes in a compact set of clauses. Every sentence carries information; only slight compression could improve it.

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 listing the fields returned, and it covers auth and billing. It is nearly complete for a single-purpose, two-parameter enrichment call, though it does not detail the shape of range-type fields.

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 'domain' and 'fields' fully, including URL normalization and the key-list pattern. The description's field enumeration loosely corresponds to the 'fields' filter but adds no syntax or format 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+resource ('Firmographic data for a company web domain') and enumerates the returned data categories, making it instantly distinguishable from the validation, lookup, currency and holiday siblings. An agent knows exactly what this yields 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?

Gives clear operational context — it is the Company Enrichment API, costs 1 credit per request (including failures), and requires the Company Enrichment API key. However, it never names an alternative or states when-not to use it relative to other abstractapi tools.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds value the annotations cannot: per-request credit cost (including failed requests) and the API key requirement, plus the shape of the returned timezone 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 dense sentences with zero padding; the returned fields come first and the cost/auth constraints second. Every clause carries information the agent needs.

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 the return contents (name, abbreviation, GMT offset, DST) and covers cost and authentication. Minor gap: no mention of failure/error semantics beyond the credit note.

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 location parameter is fully documented in the schema, so baseline 3 applies. The description restates the accepted input forms but adds no format or syntax 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 resource and scope: the current local date/time/timezone for a place, coordinates, or IP. The input forms (place name, lat/long, IP) are named, and 'current' implicitly opposes sibling convert_time, though no sibling is explicitly named.

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 explicit when-to-use vs convert_time or exclusions, but it does state the practical preconditions: it consumes 1 credit per request including failures and requires the Timezone API key. That is genuine usage context, just not 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, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful operational context the annotations cannot: a per-request credit cost, that failed requests also bill, and that an Exchange Rates API key is required.

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 the core purpose front-loaded, followed by billing and auth constraints. No filler, though the trailing 'Exchange Rates API' fragment is slightly 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 tool with full schema coverage and no output schema, the description covers purpose, default behavior, cost, and auth. Return-value shape is unaddressed, but that is acceptable for a simple rates endpoint.

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 both parameters (base, target) are already fully documented with ISO codes and comma-separated format. The description only restates the 'all supported currencies if none is given' default, which the schema already conveys with 'Omit for all.' Baseline 3.

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

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

The description gives a specific verb and resource: fetching latest foreign-exchange and cryptocurrency rates for a base currency against targets. The word 'Latest' implicitly separates it from get_historical_rates, but no sibling is named explicitly, so the differentiation is left to inference.

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 only implied — it is a rates-fetching tool and the default-all-targets behavior is stated. There is no explicit guidance on when to choose this over convert_currency or get_historical_rates, which is the main ambiguity an agent faces here.

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

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

Beyond the read-only/idempotent/non-destructive annotations, the description discloses substantial behavioral context an agent cannot infer: closed-beta status with possible 401/403 refusal until enabled, a 1-credit cost that applies even to failed requests, and the required Exchange Rates API key. This is exactly the auth/cost/error disclosure the dimension rewards.

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 in the first sentence, followed by the caveats that matter most. The prose is slightly choppy ('Exchange Rates API.' is a bare fragment) and could be tightened, but nothing is padding.

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

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

For a read-only lookup with fully documented parameters and an annotations set covering the safety profile, the description is nearly complete, adding beta, auth and cost context. It does not describe the response shape, which matters slightly more here since there is no output schema, but the omission is modest.

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 all three parameters (base, date, target) documented including patterns and examples, so the baseline is 3. The description adds no syntax, format, or edge-case meaning beyond what the schema already conveys.

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: fetching exchange rates for a base currency on a past date. The 'past date' scoping implicitly distinguishes it from the current-rates sibling get_exchange_rates, but it never names that sibling or any other alternative, so differentiation is left to inference.

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 only implied via the 'past date' framing and the closed-beta caveat. The description never says when to prefer this over get_exchange_rates or convert_currency, nor does it name an alternative — but the beta and credit-cost notes do inform whether an agent should call it at all.

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 open-world, and the description adds genuinely new operational context: one credit is spent per request (failed requests included) and the Public Holidays API key is required. Cost and auth requirements are exactly the details 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?

Three sentences, front-loaded with the resource and granularity, followed by the plan constraint and cost/auth note. The bare fragment 'Public Holidays API' is redundant padding against the tool name and title, but nothing else 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 still identifies what is returned (holidays of a type, for a scope) well enough to call the tool. It covers scoping, plan constraints, cost and credentials; only the response shape is left implicit, which is a minor 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%, so the baseline is 3, but the description adds semantics the schema lacks: the free-plan requirement that year/month/day be supplied together and the paid-plan rule that omitted values default to today. That is meaningful behavior beyond the per-field descriptions.

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 — returns public, local and religious holidays for a country at day, month or year granularity — and the granularity is spelled out. Siblings are all in unrelated domains (VAT, currency, IP), so there is no ambiguity to resolve, but the scope is nonetheless 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?

Gives concrete plan-dependent usage rules: free Abstract plans require year, month and day together, while paid plans default missing values to today. It does not name exclusions or alternatives, but no sibling overlaps this resource, so the practical when-to-use condition is 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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious operational context: Abstract may answer this endpoint without validating the key and may not count it as a credit, while the tool still requires the VAT API key. That is exactly the kind of detail 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?

The purpose sentence is well front-loaded, but the dangling fragment 'VAT Validation API.' adds no information and reads like boilerplate pasted in. The auth/credit sentence is long and could be tightened, so the description is merely adequate in structure.

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 usefully describes what is returned (standard rate + reduced-rate categories with descriptions) and flags the key/credit quirk. Only minor gaps remain, such as coverage of unsupported country codes and error responses.

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 a format example (DE), so the schema does the heavy lifting and baseline 3 applies. The description adds nothing about country_code semantics (e.g., unsupported countries or error behavior), so no credit above 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 (list) and resource (latest VAT rates of one country) and even previews the payload: standard rate plus each reduced-rate category with its description. It does not, however, differentiate itself from close siblings like abstractapi_validate_vat or abstractapi_calculate_vat, so an agent must infer the split itself.

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 by the wording (use when you need the current rate table for a country), but there is no explicit when-to-use versus when-not-to-use guidance and no callout to sibling tools. The key/credit note is a prerequisite, not selection guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds information they cannot: a 1-credit cost per request including failures, the required IP Intelligence API key, and the default-address behavior when ip_address is omitted. That is exactly the kind of context an agent needs before invoking.

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-loaded with the capability and its output surface, then the two operational constraints (required parameter, credit cost). Dense but every clause carries information; the trailing 'IP Intelligence API' label is the only near-redundant fragment.

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 mostly discharges it by naming the signal categories, plus cost and auth requirements. It stops short of describing response shape or edge cases like invalid-address failures, which keeps it out of the top band.

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, and the description earns an upgrade by explaining why ip_address is mandatory (the server's own address would otherwise be resolved) rather than merely restating that it is required. The fields parameter's section semantics are left to 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 ('Geolocation and security intelligence for one IPv4 or IPv6 address') and enumerates the returned signal classes (VPN/proxy/Tor/hosting/abuse flags, ASN, company, location, timezone, flag, currency). No sibling does IP lookup, so the tool is unambiguous within the set.

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 conditions usage on supplying an explicit ip_address and explains the fallback behavior that makes it necessary (otherwise the caller's own address is looked up, which here is the server's). It does not name alternatives, but there is no competing sibling for this resource, so the gap is minor.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the description justifiably focuses on extra behavior: it discloses that each request spends 1 credit and that failed requests also count, plus the API key requirement. It does not describe rate limits or response shape, but the billing/auth disclosure is genuinely useful context beyond annotations.

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

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

Front-loaded with the core action and its outputs, followed by two short clauses for billing and auth. Slightly dense but every sentence carries information; 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?

With no output schema, the description helpfully enumerates the enrichment fields an agent can expect, and it covers cost and credential prerequisites. What it lacks is any statement of when to prefer this over sibling tools, a minor gap for a clearly-scoped lookup.

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

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

Schema description coverage is 100%, so the schema already documents both parameters including the country code rule and phone format. The description adds no syntax or format guidance beyond what the schema provides, making the baseline 3 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 specific verbs (validate and enrich) plus the resource (a phone number) and enumerates the returned facets: format, carrier, line type, location, line status, risk, and breaches. This clearly distinguishes it from siblings like validate_email, validate_iban, and lookup_ip, which target different resources.

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 by the resource rather than stated: no explicit when-to-use, when-not, or named alternatives among the sibling validators/lookup tools. It does add useful prerequisites (Phone Intelligence plan and API key), which partially compensates.

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 open-world traits, so the description correctly focuses on what they don't cover: it discloses that each request spends one credit (including failed requests) and that the Email Reputation API key is required. It stops short of rate-limit or failure-mode detail, keeping it below 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?

Two well-packed sentences, front-loaded with capability and followed by billing/auth constraints. No filler, though the API-product name ('Email Reputation API') is slightly redundant with the cost sentence that follows.

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 lists the categories of data returned (deliverability, score, flags, sender, breaches), and it covers cost and auth. For a single-parameter read-only tool with annotations handling the safety profile, this is essentially 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 100%, and the single 'email' parameter is fully documented in the schema itself. The description adds only the single-address constraint ('one email address'), which is marginal beyond what the schema already conveys.

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 (Check/Validate) and resource (one email address) and then enumerates the exact checks performed: format, MX, SMTP deliverability, quality score, and reputation flags. An agent can distinguish it from the sibling validators (validate_iban, validate_vat) 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?

'Check one email address' establishes the single-address scope, and the cost/key sentences frame the operating context (Email Reputation plan). There are no true alternative siblings for email validation to route against, but no explicit when-to-use or when-not guidance is offered either.

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 the description adds genuinely new behavioral facts the structured data cannot carry: the per-request credit cost (including on failure), the API-key prerequisite, and the crucial semantic limit that a pass does not confirm the account exists. That last point prevents an agent from over-interpreting a success.

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-loaded with the action and its limitation, then the cost/auth constraints. Efficient, though the fragment 'IBAN Validation API.' is mild padding that repeats the product name already implied by 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?

Covers purpose, cost, credentials, and the interpretation caveat for a single-parameter tool with no output schema. It does not hint at the shape or fields of the response, which is the one thing an agent must infer since no output schema exists.

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's format hint ('with or without spaces') lives in the schema. The description adds nothing about the iban argument, 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 ('Check the structure and check digits of one IBAN') and immediately bounds the claim with 'It does not prove that the account exists.' This distinguishes it from every sibling, none of which touch IBANs.

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 operational context: one credit per request, a failed request still counts, and the IBAN Validation API key is required. It does not name an alternative tool, but no sibling offers IBAN validation, so there is nothing to route against.

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 and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context: it costs 1 credit per request (including failures) and requires the VAT Validation API key, which matters for how an agent should budget 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?

Front-loads the purpose and return value in the first sentence, then tacks on cost and key requirements. Mostly efficient; the fragment 'VAT Validation API.' is redundant filler that could be dropped.

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

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

For a one-parameter read-only lookup with no output schema, the description covers purpose, return fields, cost, and auth requirements. It stops short of noting any error/edge-case behavior (e.g. unrecognized country prefix), but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100% for the single parameter, and the schema already documents the country-prefix format and example. The description adds no syntax or format detail beyond it, 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 ('Check whether a VAT number is valid') plus the value returned (registered company name and address), which separates it from siblings like abstractapi_calculate_vat and abstractapi_list_vat_rates. An agent can tell what it does 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?

Usage is implied by the verb 'validate' and the return description, giving clear context for what the tool is for. However, it never explicitly says when to prefer this over siblings such as calculate_vat or list_vat_rates, or what prerequisites/invalid-input behavior look like.

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