Veriq

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

No annotations exist, so the description carries the full burden. It usefully discloses the fields returned, which substitutes partially for the missing output schema, but says nothing about rate limits, auth requirements, error behavior for unregistered domains, or latency.

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

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

Two short sentences, front-loaded with the capability before the use case. No filler, though it is terse enough that it could have afforded one clause on input format.

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 lookup with no annotations and no output schema, the description covers what comes back but omits input expectations and failure modes. Adequate, not complete.

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

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

Schema description coverage is 0% and the description adds nothing about the single 'domain' parameter — no format, TLD expectations, or whether subdomains or URLs are accepted. The parameter name is self-evident but the description does not compensate for the coverage gap.

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

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

Names a specific verb+resource (domain lookup) and enumerates the returned intelligence: age, registrar, expiry, mail provider, SPF, DMARC. This clearly separates it from generic validation siblings, though it never explicitly contrasts itself with lookup_ip or validate_contacts.

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?

'Good for vetting a company' implies a use context but gives no when-not conditions, prerequisites, or pointers to alternative tools like lookup_ip. Usage is inferable, not stated.

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

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

Annotations are absent, so the description carries the full behavioral burden. It usefully discloses what data is returned (and no output schema exists to carry that), but says nothing about rate limits, auth requirements, or accepted input form (IPv4 vs IPv6), leaving real gaps for a network-calling tool.

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 sentence, front-loaded with the resource and immediately followed by the concrete data points. Every clause earns its place 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?

For a single-parameter lookup with no output schema, the description does the important work of enumerating the returned fields, which is exactly what the agent needs to judge relevance. Its only shortfall is omitting input-format expectations.

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

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

Schema description coverage is 0% and the single required 'ip' parameter has no schema title or description beyond the name. The description never mentions the input at all, so it does not compensate — an agent gains no information about accepted IP formats or validation.

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 ('IP intelligence') and enumerates the returned signals (ASN/network owner, country, reverse DNS, Tor/VPN/data-center flags), so an agent can tell it apart from lookup_domain. It does not explicitly name the sibling, but the 'IP' scope makes the distinction clear in practice.

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

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

No when-to-use guidance, no exclusions, and no reference to alternatives such as lookup_domain. The word 'intelligence' implies a read lookup, but nothing tells the agent when this is the right tool over its 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?

With no annotations, the description carries the full burden and does so: per-call credit costs (3 credits for Ghana, 1 for signals-only, 0 for unresolved provider error), the privacy guarantee that the registered name is never returned or stored, and the failure mode (unresolved on provider error). This is unusually rich behavioral context.

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

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

Line-broken and front-loaded: purpose first, then per-region behavior and costs. Dense but every line carries operational information; only minor tightening would be possible given the amount of region-specific behavior it must convey.

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 annotations or output schema for a complex, credit-charging identity check, the description covers verdicts, costs, privacy, and geography well. It stops short of explaining how identifier parameters (phone vs account_number vs bank) combine to form the lookup, which is the remaining gap.

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

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

Schema coverage is 0% across 8 parameters, so the description must compensate. It clarifies that 'name' is the person's given name to be matched and that 'country' takes an ISO code (GH, KE...), but leaves bank, email, phone, network, account_number, and mask_registered_name entirely undocumented—only 'network' is touched indirectly via the free signals list.

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: does the given name match the name registered on a mobile money wallet or bank account. It also scopes geography (Ghana live, other regions degraded) and names the exact verdicts returned, distinguishing it clearly from validate_phone/validate_contacts siblings.

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

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

