ProWebLook

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine context beyond that: the cost of 1 caller-ID credit per call, which affects invocation decisions. It does not state whether credits are consumed on a not-found result or what the response contains on failure.

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

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

Two sentences with zero waste; the core purpose is front-loaded before the cost note and use case. Every clause earns its place.

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

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

For a single-parameter read tool with no output schema and annotations covering the safety profile, the description supplies purpose, cost, and use case. The remaining gap is failure/unknown-number behavior and whether a credit is still charged, which an agent would need for reliable 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% and the single parameter documents both E.164 and local formats, so the schema does the heavy lifting. The description adds no format or constraint detail beyond what the schema already 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?

The description names a specific verb and resource (reverse phone lookup retrieving CNAM for a phone number), which is unambiguous and clearly separable from siblings like validate_phone or check_whatsapp. It stops short of explicitly naming those siblings as alternatives, so it is clear but not sibling-differentiating.

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 identify who owns a number" gives an implied use case but no explicit when-not guidance or named alternatives (e.g., validate_phone for validity vs. this for ownership). The agent must infer selection among the many phone-related siblings.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds real behavioral value beyond them: the 1-credit-per-successful-check cost model and the fact that results are returned per-source plus an overall summary. Return/pagination details for large source sets are the only gap.

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

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

Four sentences, all carrying distinct payload (target scope, return shape, cost, use cases) with no filler, and the core purpose is front-loaded. Slightly dense but every sentence earns its place.

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

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

For a read-only, 3-parameter lookup with no output schema, the definition covers the target types, the source-selection option, the cost, and the shape of the result. An agent has enough to call it correctly; only the detailed per-source response format is unspecified.

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

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

Schema description coverage is 100%, so all three parameters, including the sources override and the target_type enum with 'auto' default, are already documented in the schema. The description adds no syntax or format detail beyond that, which is the expected baseline 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 ('Check') and resource ('IP address, domain, or URL against major global blacklists and spam databases (DNSBL/RBL sources)'), plus what it returns. It is clearly distinguishable from most siblings, though it never explicitly contrasts itself with the closely related check_spam_score.

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 usage contexts ('deliverability debugging, reputation checks, and abuse triage') so an agent knows when to reach for it. It offers no exclusions or named alternatives, so it lands at clear-context-without-routing rather than a full 5.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description's disclosure of a cost ('1 spam-checker credit per successful request') is genuine added value beyond structured data. It also describes the return shape (score, risk level, per-trigger breakdown), which matters since no output schema exists. No auth or pagination detail, so not a 5.

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

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

Three sentences, front-loaded with the capability and outputs, then cost/usage, then the input constraint. No filler or repetition of the tool name; every sentence adds 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 two-parameter read-only tool with no output schema, the description covers purpose, outputs, cost, intended timing, and the input precondition. An agent has everything needed to decide and invoke correctly.

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

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

Schema coverage is 100% so the per-parameter docs already carry baseline weight, but the description adds a real semantic constraint the schema does not enforce: at least one of subject or content must be provided (required is 0 in the schema). That constrains invocation behavior beyond what the structured fields say.

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 (Analyze) and resource (email subject/body text for spam trigger words) and names the exact outputs (0-100 score, risk level, per-trigger breakdown). This clearly separates it from siblings like verify_email or check_blacklist without needing to open 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?

Explicitly states the use case ('Use before sending marketing/transactional email to predict deliverability') and the input precondition ('At least one of subject or content must be provided'). It lacks an explicit when-not or a named alternative sibling, so it stops short of 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely non-redundant behavior: no message or OTP is sent, billing is '1 WA credit per successful call' (implying failed calls are free), and the enrichment data returned. It stops short of covering failure modes or invalid-number 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?

One dense paragraph, front-loaded with purpose, then side-effect clarification, cost, and return fields in descending priority. Every sentence carries information an agent needs; 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?

With no output schema, the description correctly compensates by naming the key return fields (numberstatus, businessnumber, carrier/line type/country) and disclosing cost. It is close to complete, missing only error/invalid-number behavior and a nod to the batch sibling for bulk work.

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

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