Explicit when-to-use ('only use with the person's consent, at sign-up'), conditional behavior elsewhere in Africa/USA, and downstream action rules ('on partial, confirm with the user; on mismatch, do not pay out'). An agent knows both the prerequisite and how to act on each outcome.

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?

With no annotations, the description carries the full burden and does much of it: it discloses the scoring range and direction, that name matching is conditional, and an unusual credit-cost model (3 credits resolved for Ghana mobile money, 1 for fallback, 0 if unresolved). It still omits auth/permission requirements and any statement about side effects, so it is not fully transparent.

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 score range and polarity — the single most useful fact — before the optional enrichment. The credit-cost clause is dense but earns its place because pricing behavior is otherwise undiscoverable. Minor verbosity in the parenthetical cost breakdown.

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 seven-parameter tool with no annotations and no output schema, the description covers scoring semantics, the cost model, and most inputs. Gaps remain: default_country is unexplained, it never says whether at least one identifier must be supplied, and nothing beyond the 0-100 number describes 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?

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains the roles of ip, email, phone, name (folds in a name match) and momo_number/momo_network (Ghana mobile money, cost-bearing). The seventh parameter, default_country, is never mentioned and no expected formats are given.

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

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

States a specific verb and resource ('One fraud score ... for a sign-up, order or lead') and even defines the output scale and polarity ('0-100, higher = riskier'). It covers the identifier universe (email, phone, IP, name, mobile money), which is enough for an agent to separate it from single-signal siblings, but it never explicitly names a sibling it is not, so 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?

Usage is implied rather than stated: any of email/phone/IP can be supplied, and name plus mobile money is an optional enrichment. There is no explicit when-to-use versus validate_email/validate_phone/match_name, nor any statement of prerequisites (e.g. whether at least one identifier is required, despite 0 required parameters).

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?

No annotations, so the description carries the full burden. It usefully discloses the 100-item cap, auto-detection behavior, and result ordering with a summary count, but says nothing about side effects, auth/permissions, rate limits, or whether DNS lookups (check_dns default true) cause network 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?

Two tight, front-loaded sentences with no filler; the batch constraint leads and the output format follows. The phrase 'per agent_action' is unexplained jargon that slightly muddies the second sentence.

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 tool with no annotations and no output schema, the description is only partially sufficient. Ordering and summary output are covered, but the two optional parameters and any safety/network behavior remain undocumented.

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

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

Schema description coverage is 0%, so the description must document parameters. It only covers 'values' (contents plus the 100 max), and completely omits check_dns and default_country, leaving two of three parameters with no semantic explanation anywhere.

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 (validate emails/phone numbers), plus batch scope of up to 100 with auto-detected type. This distinguishes it implicitly from validate_email and validate_phone, but it never names those siblings, so an agent must infer the batch-vs-single split.

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 'up to 100 ... at once' and 'type is auto-detected' phrasing implies the mixed/bulk use case versus the single-type siblings, but there is no explicit when-to-use, when-not-to-use, or named alternative 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?

With no annotations, the description carries the full burden, but it does disclose the checking dimensions and the return shape (verdict + agent_action + reasons). It does not mention that a DNS/mail-server lookup happens over the network, nor rate limits, failures, or auth needs — meaningful gaps for a tool that touches DNS.

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 packed sentences, front-loaded with the action and checks, then the return values. 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, so the description usefully names the return fields (verdict, agent_action, reasons). It covers the validation surface well, though the check_dns parameter's effect and failure behavior remain unexplained.

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

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

Schema coverage is 0%, so the description must compensate. 'Check one email address' clarifies the email parameter as a single address, and 'whether the domain has a working mail server' loosely maps to the check_dns toggle, but it never states that check_dns controls that lookup or its default. Partial compensation only.

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 one email address') and enumerates exactly what is checked: syntax, typo suggestion, disposable inbox, role account, and domain mail server. The 'one email address' phrasing implicitly distinguishes it from the bulk-oriented sibling validate_contacts.

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: 'one email address' suggests single-address validation versus validate_contacts, but there is no explicit when-to-use, when-not-to-use, or named alternative. No prerequisites or cost/latency guidance is given.

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?

No annotations are provided, so the description carries the full burden, and it does useful work by enumerating what the call returns (E.164, validity, line type, SMS capability, country, carrier, timezones) with no output schema to lean on. It omits operational traits such as auth requirements, rate limits, or whether this is a paid carrier lookup, which keeps 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?

Three sentences, front-loaded with the verb, then returns, then the one non-obvious parameter rule. The return-field list is longer than strictly necessary but each item is informative, 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 and no annotations, the description supplies exactly the two things missing: the return shape and the conditional for the optional parameter. Only operational context (auth, cost, limits) is absent, which is minor for a single-number read check.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: default_country is explained as an ISO code ('US', 'GH') used when no +country prefix is present, which is meaning the schema does not carry. The phone parameter itself is self-evident from its name.

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?

"Check one phone number" names a specific verb and resource, and the enumerated return fields make the scope unambiguous. It distinguishes itself from siblings by resource (phone vs domain, IP, email, contacts), though it never names an alternative explicitly.

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

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

The description gives one clear conditional: pass default_country when the number lacks a +country prefix. Beyond that it offers no guidance on when to use this tool versus validate_contacts (which may also cover phones) or when not to call it, 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.