Schema description coverage is 100%, with both phone_number (E.164 or local) and country_code already fully documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('Check whether a phone number has an active WhatsApp account') and immediately scopes it further with the Business-account variant. It is clearly distinguishable from siblings such as validate_phone and whatsapp_batch_submit, which do number validation and batch submission respectively.

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 clause 'without sending any message or OTP' tells the agent this is a non-invasive check, which is useful implied usage context. However, no alternative is named (validate_phone, whatsapp_batch_submit, whatsapp_batch_status) and there is no explicit when-to-use/when-not-to-use guidance, leaving routing 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=true and openWorldHint=true, so safety is covered. The description adds a genuinely useful behavioral fact beyond that: the call deducts from the caller's Geo-IP quota, which is a cost signal the agent can't get from structured fields. It omits rate-limit specifics and failure modes.

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

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

Three tight sentences, front-loaded with what is returned, then the cost caveat, then use cases. No filler and nothing 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?

A one-parameter read-only lookup with readOnlyHint/openWorldHint annotations is well covered: the description lists the returned fields (compensating for the absent output schema), states the quota cost, and gives usage contexts. Nothing essential to calling it correctly is missing.

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

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

With a single parameter at 100% schema description coverage, the schema fully documents `ip` including the IPv4/IPv6 format and an example. The description only confirms the accepted address types, adding marginal meaning 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 (look up) and enumerates the resource returned: geolocation, ISP, organization, country, region, city, coordinates, timezone, ASN for an IPv4/IPv6 address. This is distinguishable from the phone/email/social siblings 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?

Names concrete use cases (traffic analysis, fraud checks, localizing users), giving the agent a clear context in which to reach for it. It does not, however, name alternatives or exclusions (e.g. when to prefer check_blacklist or check_spam_score instead), so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the call is free and consumes no credits, and balance data is available elsewhere in other tool responses.

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?

It is front-loaded with the core action, then the free/credit note, then the routing guidance. The only waste is the redundant enumeration of the four enum values already listed in 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 one-parameter read-only lookup with no output schema, the description covers purpose, cost, supported scope, and where else balance appears. An agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and the single parameter has an enum, so the schema already fully documents 'service'. The description merely restates the same four enum values, adding no syntax or format detail beyond the schema. 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 states a specific verb and resource: 'Check remaining ProWebLook API credits for a service.' It also distinguishes itself from siblings by noting that most other tools return the balance inside their own responses, so an agent can route correctly 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?

It gives clear scope ('Only these services are supported here: ...') and an implicit when-not rule ('Most other tools ... return your remaining balance inside their own responses'), which steers the agent away from over-calling this tool. However, it never states the positive trigger in an explicit 'use this when' form, so some inference is required.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description earns credit for adding the async-polling behavior, the free-to-call fact, and the contents returned at each detail level. It stops short of describing rate limits or how long audit results persist, which keeps 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?

Three tight sentences, front-loaded with what the tool does, then the polling instruction, then the completion follow-up. 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 present, the description enumerates the return payload (progress and job_status at summary; visibility score, per-LLM coverage, competitive benchmarking, query results, recommendations at full), so an agent knows what to expect at both stages.

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 baseline is 3; the description goes further by explaining the semantic difference between the two enum values and when each applies, and by tracing audit_id back to run_brand_audit. That is real added meaning over 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 ('Get the status/results of an AI Visibility Audit by audit_id') and implicitly distinguishes itself from run_brand_audit and list_brand_audits by dealing with a single existing audit. An agent can select it without opening the schema.

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

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

Gives an explicit two-phase workflow: poll with detail "summary" while the job runs, then re-call with detail "full" once job_status is "completed". It also notes the call is free, removing cost hesitation.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely new behavioral facts: the 90-data-point cap and that the call is free, plus the dependency on a prior audit. It does not explain ordering, gaps, or granularity of the trend points.

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 with zero filler; the resource and data cap are front-loaded, the cost note and usage cue follow. 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?

With no output schema, the description adequately signals the return shape (a historical trend series, capped at 90 points) and the precondition for calling it. Missing only minor detail such as cadence or ordering of the data points.

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

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

Schema coverage is 100% and both parameters are documented in the schema. The description reinforces that brand/domain must match past audits, but adds no syntax or format detail beyond 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+resource ('Get the historical AI-visibility score trend') with scope ('up to 90 data points') and a clear precondition ('brand + domain that has been audited before'). It implicitly separates itself from the audit siblings but never names get_brand_audit or list_brand_audits 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 show visibility change over time' gives clear when-to-use context, and the 'has been audited before' clause states a prerequisite. It stops short of naming alternatives (e.g., a single-snapshot audit) or stating when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the 1-scraper-credit cost per successful call and the fact that replies/comments are returned where available. It omits failure modes, rate limits, and auth/prerequisite details, keeping it short of a 5.

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

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

Two tightly written sentences with zero filler; the core action and scope come first, with the cost caveat appended where it belongs. Nothing redundant with the schema 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?

For a read-only fetch tool with up to two well-documented parameters and no output schema, the description covers what is retrieved (full content plus replies/comments) and the per-call cost. It is nearly complete; only edge-case behavior (private, deleted, or unsupported URLs) is left unstated.

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

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

Schema description coverage is 100%, so both parameters (url and platform with its enum and default) are already fully documented by the schema. The description adds only the constraint that the post must be public and referenced by its URL, which is marginally beyond the schema. Baseline 3 applies.

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

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

The description gives a specific verb (fetch), resource (a single public post), the supported platforms (Reddit, X, LinkedIn), and the input form (by URL), plus the useful scope note that replies/comments are included where available. It is clearly distinct from search_social (search) and scrape_url (generic), though it never names a sibling to route the agent 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?

Usage is only implied: an agent can infer it should be used when it already has a specific public post URL. There is no explicit when-to-use vs. alternatives guidance, no statement of when not to use it (e.g., private/deleted posts), and no routing to search_social for discovery.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds non-obvious cost semantics (1 scraper credit per successful call), which is genuinely useful context an agent cannot get from structured fields. It stops short of describing return shape or pagination limits for top-level items vs comments.

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: purpose, cost, and workflow. Front-loaded with the action and resource, then the cost, then usage. 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 read-only, no-output-schema tool this covers the essentials: what it returns conceptually, its cost, and its place in the workflow. The one gap is not clarifying the relationship between maxItems and maxComments or the shape of the returned thread, which matters for a comment-fetching tool with two pagination-style params.

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 url, maxItems, and maxComments are already documented with defaults. The description adds no parameter-level detail beyond reinforcing that url is a single post URL. 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+resource (fetch comments/replies for a single X post URL) with clear scope limited to one post. An agent can distinguish this from get_social_post (the post itself) and search_social (discovery) 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?

Explicitly names the prerequisite workflow: find a post via search_social (platform "x"), then use this tool to read its discussion thread. It supplies both when-to-use and the alternative that precedes it, 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 cover readOnly and openWorld safety. The description adds genuine value beyond them by disclosing the credit cost ('1 SERP credit per successful search', implying failed searches do not bill) and the pagination constraint. It omits rate limits and error behavior, but with annotations present the bar is lower.

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 front-loaded sentences that are tight and useful. The final pagination sentence is mildly redundant with the schema but is short and scenario-relevant, so little 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 compensates by naming the returned fields and format (JSON). Combined with the cost disclosure, use cases, and pagination rule, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100% — every parameter carries its own description with ranges, defaults, and enum values. The description's pagination note ('start must be a multiple of 10') merely restates the schema's multipleOf constraint, so it adds no meaning beyond structured data. 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 ('Run a Google search') and enumerates the returned fields (title, URL, snippet, position) as JSON. This is clearly distinguishable from the unrelated sibling tools (email, phone, blacklist, social checks).

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

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

Gives explicit use cases — rank tracking, competitor research, finding sources on a topic. It does not name an alternative tool or state when not to use it, but no sibling overlaps this capability, so the guidance is contextually adequate.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds two genuinely new traits: it is free to call (cost/billing behavior) and results are returned newest-first, neither of which is derivable from the annotations or 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 with zero filler: purpose first, then cost, then the motivating use case. Each sentence carries distinct information and nothing is repeated from the schema 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?

For a simple two-parameter list tool with no output schema, the description covers purpose, pagination, ordering, and cost. It does not hint at what an audit record contains beyond audit_id, which is a minor gap given no output schema exists to compensate.

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% (page and per_page are both documented with ranges), so the baseline is 3. The description adds the result ordering ('newest first'), which is not in the schema and materially affects how an agent interprets and navigates page numbers.

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 ('List this account's past AI Visibility Audits') plus scope and ordering ('paginated, newest first'). The phrase 'instead of re-running an audit' implicitly distinguishes it from the run_brand_audit sibling and from get_brand_audit's single-record fetch.

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 a concrete use case: finding an earlier audit_id rather than re-running (and re-paying for) an audit. That is effectively a when-to-use condition pointing away from run_brand_audit, but there is no explicit when-not-to-use or direct sibling naming.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds the high-value context those annotations cannot express: credit consumption, asynchronous execution with an immediate audit_id return, multi-minute latency, the polling contract, and 24h cache behavior. This is exactly the behavioral context an agent needs to sequence 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?

Four sentences, each carrying distinct, non-redundant information: purpose, cost, async contract, and caching. The most decision-critical facts (cost, return shape) are front-loaded ahead of the polling instructions.

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: it names the returned audit_id, explains job_status polling, and directs the agent to detail 'summary' then 'full'. Combined with 100% schema coverage, an agent has everything needed to call and follow up correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema and the baseline is 3. The description adds no parameter-level detail beyond what the schema provides (the competitor benchmarking mention maps to the existing 'competitors' param).

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

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

Opens with a specific verb+resource ('Start an AI Visibility Audit') and immediately scopes it: measures brand visibility in AI assistant answers across a query set, with competitor benchmarking. This is clearly distinguishable from siblings like get_brand_audit, get_brand_trend, and list_brand_audits.

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 the cost ('Costs 1 audit credit'), that it is asynchronous, and gives the exact follow-up workflow: poll get_brand_audit with detail 'summary' until job_status is 'completed', then fetch detail 'full'. It also names the caching condition (identical requests within 24h). No inference required.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the 1-credit cost model (per successful request regardless of format count), differentiated latency (~5-15s for Chromium screenshot vs ~1-5s for other formats), and that screenshots arrive as an image attachment. These are exactly the operational traits an agent needs to plan around.

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 sentences, each earning its place: capability, cost, latency, use cases. The capability and payload are front-loaded, and there is no restatement of the tool name or schema fields.

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 5-parameter, no-output-schema tool with read-only annotations, the description covers capability, cost, timing and payload form well. It stops short of mentioning error/edge behavior (non-2xx pages, blocked or JS-only sites, timeout semantics) that an agent invoking against arbitrary URLs would benefit from.

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 real semantics on top: it explains that cost is flat regardless of how many formats you request, and that choosing the screenshot format carries a disproportionate time cost. That trade-off context is not derivable from the enum list alone.

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

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

States a specific verb and resource (scrape any web page) and enumerates the exact outputs — Markdown, rendered/raw HTML, links, SEO metadata, screenshot — so the agent knows precisely what it gets back. This is clearly distinguishable from siblings like google_serp or get_social_post, which return search/social data rather than raw page content.

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 final sentence gives concrete use cases (reading article content, extracting metadata, link discovery, visual captures), which tells the agent when this tool is appropriate. It does not, however, name an alternative tool or state when NOT to use it (e.g. prefer google_serp for query-style discovery), so the routing guidance is clear but not exhaustive.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavior: a cost of 1 scraper credit per successful search (implying failed searches may not be charged) and an outline of the returned shape (title/text, author, URL, engagement, meta). It stops short of detailing rate limits or per-platform behavioral quirks.

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 compact sentences: capability and scope first, then return shape and cost, then use cases. No redundancy and every sentence adds an actionable fact.

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 summarizes the return shape and discloses the credit cost, which is the key operational fact for a paid scraping call. It is nearly complete; only cross-platform differences (e.g. which sort values each platform honors) are left implicit.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including defaults, enums, and the Reddit-only subreddits constraint. The description adds no syntax or format detail beyond what the schema provides, which is the expected baseline when structured fields carry the load.

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 (search) and resource (public posts) and enumerates the exact platforms (Reddit, X, LinkedIn) plus the input mode (keyword). An agent can distinguish it from the sibling get_social_post (fetch a single post) and get_x_comments without opening the schema.

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

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

Explicitly names intended use cases (social listening, market research, finding discussions about a topic or brand), which gives clear context for selection. However, it does not state when NOT to use it or name an alternative sibling for single-post retrieval, so routing guidance is contextual rather than exclusive.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered structurally. The description adds genuinely new operational context: a billing cost of 1 phone-validation credit per successful call, and that enrichment is returned as part of the operation. It omits failure modes and what happens on an invalid 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?

Two sentences, front-loaded with the verb and returned fields, then cost, then usage condition. Every clause carries information and nothing is 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?

With no output schema, the description usefully enumerates the enriched fields an agent can expect, and it discloses the cost, which is material for a metered tool. It stops short of covering error behavior or output structure details, but is adequate for correct invocation.

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

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

Schema coverage is 100%, so both parameters (phone_number, country_code) are fully documented in the schema with format and E.164 guidance. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (validate) plus the resource (phone number) and enumerates the enrichment payload (carrier, line type, country, location, timezone, formatting). An agent can distinguish this from check_spam_score or caller_id_lookup on the stated purpose alone.

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

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

"Use when you need to know whether a number is real, who operates it, or where it is registered" gives clear triggering conditions. It does not explicitly exclude or route to siblings such as check_spam_score, check_whatsapp, or caller_id_lookup, so the guidance is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful context the annotations cannot convey: a cost of 1 email credit per successful check (noting that failures are free) and the single-address throughput limit. It omits any statement of accuracy or latency, which keeps 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 sentences, front-loaded with what the tool does and what it checks, then cost and usage in the second. Every clause carries information an agent needs; nothing is restated from the name or 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?

With no output schema, the description carries the burden of return-value semantics, and it partially does so by naming the four check dimensions a caller can expect results on. It does not describe the result shape or status vocabulary (e.g., deliverable vs. risky vs. undeliverable), which is the one gap for an agent that must interpret the response.

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

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

There is only one parameter and schema description coverage is 100%, so the schema fully documents 'email'. The description adds no format, normalization, or edge-case guidance beyond what the schema already says, which is the baseline case for a fully covered simple parameter.

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

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

States a specific verb ('Verify') and resource ('an email address') and then enumerates exactly what verification covers: syntax, MX records, SMTP deliverability, and disposable-address detection. No sibling tool performs email validation (validate_phone is a distinct resource), so the scope is unambiguous to an agent scanning the tool list.

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 usage contexts ('validate signup emails or clean mailing lists') and an important operating constraint ('one address at a time'), which steers an agent away from attempting bulk use. It stops short of naming an alternative or an explicit when-not-to-use condition, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint, so the read-only nature is covered. The description adds value beyond that by disclosing cost ('Free to call'), the recommended polling rhythm, and that results appear only after completion. It stops short of describing possible status values or error states, so it is strong but not exhaustive.

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 followed by cost, cadence, and completion condition. Nothing is redundant and every clause carries operational 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 one-parameter read-only poller with no output schema, the description covers purpose, cost, timing, and termination, which is most of what an agent needs. It could go slightly further by sketching the result payload or possible non-terminal statuses, but nothing critical is missing.

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

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

Schema coverage is 100% and the single batch_id parameter is fully described there (UUID returned by whatsapp_batch_submit). The description adds no parameter-level detail beyond restating the source of the ID, 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 (poll) and resource (status/results of a WhatsApp batch validation job) and ties it to the sibling that creates the job (whatsapp_batch_submit). An agent can distinguish it from the other whatsapp_* tool 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 concrete when-to-use guidance with polling cadences (5-10s for small batches, 30-60s for large ones) and the stop condition (until status is "completed"). It also names the originating tool, so the alternative path (submitting a new batch) is implicit and clear.

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

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing the cost model (1 WA credit per number, deducted upfront), the all-or-nothing failure mode when balance is insufficient, and the immediate return shape (batch_id with status "processing"). These are exactly the side effects an agent must know 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?

Three tight sentences, front-loaded with capability then cost then return/next-step. Every sentence carries distinct, actionable information with no filler.

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

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

No output schema exists, yet the description covers the return value (batch_id, "processing" status) and the follow-up tool, plus the billing consequence. An agent has everything needed to call and continue the workflow correctly.

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

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

Schema coverage is 100% and the single parameter already documents the 1,000 max and automatic duplicate removal, so the description's restatement of the limit adds little. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

States a specific verb (submit), resource (phone numbers), and scope (up to 1,000, asynchronous WhatsApp validation), which cleanly separates it from the single-number sibling check_whatsapp and from the retrieval sibling whatsapp_batch_status.

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 routes the agent to whatsapp_batch_status for retrieving results, and the credit warning frames when to be careful with large batches. It stops short of saying when to prefer a single-number check over a batch, so usage context is clear but not fully exhaustive.

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