osint.foundation

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 usefully adds the payment model — x402, Base or Solana, charged only on successful calls — which is real behavioral context an agent needs before invoking. It omits what happens on invalid or unknown CEPs (error vs empty result), which for a paid call is a meaningful 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?

Two sentences, both load-bearing: the first states the lookup and its return fields, the second states cost and payment rails. Nothing is wasted and the purpose is front-loaded ahead of pricing.

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 does supply the return shape (street, neighbourhood, city, state) plus the payment requirement, which is what an agent most needs to call it. Failure behavior for malformed or non-existent CEPs is the remaining omission, but the read-only, single-param design makes it minor.

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 'cep' is fully documented (8-digit, hyphen optional). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific resource (Brazilian CEP) and enumerates the returned address fields (street, neighbourhood, city, state), so an agent knows exactly what it gets back. It does not explicitly distinguish itself from sibling Brazilian identifier tools (br_cnpj, br_cpf, br_ddd), but 'postal code (CEP)' is unambiguous enough to route correctly.

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

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

There is no guidance on when to use this versus alternatives, no mention of input validity handling, and no stated exclusions. The only conditional content is about pricing (no API key → $0.05 USDC via x402), which is a cost notice rather than usage 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. Beyond that, the description adds genuinely valuable behavioral context: no API key required, $0.05 USDC per successful call, and payment rails (x402, Base or Solana) — details the agent could not otherwise infer.

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

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

Two tight sentences, front-loaded with what the record contains and then the cost model. No filler, and the pricing caveat is clearly separated from the data description.

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

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

With no output schema, the description usefully enumerates the returned fields, and it covers the payment/auth precondition. The main gap is the absence of sibling routing guidance, but for a single-parameter lookup this is largely 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 `cnpj` parameter is well documented in the schema (14-digit, punctuation optional). The description adds nothing about the parameter beyond what the schema already provides, 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 makes clear it returns a Brazilian company's CNPJ registry record, enumerating the specific fields (legal/trade names, status, opening date, activities, address, capital, partners). It does not explicitly differentiate itself from the similar us_company_lookup / uk_company_lookup / br_cpf siblings, leaving that to the country/identifier context.

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

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

There is no explicit when-to-use guidance, no mention of when to prefer us_company_lookup or uk_company_lookup, and no prerequisites stated. The Brazilian-company scope is implied only by the resource name and title, not spelled out as a selection rule.

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 cover readOnly/openWorld, so the description carries meaningful extra weight: it discloses that no personal data is returned, that payment is $0.05 USDC per *successful* call, and that x402 on Base or Solana is used absent an API key. That billing/authorization context is exactly what annotations cannot express. It falls short of 5 only because the response shape and what counts as an unsuccessful (unbilled) call are unstated.

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 clauses: what it validates, the data-scope caveat, and the pricing/auth model. The core purpose leads and no sentence is padding. Tight for the amount of ground covered.

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-param, annotation-backed read tool with no output schema, the description covers purpose, data scope, and the unusual x402 payment requirement — the highest-risk unknown for an agent. Only minor gaps remain (no hint of what a valid-vs-invalid result looks like, no mention of whether region is returned as a code or name).

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

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

Schema description coverage is 100% — the single 'cpf' parameter is documented as 11 digits with optional punctuation and bounded 1-200 chars. The description adds nothing about the parameter 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?

Names a specific verb ('checks') and resource ('Brazilian CPF'), and enumerates what is verified: format, check digits, issuance region. It implicitly separates from br_cnpj (CPF = individual, CNPJ = company) but never names the sibling, so differentiation relies on the agent's own knowledge.

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?

'Validation only: no personal data' frames the appropriate use case and warns off anyone expecting enrichment data. However, no alternative is named — an agent handling Brazilian company data gets no pointer to br_cnpj — and there are no explicit when-not-to-use conditions.

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 – the $0.05 USDC x402 charge per successful call and the two supported chains – but says nothing about what happens on an invalid or non-existent DDD, which matters for a paid call.

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: return content first, then the payment condition. Nothing is redundant and the most important fact leads.

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 one fully described parameter and no output schema, the description tells the agent what the response contains and what it costs, which covers most of what is needed. The gap is failure behavior for invalid codes on a paid 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% and the single parameter is already documented as a '2-digit DDD' in the schema. The description only restates 'area code (DDD)' without adding format, validation, or example guidance, so baseline 3 applies.

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

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

The description names the resource (Brazilian area code / DDD) and the exact return fields (state, cities, time zone), so an agent knows precisely what it gets back. It stops short of naming a verb or distinguishing it from the nearest siblings like phone_lookup or osint-phone, which also deal with phone numbers.

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

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

There is no statement of when to use this tool versus br_cep, phone_lookup, or osint-phone, nor any exclusion for non-Brazilian numbers. The only usage-adjacent content is the payment note, which is about cost, not selection.

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), so the description earns credit for extra behavior: it discloses the x402 metered cost of $0.05 USDC per successful call and the accepted chains (Base or Solana) plus the API-key bypass. That is real, decision-relevant context an agent cannot get from structured fields. It stops short of saying what happens on failure or whether uncharged failed calls occur.

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 with zero filler: the return payload is front-loaded and the pricing caveat follows. Every clause carries information the agent needs before calling.

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

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

For a single-parameter read-only lookup with no output schema, enumerating the returned fields and disclosing the payment model covers nearly everything needed to call it correctly. Only failure/empty-result behavior 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?

Only one parameter and schema coverage is 100%, with the schema already documenting the '1, 3 or bc1' prefix constraint. The description adds nothing beyond identifying the resource as a Bitcoin address, so the baseline of 3 applies rather than a penalty.

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

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

The description names the resource (a Bitcoin address) and enumerates exactly what data comes back — balance in BTC and USD, totals sent/received, tx counts, last activity, recent transactions. The chain specificity ('Bitcoin address') implicitly separates it from the eth_address, sol_address and tron_address siblings, though it never names them directly.

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 guidance on when to choose this over the many address/OSINT siblings, nor on prerequisites such as a valid address format or what happens on an unknown address. The payment sentence is billing context, not usage guidance, and no exclusions are 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 already declare readOnlyHint=true, and the description reinforces that by describing the return payload (prices plus a checkout link) rather than a purchase action. It adds useful facts annotations cannot carry: that the call is free and requires no auth key. Authentication and output shape are both disclosed.

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 no waste; the payload description leads, the optional filtering follows, and the access terms close. Nothing is buried or repeated.

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?

Low-complexity tool with one optional enum parameter and no output schema, and the description covers what is returned, the payment methods behind the link, and the no-key access requirement. Only minor gaps (e.g., whether links expire or whether prices vary by region) remain, which are not essential 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% and the single parameter is an enum with all four values documented, so the schema does the heavy lifting. The description only adds the filtering semantics (a given pack id narrows results to that pack), which is a small increment 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 resource (credit packs with prices and a direct checkout link, crypto or card) and the optional single-pack scope. This is clear enough that an agent knows this is a catalog/listing call rather than an actual purchase, despite the 'buy' name. It doesn't need sibling differentiation since it is the only billing tool among OSINT 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?

'Pass a pack id for just that pack' implies that omitting the id returns the full list, which is genuine usage guidance. 'Free; works without a key too' adds access context but there is no explicit when-to-use vs when-not framing, and no alternatives exist to route to.

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; the description goes well beyond by disclosing the payment/auth model (API key optional, $0.05 USDC per successful call via x402 on Base or Solana) and the content boundary ('no exploit code is returned'). That cost and output-scope disclosure is exactly the kind of behavioral context the annotations cannot carry.

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 input ('For a CVE id') followed by a dense result enumeration; every clause maps to a distinct returned field. The enumeration is long but each item earns its place, and the cost sentence is placed last where a reader expects 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 takes on the job of describing return values and does so thoroughly (scoring, classification, exploitation status, artifact links, advisories). Combined with the content limitation and pricing note, an agent has everything needed to decide and call 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?

Only one parameter and schema coverage is 100%, with the schema already giving the 'CVE-2021-44228' example and length bounds. The description adds nothing about format, case sensitivity, or handling of non-CVE identifiers, so it sits at the baseline.

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

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

States a specific verb-like action on a specific resource ('For a CVE id') and enumerates exactly what is resolved: CVSS, CWE, CISA KEV status, ransomware use, PoC/Metasploit repos, Nuclei template, advisories. Nothing in the sibling list (domain/IP/phone/social lookups) overlaps, so the tool is unambiguously distinguishable.

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?

'For a CVE id' plus 'References and metadata only; no exploit code is returned' sets a clear expectation of when this tool applies and what it will not produce. It stops short of naming alternatives or exclusions (e.g., when to prefer a generic http_get or osint-domain call), so it is clear context without explicit routing.

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

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

Annotations already cover the read-only and open-world profile, and the description adds genuinely useful context beyond them: a $0.05 USDC charge per successful call via x402 on Base or Solana, and that an API key bypasses this. It does not state rate limits or failure/refund behavior, 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?

Two compact sentences with the capability front-loaded and the payment caveat trailing. Every clause carries information; the only mild inefficiency is enumerating return fields rather than summarizing them.

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 single-parameter read-only lookup with no output schema is well served here: the description names the returnable fields (server name, member counts, server tag, inviter, creation date, invite expiry) and the cost model. Only the ambiguity about which sibling handles usernames/tags is unaddressed.

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 'query' parameter is already documented as 'Invite code (or discord.gg link code), or a numeric user, bot or server ID'. The description restates the same accepted formats without adding syntax, validation, or example details, 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?

States a specific verb (look up) and resource (Discord invite code or numeric user/bot/server ID) plus the fields returned. It implicitly separates itself from discord_username/discord_tag/discord_server_search by restricting input to invites and numeric IDs, but never names those siblings so the agent must infer the boundary.

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: the input type (invite code or numeric ID) hints that username/tag searches belong to other tools, but no explicit when-to-use or when-not-to-use statement is given. The pricing note tells the agent about cost, not about choosing this tool over alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely new behavioral context – the x402 pay-per-successful-call pricing at $0.05 USDC on Base or Solana, and the fact that each page is a separate billable lookup. It stops short of stating rate limits or whether failed lookups are charged (only 'successful' calls are, which is stated).

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: what it returns, how paging works, and what it costs. The resource and return fields are front-loaded before the operational caveats.

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 fields, and it covers the cost/auth model that would otherwise be invisible. It omits how many results a page contains and how results are ranked, which an agent sizing a search loop would want, but nothing required to call 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?

Schema coverage is 100%, so both 'keyword' and 'page' are already documented in the schema, and the description's mention of name search and per-page lookups adds only marginal framing. The important derived detail – that each page incurs its own charge – is conveyed, but not parameter-specific syntax or matching behavior.

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 ('Find public Discord servers by name') and enumerates what comes back (guild IDs, member counts, tags, invites), which immediately separates it from the username/tag/profile siblings in the list. An agent can tell this is server discovery, not user lookup, 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?

The description gives clear paging guidance ('request page 2+ only when hasMore is true'), but says nothing about when to choose this over discord_lookup or the other Discord siblings. Usage is inferable from the name and scope, 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 already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds two genuinely non-structured facts: the data set is a partial directory of previously observed servers, and the call is metered ($0.05 USDC per successful call via x402, Base or Solana) — an important cost signal for an agent deciding whether to call.

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

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

Two tight sentences: the lookup semantics and tag definition come first, the payment clause second. Nothing is redundant and no sentence could be removed without losing information.

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

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

For a one-parameter, read-only lookup with no output schema, the description covers purpose, data scope, and cost. The only gap is the return shape — it doesn't say whether the answer is a list of server names/IDs or how multiple matches are ordered — which matters slightly more given there is no output schema.

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 carries a description with an example ('The server tag, e.g. OWL'). The description's gloss on what a server tag is adds modest conceptual clarity but no format, casing, or matching-behavior details, so baseline 3 applies.

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

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

The description states a specific reverse-lookup: which server(s) use a given server tag, and clarifies what a tag is (the short tag members wear beside their name). This clearly separates it from discord_username and discord_lookup, though it never names the closest sibling discord_server_search to draw the boundary.

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 phrase 'from the directory of servers seen so far' implies the coverage constraint on when results will be useful, but there is no explicit when-to-use/when-not guidance or pointer to discord_server_search / discord_lookup for forward lookups. Usage is inferable rather than 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 already declare readOnlyHint=true and openWorldHint=true, so safety profile is covered. The description adds meaningful context: it explains what results mean (registration status plus platform accounts) and includes a pricing note for unauthenticated calls, which is valuable behavioral information 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?

The description is front-loaded with the core purpose and packs useful edge-case and pricing details into three tight sentences. Every sentence contributes context without waste.

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

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

For a simple read-only lookup with no output schema, the description covers what is returned conceptually, an important edge case, and payment requirements. It does not describe response formatting specifics, but that is a minor gap given the tool's simplicity.

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 is fully documented in the schema ('Discord username, with or without @'). The description does not add any new parameter semantics, which is acceptable given the high coverage.

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 clearly states that this tool checks whether a Discord username is registered and which platform accounts have held it. The verb+resource is specific enough to distinguish it from generic lookups, but it does not explicitly differentiate itself from siblings like discord_lookup or username_scanner.

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 provides no guidance on when to use this tool versus alternatives. It mentions an edge case ('a name can be taken with no known account'), but that is behavioral context, not usage routing.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely new behavioral facts: the response contains addresses only with no source attribution, and calls are metered at $0.05 USDC per successful call via x402 on Base or Solana when no API key is supplied. That cost and output-content disclosure is exactly the kind of context annotations cannot carry; only failure behavior is unstated.

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 resource and immediately followed by the output-scope caveat. The payment sentence is boilerplate but earns its place by explaining the unauthenticated cost model.

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 stating what the response does and does not contain, and it discloses the paid-access path that would otherwise surprise an agent. For a one-parameter read-only lookup, nothing essential is missing.

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

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

With a single parameter at 100% schema description coverage, the schema already explains that the input may be a domain, URL or email address on it. The description adds only the loose framing 'associated with a domain' and no format or normalization detail 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?

The description names a specific resource and its scope: 'Every email address associated with a domain', which is clearly distinct from siblings like domain_ips, domain_urls and domain_whois. It does not explicitly name those siblings, so an agent must infer the routing, but the verb+resource pairing is unambiguous.

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

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

There is no statement of when to use this versus osint-email, domain_urls or domain_ips, and no prerequisites or exclusions are given. The only context offered is billing mechanics, which is not usage guidance for tool selection.

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 readOnly and openWorld; the description adds real context beyond them — the underlying data provenance (certificate logs, web crawls, archives, passive DNS) and the paid-call model ($0.05 USDC per successful call via x402 on Base or Solana). It does not cover rate limits, caching, or what a partial/empty result looks like.

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, front-loaded with what is returned, followed by the pivot suggestion and the pricing caveat. Every clause carries information; nothing is redundant with the title 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 and minimal annotations, the description must carry the return-shape burden, and it does — enumerating subdomains, IPs, network owner/ASN/country, and DNS records. Payment terms close the remaining gap for a paid, open-world tool.

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

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

There is only one parameter and schema description coverage is 100% ('A domain name, or a URL or email address on it' is already in the schema). The description adds no further parameter-level meaning, so the high-coverage baseline of 3 applies.

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

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

States a specific verb and resource ('Every subdomain found for a domain ... with the IPv4 addresses each resolves to') plus secondary outputs (NS, MX, TXT). The scope is precise enough to separate it from sibling tools like domain_whois (registration data) and domain_emails/domain_urls (harvesting different artifacts).

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 downstream work: 'Pivot any IP into ip_lookup for open ports and CVEs.' It also gives the cost context for callers without an API key. It stops short of stating when *not* to use this (e.g., vs domain_whois for registration, or ip_geolocation for a bare IP), so a 4 rather than 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 readOnly and openWorld, but the description adds substantial context beyond them: the exact return shape (crawl id, URLs, status, mime type, timestamp) and a pricing/auth model ($0.05 USDC per successful call via x402, no API key). This is precisely the behavioral detail an agent needs to budget and invoke correctly.

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

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

Three tight sentences: what it does first, then return values, then payment terms. No waste, and the primary definition is front-loaded.

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 describing the return contents. Single simple parameter, annotations cover the safety profile, and payment/auth context is included. An agent has everything needed to call and interpret it.

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

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

Only one parameter with 100% schema coverage, and the schema already documents that it accepts a domain, URL, or email address. The description adds nothing beyond restating 'on a domain', so the baseline of 3 applies.

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

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

States a specific verb and resource: enumerate every URL captured on a domain via public web crawls. This clearly distinguishes it from sibling tools like domain_emails, domain_ips, and domain_whois, and the 'passive ... without touching the site' framing removes ambiguity.

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?

Explains the use-case well: passive enumeration of a site's pages without touching the site, implicitly contrasting with active crawl siblings like http_get or http_screenshot. It stops short of naming those alternatives or stating explicit when-not conditions, so not a 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 cover the read-only, open-world profile, and the description adds genuinely non-obvious behavior: redacted placeholders are omitted rather than returned, a `privacy` flag signals a hidden owner, and unauthenticated calls cost $0.05 USDC per successful call via x402. What is missing is any mention of rate limits, error cases (e.g., unregistered domain), 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?

Front-loaded with the core question, then the field list, then the redaction caveat and pricing. Dense but every clause carries information; only minor cost is the slightly compressed pricing phrasing.

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 serves as return-value documentation by listing the fields an agent will receive, and it discloses the redaction behavior and payment requirement. For a one-parameter lookup that is nearly complete; only edge-case behavior (invalid or unregistered domains, response shape) is left uncovered.

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 the schema documents it at 100% coverage, including that a bare domain, URL, or email on the domain is accepted. The description adds no extra semantics about the domain argument, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Who owns a domain') and enumerates the exact record types returned (owner, registrar, registration/expiry dates, status, nameservers). This enumeration distinguishes it clearly from sibling lookups like domain_emails, domain_ips, and domain_urls without needing to name them.

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 field list – an agent can infer it should be called when ownership/registrar data is needed – but there is no explicit when-to-use or when-not-to-use guidance, and no reference to the domain-scoped siblings that query adjacent data. The x402 pricing note describes cost, not selection criteria.

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 context the annotations lack: the $0.05 USDC per successful call x402 payment model (Base or Solana) when no API key is present, which materially affects invocation planning. It does not describe failure modes or rate limits.

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, no filler, with the data returned front-loaded ahead of the payment caveat. The enumeration is dense but each item conveys distinct return content an 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 must enumerate what comes back, and it does so thoroughly. The payment/pricing note covers the main non-obvious operational constraint. Minor gaps remain around error behavior and response size.

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 address parameter is fully documented (42-char 0x address or .eth name). The description restates the accepted input formats but adds no syntax or validation detail beyond the schema, so the baseline 3 applies.

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

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

Names the specific resource (Ethereum address or ENS name) and enumerates the returned data: balance, token holdings, transaction counts, contract details, scam flags, recent transactions. This distinguishes it from the sibling chain-specific tools (btc_address, sol_address, tron_address), though it lacks a leading verb.

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 type — the agent can infer this is the tool for Ethereum lookups — but there is no explicit when-to-use guidance, no exclusions, and no mention of when a sibling such as btc_address or sol_address would apply.

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 say readOnly and openWorld; the description adds substantial context beyond that — approximate result cardinality (~a dozen), people-only restriction, the fields returned, and the exact cost/auth model ($0.05 USDC per successful call via x402 on Base or Solana, or API key). The per-call charge is critical pre-invocation information an agent would otherwise miss.

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

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

Three tight sentences: what it returns first, the follow-up tool second, cost/auth last. Zero filler and every clause carries information an agent needs before selecting or calling the tool.

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

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

There is no output schema, yet the description enumerates the returned fields (name, numeric profile ID, profile link, public details), the result volume, and the payment/auth path. Nothing material is missing for a single-parameter 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?

Only one parameter and schema coverage is 100%, so the schema alone documents 'name' with an example ('John Smith'). The description reinforces that it is a person's name rather than a username or ID, but adds no format or matching-rule detail (e.g. exact vs fuzzy) 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?

States a specific verb+resource (people search by name) with scope qualifiers: Facebook's public directory, ~a dozen results per name, people only. It also distinguishes itself from the sibling facebook_profile by explaining that the latter takes an ID for the full profile.

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: use this to find candidates by name, then 'Pass an ID to facebook_profile for the full public profile.' That names the alternative sibling and the condition that selects it, so no 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?

Beyond the annotations (readOnlyHint, openWorldHint), the description discloses meaningful behavior: results are limited to what Facebook shows logged-out visitors, and without an API key each successful call costs $0.05 USDC via x402 on Base or Solana. That cost/auth context is genuinely useful; only failure/not-found behavior and rate limits are unaddressed.

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 and identifier forms are front-loaded, followed by the returned fields and payment note. The single sentence with a long parenthetical is dense but largely earned; it stays within reasonable length.

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 carries the return-value burden and does so by listing the fields available. Combined with the visibility scope and payment terms, an agent has enough to call it correctly; only missing-result handling and quota details are absent.

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 one parameter at 100% schema coverage, the schema already documents the accepted identifier formats, so the baseline is 3. The description adds only the notion that the identifier may refer to a Page or a person, which is marginal.

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 — fetching 'The public Facebook profile for a Page or person' — and enumerates the fields returned (name, IDs, verified badge, follower counts, About section). It implies differentiation from the sibling facebook_name_search by accepting 'username, numeric ID or link' rather than a name, though it never names that alternative.

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: the identifier forms (username, numeric ID, link) suggest when this lookup is the right choice over a name search, but no explicit when-to-use or when-not-to-use guidance and no named alternative are 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuinely new behavior by disclosing the paid path ($0.05 USDC per successful call via x402 on Base or Solana when no API key is supplied) and that only public data is collected. It stops short of describing failure/rate-limit 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?

Two sentences: the capability list is front-loaded and the pricing caveat follows as a second, clearly separable clause. The data enumeration is long but each item conveys distinct output content rather than 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 read-only single-parameter lookup with no output schema, the description usefully enumerates what is returned, which is exactly the missing structured information. Remaining gaps (response shape, error/payment-failure handling) are modest at this complexity level.

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 and 100% schema description coverage (including the 'leading @ is stripped' normalization rule), the schema carries the semantics. The description says nothing additional about the username argument beyond implying it identifies a GitHub profile, 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 enumerates the concrete resource surfaced (repositories, languages, organisations, SSH/GPG keys, commit author emails, activity by hour/weekday), which is far more specific than the name 'github_user' alone. It is implicitly differentiated from generic siblings like osint-username or username_scanner by being GitHub-specific, but it never explicitly contrasts with them, keeping it below 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?

There is no when-to-use or when-not-to-use statement, no prerequisites, and no mention of the near neighbours (osint-username, username_scanner) that an agent must choose between. Usage is only inferable from the tool name and the data list.

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 readOnlyHint and openWorldHint annotations, the description discloses that searches are run both as typed and as a username and merged, lists the main returned fields, and states the $0.05 USDC cost via x402 when no API key is used. It does not explain pagination, error behavior, or authentication details with an API key, but it adds meaningful 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?

The description front-loads the purpose and returned data, then adds the location-pinning hint and pricing in short follow-up sentences. It is compact and mostly well structured, though the phrase "searched as typed and as a username and merged" is slightly awkward.

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 paid lookup with no output schema, the description provides enough context: what is searched, how to pin a location, what fields are returned, and the cost model. Minor missing details such as authentication with an API key or response shape are not critical for a basic call.

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

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

The schema already documents the single query parameter with an example, and the description adds important query semantics by explaining the optional " near <place>" syntax and that the input is searched both literally and as a username before merging results.

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

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

The description clearly states that the tool finds Google Maps places tied to a person or business name/username and lists returned fields such as address, phone, coordinates, place ID, and Maps link. It is specific about the resource, though it does not explicitly differentiate this tool from nearby sibling lookup tools.

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 useful usage hint: adding " near <place>" to pin a location. However, it does not explain when to use this tool instead of alternatives like facebook_name_search, instagram_name_search, or username_scanner, leaving the selection context 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 readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context beyond that: it discloses the return fields and the without-API-key pricing model ($0.05 USDC per successful call via x402 on Base or Solana). This is useful, though it does not cover behavior when no Gravatar profile exists or other 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?

The description is two tight sentences: the first front-loads the tool's purpose and return fields, and the second adds relevant billing context. There is no redundant or wasted text.

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 tool with no output schema, the description does a good job by listing the profile fields returned and the payment model. It is slightly incomplete around no-profile behavior and error handling, but the core context is present.

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

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

There is one required parameter and schema description coverage is 100%, so the schema already documents the email input. The description does not add format, normalization, or lookup semantics beyond what the schema provides, making the baseline score 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-resource outcome: it retrieves the public Gravatar profile associated with an email, and it lists the key fields returned (avatar, name, location, job title, verified linked accounts). It clearly distinguishes itself from generic email OSINT by naming Gravatar specifically, though it does not explicitly contrast with siblings such as osint-email.

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 what the tool returns and mentions a payment condition, but it gives no explicit guidance on when to choose this tool over alternatives like osint-email or domain_emails. There are no exclusions, prerequisites, or alternative-routing instructions.

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 readOnly/openWorld annotations, the description discloses meaningful traits: the request originates from the proxy network rather than the caller, text bodies are capped at 128 KB, and non-keyed calls cost $0.05 USDC per successful call. It omits timeout, redirect, non-text/binary body handling, and failure 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?

Two sentences, both dense with information; the core action and return shape come first, with cost and proxy routing as supporting detail. Nothing is wasted or repetitive.

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 tool with no output schema, the description adequately covers the return shape (status, headers, body), proxy origin, payload size limit, and billing. Only operational edge cases such as timeouts and error/redirect handling are 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 coverage, the schema already documents the URL as http or https. The description adds no format, encoding, or constraint details (the 200-character maxLength is never surfaced), so it rests at the baseline.

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

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

States a specific verb and resource ('Fetch any URL') plus the mechanism ('through our proxy') and what comes back (status, headers, body). It implicitly separates itself from http_screenshot and onion_grab by emphasizing text payloads, but never names a sibling explicitly.

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

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

Usage is only implied by 'Fetch any URL.' The pricing note ('Without an API key: $0.05 USDC per successful call via x402') hints that an authenticated path exists, but there is no when-to-use/when-not guidance and no pointer to the screenshot or onion alternatives for cases this tool doesn't cover.

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 genuinely new behavioral context: the image comes back as a data URL and, without an API key, each successful call costs $0.05 USDC via x402 on Base or Solana. That payment/auth path is exactly the kind of operational detail annotations cannot express. It doesn't mention failure behavior, timeouts, or that the request is capped at a 200-character URL.

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, each carrying distinct payload: what it does, what it returns, and what it costs. The purpose is front-loaded and 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?

For a single-parameter, annotation-covered read tool the description covers purpose, return format, and cost, and the output-schema gap is closed by the explicit mention of a data URL. The notable remaining gap is rendering scope: with no viewport/full-page parameters and no statement about whether the whole page or the fold is captured, an agent cannot predict what the image will contain.

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

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

There is one required parameter with 100% schema description coverage, so the schema already documents the url field including its http/https constraint and length bounds. The description contributes nothing about the URL beyond what the schema states. Baseline 3 applies when the schema does the work.

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 ("Capture a screenshot of any web page") plus the return format (data URL), which is enough to distinguish it from http_get in the sibling list. It stops short of naming http_get and contrasting raw-fetch vs rendered-visual, so the differentiation is implied by the verb rather than made explicit.

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

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

The parenthetical "rendered away from the caller" hints at server-side rendering as the reason to pick this over a plain HTTP fetch, but no when-to-use/when-not guidance or alternative tool is named. Usage is inferable rather than stated, so this lands at the minimum-viable level.

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 read-only and open-world profile, and the description adds meaningful context beyond them: 'Nothing is stored' discloses the privacy/retention posture, and the x402 pricing ($0.05 USDC per successful call, only on success, on Base or Solana) is a critical operational trait an agent calling without an API key must know. It does not disclose failure behavior for non-image or oversized inputs, 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?

Front-loaded with the value proposition, then the pricing/payment contingency. The long field enumeration is dense but each item genuinely describes what comes back, though a portion of it duplicates the tag-format listing and could be trimmed slightly.

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 field enumeration effectively serves as the return-value contract, and the retention and payment facts cover the remaining operational gaps for a one-parameter read tool. An agent has enough to call it correctly and anticipate the response shape.

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% for the single required parameter, and the schema already documents the accepted formats and 8 MB cap. The description only restates the concept of 'a link to the image' without adding syntax or validation detail beyond the schema, so the baseline 3 applies.

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

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

The description names the concrete resource (everything a photo file says about itself, sourced from an image link) and enumerates the exact fields returned: GPS, make/model/serial, capture and edit times, editing software, AI-generation traces, C2PA, and every EXIF/XMP/IPTC/maker-note tag. This is far more specific than any sibling in the list (http_get, http_screenshot, ip_geolocation) and an agent can immediately tell it apart.

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: give it a direct image link and get metadata back. There is no explicit when-to-use or when-not statement, and no routing to a sibling such as http_get for fetching the raw bytes. The 'not a web page' constraint lives in the schema rather than guiding selection 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?

Annotations only cover read-only and open-world nature; the description adds substantial context beyond that: the permutation heuristic that drives results, the coverage limitation of that heuristic, the fields returned (display name, follower count, match flag), and the x402 payment requirement with exact price and chains. This is well above the bar set by the 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-loads what the tool does, then the limitation, then the routing alternative, then pricing. Every sentence carries distinct information; the permutation examples in parentheses efficiently convey the matching strategy in a few tokens.

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 enumerates the return fields, and it also covers the two things an agent most needs for this open-world lookup: why results may be incomplete and what a paid call costs. Nothing material is left to inference.

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 includes a concrete example ('Kim Kardashian'), so the baseline is 3. The description adds a meaningful semantic distinction: the input is a person's or brand's name, not a username — which is exactly the confusion an agent could have given the sibling instagram_profile tool.

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 — it finds existing Instagram accounts for a given name — and immediately clarifies the mechanism (checks common username permutations of the name). It also distinguishes itself from instagram_profile by explaining that the latter is for a known username, not a name lookup.

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

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

Gives an explicit when-not: 'Instagram has no logged-out search, so accounts with unrelated usernames are not found' tells the agent not to expect discovery of arbitrary handles. It names the follow-up alternative ('Pass a username to instagram_profile for the full profile') and covers the payment precondition for unauthenticated callers.

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 readOnly/openWorld annotations, the description discloses two things annotations cannot: the logged-out visibility limitation (so private or restricted data is out of scope) and the x402 payment model at $0.05 USDC per successful call on Base or Solana. That cost/auth context is exactly the kind of behavioral detail an agent needs before invoking. It does not cover failure or refund behavior, 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?

Two dense sentences with the returned fields front-loaded, followed by the scope limit and the pricing clause. Almost nothing is wasted, though the second sentence is a fragment and the pricing note could be tighter.

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 enumerating the returned fields, and it adds the paid-call model. Remaining gaps are minor for a single-parameter read tool: no mention of behavior for nonexistent or private handles, and no rate-limit or retry context.

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 is already documented as 'username (with or without the @) or instagram.com profile link'. The description's phrase 'for a username or profile link' merely restates that, adding no syntax, normalization, or validation detail. Baseline 3 is appropriate.

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

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

States a specific resource (the public Instagram profile page) and enumerates exactly what is returned: full name, bio, picture, verified/private flags, follower/following/post counts, numeric user ID. An agent knows precisely what it gets. It does not explicitly distinguish itself from the sibling instagram_name_search, 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?

Usage is implied: supply a handle or profile link and receive profile data. The clause 'Only what Instagram shows logged-out visitors' usefully bounds expectations, but there is no explicit statement of when to prefer this over instagram_name_search or username_scanner, and no prerequisites beyond the payment note.

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

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

Annotations already cover read-only and open-world behavior, but the description adds meaningful context: pricing, payment network options, and the no-API-key condition. It does not describe error behavior or rate limits, but the additional cost/auth disclosure is stronger than the annotation baseline.

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

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

The description is two tightly written sentences: the output fields are front-loaded, and the payment condition follows. Nothing 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?

For a one-parameter lookup tool with annotations covering safety and no output schema, the description is largely complete: it lists returned fields and explains the no-key payment model. Minor gaps remain around private-IP handling and error/payment failure behavior.

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

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

Schema coverage is 100% and the single address parameter is fully documented as IPv4 or IPv6. The description repeats the IP-address context but adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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

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

The description clearly states the resource and returned fields: country, region, city, coordinates, and ASN for an IP address. It does not differentiate from sibling tools such as ip_lookup or ip_reputation, so it falls 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 gives a useful usage condition by noting that no API key requires $0.05 USDC per successful call via x402. However, it does not explain when to choose this over sibling tools like ip_lookup or ip_reputation, leaving the alternative-selection guidance 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?

Beyond readOnlyHint/openWorldHint, the description discloses two things annotations cannot: the lookup is passive ('Nothing is sent to the address') and it is metered at $0.05 USDC per successful call unless an API key is used. It does not say what happens on a failed or uncharged call, or whether results are cached.

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

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

Two tight sentences with no filler: the returned data first, then the privacy and pricing terms. Slight weakness is that it opens with an output list rather than a verb-led statement of purpose, pushing the 'what does this do' answer a few words later than ideal.

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 spends its space enumerating return fields, and it covers the cost and safety posture. It stops short of noting result shape/format or how partial results (no software detected, no CVEs) are represented, which is the main remaining gap for a single-parameter 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?

There is a single parameter with 100% schema description coverage ('IPv4 or IPv6 address (not a hostname)'), so the schema already carries the semantics and baseline 3 applies. The description adds nothing about the address argument and never repeats the not-a-hostname constraint, which is the one input mistake an agent is most likely to make.

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

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

The description names the resource (an IP address) and enumerates exactly what the lookup returns: ownership, range, country, open ports, software, hostnames and CVEs. That is more informative than a bare 'lookup', but it never distinguishes this tool from close siblings like ip_geolocation, ip_reputation or domain_ips, 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 only implied by the data it returns (scan-derived ports/software/CVEs), with no explicit statement of when to pick this over ip_geolocation or ip_reputation. The payment note ('Without an API key: $0.05 USDC per successful call via x402') is genuine operational guidance but about cost, not tool selection.

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 a genuinely useful behavioral fact: without an API key each successful call costs $0.05 USDC via x402 on Base or Solana, which affects whether an agent should call it at all. It stops short of describing result shape, latency, or failure handling.

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 outcome (risk score and level) followed by the supporting evidence, then the payment condition. Every clause carries information an agent would act on; 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 one-parameter, read-only lookup with no output schema, the description effectively explains what comes back (score, level, and the reasons). The remaining gap is sibling disambiguation against ip_lookup/ip_geolocation, which matters given how many IP-adjacent tools sit in this toolset.

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 one parameter and 100% schema description coverage ('IPv4 or IPv6 address', length bounds), the schema already does all the work. The description's 'an IP address' adds nothing beyond it — the schema is actually more precise about accepted versions — so the baseline 3 applies.

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

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

States a specific verb/resource: a risk score and level for an IP address, and even enumerates the signals that make up the verdict (blocklists, Tor, VPN, datacenter, open ports, CVEs). It does not distinguish itself from the sibling tools ip_lookup and ip_geolocation, so an agent cannot tell from the description alone which IP tool is the right one.

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 purpose — reach for it when you need a risk assessment rather than raw geolocation — but the description never says when to use it instead of ip_lookup or ip_geolocation, nor any prerequisites. The payment note hints at a commercial/credential trade-off but is not framed as usage 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 establish readOnlyHint=true and openWorldHint=true. The description adds useful non-annotation context: pricing without an API key is $0.05 USDC per successful call via x402 on Base or Solana, which matters for invocation cost and authentication expectations.

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 compact sentences front-load the resource and identifiers, then append critical payment context. There is no redundant or filler language.

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 lookup with no output schema, the description lists the key return fields and explains payment context. It could additionally clarify ambiguity or multiple-match behavior, but it is largely complete 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% and the single query parameter is fully documented in the schema, including accepted formats. The description is consistent but mostly repeats that queries may be by NPI or name rather than adding syntax 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?

The description concretely states the resource (US healthcare providers), the lookup keys (NPI number or name), and the returned data (provider type, specialties, licences, addresses, phone numbers). This clearly separates it from siblings like us_company_lookup or phone_lookup.

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 implies when to use the tool by naming acceptable query inputs, NPI number or provider/organisation name, but it does not explicitly compare against alternatives or state when not to use it. The guidance is adequate but leaves 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 only cover read-only and open-world, but the description adds substantive context: text-only output with no images, the shape of what comes back, and the pay-per-call model ($0.05 USDC via x402, waived with an API key). It omits failure behavior typical of Tor fetches (timeouts, unreachable onions, retries), which is a meaningful gap for an unreliable network path.

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: what it does, what the alternate input does, then cost/auth. No filler, though the pricing clause is dense and could be split or moved to a note for easier scanning.

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 one parameter, no output schema, and full schema coverage, the description covers mode, output fields, and commercial terms adequately. Missing only the operational caveats an agent would want before relying on it — latency, failure modes on unreachable onions — which keeps it below a 5.

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 is already documented, so the baseline is 3. The description goes further by explaining the semantic consequence of the URL value — a clearnet URL switches the tool into an onion-address-harvesting mode — which is real meaning beyond the schema text.

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 ('Fetch a .onion page over Tor') plus the exact return payload (status, title, visible text, links), and adds a second distinct mode for clearnet URLs. This clearly separates it from the generic sibling http_get, which does not route over Tor or extract .onion addresses.

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 two modes are stated explicitly with their triggering input ('.onion URL' vs 'clearnet URL'), which is enough to select behavior correctly. It stops short of naming alternatives or exclusions (e.g., 'use http_get for normal pages'), so an agent must infer that http_get is the wrong pick for .onion targets.

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 valuable behavioral context beyond annotations: paid plans, $4.99 USDC per search via x402 on Base or Solana without an API key, and charging only when records are found. It does not cover rate limits or output format, but the payment behavior is well disclosed.

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

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

The description is compact and front-loads the core purpose before pricing details. The first sentence is slightly awkward but carries essential scope information, and the remaining sentences efficiently cover payment behavior without waste.

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 tool with annotations and no output schema, the description covers purpose and payment well. However, it leaves the meaning of 'records' and 'the data seen for each' vague and does not help the agent distinguish this from several domain-related siblings, which is a real gap in a crowded toolset.

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. The description adds meaning beyond the schema's 'Domain, e.g. example.com' by clarifying that the domain is used to find accounts at 'every address @domain'. This helps the agent understand the parameter as an email domain scope rather than a generic domain lookup.

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

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

The description states the resource and scope clearly: 'Records found for accounts under a domain (every address @domain), with the data seen for each.' It communicates that this is a domain-level OSINT retrieval tool returning per-account records. It does not differentiate from closely related siblings such as domain_emails, domain_ips, or domain_whois, which limits it to a 4.

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

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

There is no explicit guidance on when to use this tool versus alternatives. It mentions paid plans and x402 payment, but does not say when to choose this over domain_emails or osint-email, nor does it describe prerequisites like authentication with an API key.

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 description rightly spends its words elsewhere: it discloses that an API key changes the access path, that an unauthenticated call costs $0.25 USDC via x402 on Base or Solana, and critically that the charge applies only when records are found. That billing behavior is not derivable from any structured field and is exactly what an agent needs before calling a paid 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?

Two sentences, front-loaded with the purpose and followed by the cost condition; nothing is padded. The pricing sentence is dense with qualifiers (currency, networks, conditional charge) but each detail is operationally relevant, so it earns its space.

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, single-parameter lookup with no output schema, the description covers purpose, return shape at a high level ('sites and accounts... with the data seen for each'), and the payment model. What is missing is guidance on what an empty result looks like versus a charged result, and any latency or rate-limit expectation for an open-world tool.

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

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

Schema description coverage is 100% with a single required 'email' string, so the schema already carries the parameter burden. The description adds no format, validation, or canonicalization guidance (e.g., case handling) beyond what is in the schema, which is the expected baseline for a one-parameter tool.

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 the resource (an email address) and what the caller gets back (records of sites and accounts tied to it, with per-site data), which is more specific than a bare 'email lookup'. It doesn't explicitly distinguish itself from the closest sibling, gravatar_email, which also takes an email, so the differentiation is implied rather than stated.

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

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

There is no when-to-use guidance, no exclusions, and no pointer to an alternative such as gravatar_email for a narrower check. The second sentence covers billing rather than selection criteria, so an agent is left to infer that this is the broad email-to-accounts tool.

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

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

Annotations cover safety (readOnly, openWorld) and the description adds genuinely new behavior: paid plans, a $4.99 USDC x402 charge on Base or Solana when no API key is present, and billing only on hits. That billing-only-on-success detail is exactly the kind of cost/risk signal an agent needs before invoking a paid open-world lookup, though nothing is said about coverage limits or failure 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?

Front-loaded with what it returns, then payment terms, in three short sentences. The fragment 'Paid plans.' is tersely placed and slightly redundant with the pricing sentence that follows, but overall there is little waste.

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 should carry the return shape, and 'the logins seen there and the data for each' is only a sketch — no indication of field set, volume, or what an empty result looks like. Adequate as a pre-call summary but thin for a paid, open-world tool whose results are unbounded.

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?

Single parameter with 100% schema description coverage, so the schema already defines it fully. The description reinforces the domain-keyed nature of the query but adds no syntax, normalization, or format guidance beyond 'e.g. example.com'.

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: accounts recorded on a website, keyed by domain, returning logins and per-account data. The verb is implicit ('retrieve/lookup') rather than explicit, and with a sibling literally named osint-domain the description does nothing to distinguish the two, leaving ambiguity about which domain-intelligence tool to pick.

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

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

No guidance on when to use this versus osint-domain, domain_emails, or domain_urls, even though those siblings plausibly overlap. The payment text describes cost mechanics rather than selection criteria, so the agent must guess at routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: the x402 payment path, the two supported chains (Base or Solana), and the billing condition that charges apply only when records are found. It omits rate limits and any note on empty-result behavior, 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 sentences, front-loaded with what is returned, then the payment mechanics. Nothing is redundant. The first sentence is a sentence fragment and the pricing sentence is dense, which slightly hurts readability but not efficiency.

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 what comes back ('data seen for each'), the cost model, and the payment fallback. It is nearly complete; only the shape of a 'record' and empty-result handling 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?

There is a single parameter and schema coverage is 100%, with the schema itself specifying 'digits only, country code first'. The description adds no formatting, normalization, or example detail beyond 'phone number', so baseline 3 applies.

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

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

The description names the resource (a phone number) and states the return content specifically: sites and accounts tied to the number plus the data seen for each. That is more informative than a generic 'look up a phone'. However, it never distinguishes itself from the sibling phone_lookup, so an agent cannot tell from the text which of the two phone tools to pick.

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

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

Usage is only implied through the pricing clause ('per search'), which signals a paid lookup operation but gives no explicit when-to-use condition and no mention of the obvious alternative, phone_lookup. The '$0.25 charged only when it finds records' line does give the agent a cost-based decision input, which lifts this above pure silence.

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, and the description adds meaningful behavioral context: per-search cost, x402 payment networks, conditional charging only when records are found, and the implication that an API key changes the payment path. It stops short of describing rate limits or exact return structure.

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 compact sentences: the first describes the returned records, the second covers cost and billing behavior. The result description is front-loaded, and the cost sentence earns its place because it materially affects invocation.

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, one-parameter, open-world lookup with no output schema, the description adequately explains what comes back and the cost model. However, in a sibling set crowded with username-specific tools, it omits the alternative-selection guidance needed for an agent to choose confidently.

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%, with the single username parameter already documented as 'Username or handle'. The description does not add format constraints, examples, or meaning beyond what the schema provides, 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 clearly states the resource: records tying a username to sites and accounts, with associated data. It does not explicitly distinguish this generic lookup from siblings like username_scanner or platform-specific tools such as github_user, so it falls 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 provides payment context (x402, $0.25 USDC, charged only on hits) but gives no guidance on when to use this tool versus username_scanner or the many platform-specific username tools. An agent must infer selection from the name and sibling list alone.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description goes further by disclosing the commercial model — $0.05 USDC per successful call, x402 protocol, Base or Solana rails, and that the call is metered on success. That is meaningful operational context an agent needs before invoking. It stops short of describing failure behavior for nonexistent handles or rate limits.

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, zero padding. The value proposition (what is returned) is front-loaded and the payment constraint follows as a secondary operational note.

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 tool with no output schema, the description compensates by enumerating the returned fields. What remains unstated is how to complete the x402 payment flow and what happens when the handle does not resolve, both of which an agent would need before a failed call.

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

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

Only one parameter exists and schema coverage is 100% ('paypal.me handle'), so the schema fully documents it. The description restates the same concept ('paypal.me handle') without adding format rules, casing, or URL-vs-bare-handle guidance. Baseline 3 is appropriate when the schema does the work.

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 ('Resolve') and a narrowly scoped resource ('a paypal.me handle'), then enumerates exactly what comes back: display name, first/last name, profile and cover photo. Being paypal.me-specific implicitly separates it from generic siblings like username_scanner or osint-username, though no sibling is named explicitly.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no routing against the many other username/lookup siblings in the toolset. The only contextual signal is the pricing/payment note, which is about cost rather than selection.

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 carries the interesting load and does it well: it discloses that the carrier field is range-allocation data rather than a live network query, and it spells out the paid path — $0.05 USDC per successful call via x402 on Base or Solana when no API key is present. Cost model and payment rails are exactly the kind of operational 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?

Two tight sentences with no filler: the capability and its outputs come first, then the pricing fallback. The scope caveat about carrier data is embedded inline rather than padding a third 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 one-parameter, no-output-schema tool, the description must explain what comes back and it does — validity, type, region, location, allocated carrier — plus the billing conditions. There is nothing an agent needs in order to call this correctly that 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 description coverage is 100% and the single parameter already documents the 'digits only, country code first, no + or leading zeros' format with an example. The description adds only the notion of 'its country's numbering plan', which is modest added meaning, 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 states a specific verb and resource — validating a phone number against a country's numbering plan — and enumerates exactly what is returned (validity, type, region, location, carrier allocation). It does not name the closest sibling (osint-phone), so the agent must infer the split, which keeps it off a 5.

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

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

Usage is only implied by the phrase 'Validate a phone number'; there is no explicit when-to-use or when-not, and no pointer to osint-phone or whatsapp_business for adjacent phone tasks. The parenthetical '(not a live network query)' does sharpen expectations about the result, but it is a scope caveat, not guidance on tool selection.

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 genuinely new behavioral context by disclosing the x402 pay-per-call model, the $0.05 USDC price, settlement chains (Base or Solana), and that charges apply only to successful calls. It stops short of saying what a non-existent username returns or whether handles need an '@' prefix.

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: capability first, then the payment condition. Nothing is repeated and the most decision-relevant fact (cost) is placed up front for the caller.

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 one parameter, annotations present and no output schema, the description covers what is returned and the payment mechanics adequately. The remaining gap is edge-case behavior — not-found responses and identifier format — which an agent would want before calling.

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

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

There is a single parameter with 100% schema description coverage, so the schema already fully documents 'handle'. The description adds no format detail beyond the schema (e.g. whether '@' is accepted, casing rules), 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 ('Check whether ... exists') and resource ('Snapchat username') and enumerates what is read back (public profile, Bitmoji, Snapcode). It does not name a sibling tool or explain how it differs from osint-username or username_scanner, so an agent must infer the distinction from the platform name 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?

Usage is only implied: the description makes clear this is a platform-specific existence/profile lookup, and the pricing sentence hints at the no-API-key path. There is no explicit 'use this instead of X when...' guidance nor any stated preconditions or exclusions relative to the many other username-scanner 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 declare readOnlyHint and openWorldHint, so safety is covered; the description goes beyond them by disclosing the payment model — $0.05 USDC per successful call via x402 when no API key is present. That is material pre-call cost information an agent could not get from the annotations, though rate limits and failure/latency behavior are not covered.

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, no filler: the return payload is front-loaded, then the pricing/auth condition. 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 compensates by listing the returned fields, and it covers the cost/auth path. What remains unstated is edge behavior — e.g. results for an unknown .sol name or an address with no transactions — which slightly limits completeness.

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

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

There is a single parameter with 100% schema description coverage (base58 32-44 chars or .sol name). The description repeats that same duality ('Solana address or .sol name') without adding format or validation detail, so the schema does the work and baseline 3 applies.

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

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

The description states a specific resource (Solana address or .sol name) and enumerates exactly what is returned: SOL balance in SOL and USD, account type, SPL token holdings, recent transactions. This distinguishes it cleanly from chain-specific siblings such as eth_address, btc_address and tron_address without the agent needing to open 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?

The scoping phrase 'for a Solana address or .sol name' tells the agent precisely when this tool rather than the Ethereum/Bitcoin/Tron siblings applies. It does not state explicit exclusions (e.g. what to do for non-Solana input), so it stops short of a full when/when-not treatment.

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 (readOnlyHint) and reach (openWorldHint), and the description adds genuinely useful context beyond them: which fields are conditional ('if public'), the presence of ban flags, and the x402 payment model including the 'per successful call' qualifier. It stops short of describing not-found/error 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?

Two compact sentences; the payload of identifiers and returned fields comes first and the cost note is correctly demoted to the end. Slight waste in the awkward 'Any Steam account with all its ID formats' opener, but nothing extraneous.

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 describing the response and does so by enumerating the profile fields, including conditional ones. Remaining gaps are minor: no mention of failure/not-found behavior or billing on failed lookups.

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

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

Schema coverage is 100% and the schema description already lists SteamID64, STEAM_0:Y:Z, [U:1:N], custom URL and profile link. The description largely restates those formats, adding no syntax or edge-case guidance beyond what the schema provides, so baseline 3 applies.

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

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

The description names the resource (Steam account) and enumerates the returned data (IDs, name, avatar, real name, country, member since, ban flags), which clearly separates it from siblings like discord_lookup or username_scanner. It lacks an explicit verb ('look up'/'retrieve'), reading as a noun phrase, but the intent is unambiguous.

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

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

Usage is implied by the enumeration of accepted ID formats, and the pricing note ('without an API key: $0.05 USDC per successful call') hints at an authenticated free path. However, it never states when to prefer this over alternatives such as username_scanner or osint-username, nor any prerequisites.

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 and scope are partly covered. The description adds meaningful behavioral context beyond annotations: $0.05 USDC per successful call via x402 on Base or Solana when no API key is used, and what profile data is returned. It does not cover rate limits or failure behavior, which keeps 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 description is front-loaded with the resource and returned fields, then follows with the pricing caveat. Both sentences carry useful information and 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?

For a one-parameter read-only lookup with no output schema, the description explains what is returned and the payment condition, which is sufficient for correct invocation. A minor gap is that it does not describe not-found or error behavior.

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

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

There is only one parameter and schema description coverage is 100%; the schema already documents it as a Substack handle, profile URL, or name. The description echoes the same accepted forms but adds no constraints, formatting guidance, or examples beyond what the schema provides.

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

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

The description names a specific resource, a public Substack profile, and enumerates the returned data: bio, photo, follower/subscriber counts, publications run, and subscriptions. It is clearly Substack-specific among the sibling lookup tools, so an agent can distinguish it from generic username or social profile tools.

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 intended use is implied by stating that it returns a public Substack profile, and it adds practical guidance about the no-API-key payment path. However, it does not explicitly say when to use this versus alternatives such as osint-username or username_scanner, nor does it state 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 and openWorldHint, so safety is covered; the description adds useful behavioral context by listing the returned public data and scam/fake flags. It also discloses the $0.05 USDC x402 payment path when no API key is used, though it does not describe error behavior or rate limits.

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

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

The description is two sentences and front-loads the core lookup behavior before adding the payment condition. Every sentence carries relevant information with no wasted wording.

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 lookup with no output schema, the description sufficiently enumerates what is returned: existence, account type, public name, bio, photo, audience size, and scam/fake flags. Combined with the read-only/open-world annotations, it gives the agent enough context to call the tool 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 required handle parameter is fully documented as a Telegram username without the @. The description reinforces the Telegram context but adds no syntax or format detail beyond the schema, so the baseline of 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 Telegram username lookup: it checks existence, classifies the handle as user/bot/channel/group, and lists returned metadata. The Telegram-specific resource clearly distinguishes it from sibling username tools for Discord, Snapchat, TikTok, and generic OSINT scanners.

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 no explicit guidance on when to use this tool versus alternatives such as username_scanner or osint-username, nor any when-not conditions. The only conditional context is pricing without an API key, which is not usage 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. The description adds meaningful behavioral detail beyond that: pricing via x402, $0.05 USDC per successful call, and payment on Base or Solana. It still omits error behavior for missing handles and rate limits.

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 core action and returned fields, followed by the payment condition. No filler or redundant restatement of the tool name.

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

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

There is no output schema, so enumerating display name, bio, avatar, verification, counts, and permanent user ID is useful. The description is close to complete for a read-only lookup, though it could mention behavior when the handle does not exist.

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

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

Schema coverage is 100%, and the schema already explains that the handle may be provided with or without '@'. The description does not add any further parameter semantics, so the baseline 3 is appropriate.

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

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

The description uses a specific verb ('Resolve') and resource ('TikTok handle') and enumerates the exact profile fields returned. Naming TikTok clearly distinguishes it from platform-specific siblings such as instagram_profile or github_user.

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 context is clear: use this to resolve a TikTok handle to its public profile. However, it does not explicitly say when not to use it or name alternatives like osint-username or username_scanner for cross-platform searches.

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 genuinely useful behavioral context — the $0.05 USDC per-successful-call pricing and the x402/Base-or-Solana payment path, implying no charge on failures — but says nothing about rate limits, latency, or what happens on an invalid/non-T address.

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, no filler, with the returned data front-loaded and cost moved to the end. Slightly weakened by opening with a noun phrase rather than a verb, and by listing outputs as a comma run rather than grouping them.

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 responsibility for describing return content and does so thoroughly, plus it covers the payment model. Remaining gaps are minor for a read-only one-parameter lookup: failure behavior and per-agent rate limits.

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 is fully documented in the schema (TRON address starting with T, 34 chars), so baseline 3 applies. The description adds no parameter-level detail beyond what the schema already provides.

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 enumerates concrete outputs (TRX balance in TRX/USD, USDT/USDC holdings, creation and last-activity timestamps, recent transfers, Tether freeze status), which makes the resource and operation unambiguous. It never states the verb or explicitly names the TRON chain, relying on the tool name/title and implicit contrast with eth_address/btc_address/sol_address 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?

There is no guidance on when to use this versus the other chain-specific lookups (eth_address, btc_address, sol_address) or any prerequisite such as a funded x402 wallet. The only contextual statement is about payment mechanics, not selection criteria.

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 description adds useful context beyond them: the x402 payment cost of $0.05 USDC per successful call when no API key is present, and the name-matching behavior of returning a best match plus other matches. It does not disclose rate limits, failure modes, or whether results are cached, but the payment and matching semantics are meaningful additions.

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

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

The description is front-loaded with the resource and query modes, then lists returned fields and pricing. The field list is long but earns its place because there is no output schema and the agent needs to know what data is available. It avoids filler and unnecessary repetition.

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?

Given a single-parameter lookup with no output schema, the description covers the key aspects: input modes, returned data fields, name-matching behavior, and payment requirements without an API key. It omits error behavior, rate limits, and explicit sibling differentiation, which keeps it from being fully complete, but the core information an agent needs is present.

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 schema already documents the single query parameter with examples for company number formats. The description restates that the query can be a company number or name, and adds that name queries return a best match plus other matches, but it provides no additional syntax or normalization details. The baseline of 3 is appropriate 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?

The description clearly identifies the resource (a UK company on the Companies House register) and the lookup input modes (company number or name). It also enumerates the returned data fields, which is valuable because there is no output schema. It does not explicitly distinguish itself from sibling tools like uk_officer_search or us_company_lookup, so it falls 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 two query modes and notes that a name query returns the best match plus other matches, which is useful usage context. However, it gives no explicit guidance on when to use this tool versus uk_officer_search or us_company_lookup, and there are no exclusions or prerequisites beyond the pricing note.

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, but the description adds genuinely useful context the annotations cannot carry: the exact return contents (birth month/year, appointment count, addresses, and full company lists for only the first few matches), plus the auth/payment model ($0.05 USDC per successful call via x402 on Base or Solana). This is meaningful disclosure for a paid, open-world lookup; only rate limits and the truncation reason for 'first few' are left implicit.

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 and output shape are front-loaded in the opening clause, and the pricing/auth note is correctly placed last. The middle portion is dense but every clause carries information; no filler sentences are present.

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 fully carries the burden of explaining return values, and it does so at two levels of detail (summary fields and per-company appointment breakdown). Combined with the explicit payment requirement and the annotation-covered safety profile, an agent has everything needed to decide to call it and anticipate the result.

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% for the single required 'query' parameter, so the baseline is 3. The description goes beyond the schema by explaining the consequence of each input mode — a name yields all matching officer records, while an officer ID yields that record's appointments — adding behavioral meaning not present in the schema text.

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 ('Find a person on the Companies House register by name') and enumerates the record types returned (director, secretary, LLP member). It is distinguishable from the sibling uk_company_lookup by the person-centric framing, but the description never names or contrasts that sibling explicitly.

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

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

The line 'An officer ID returns that record's appointments' clarifies the alternate input mode, implying when to pass an ID rather than a name. However, there is no explicit guidance on when to use this tool versus uk_company_lookup or us_company_lookup, and no stated exclusions or prerequisites beyond the payment note.

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. Beyond that, the description discloses the paid-access model ('$0.05 USDC per successful call via x402 (Base or Solana)') and the match resolution behavior — both non-obvious operational facts an agent needs before calling.

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 payload fields are front-loaded after the identifier clause, and the pricing caveat is a short trailing sentence. The field enumeration is long but each item is informative rather than filler; nothing is redundant with 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?

With no output schema, the description carries the burden of describing returns and does so thoroughly (tickers, EIN, incorporation, financials, Form D people and amount, recent filings). Payment model is disclosed. Minor gaps remain around error/no-match behavior and whether results are paginated.

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% for the single query parameter, so the baseline is 3. The description adds genuine semantics on top: it accepts name, ticker or CIK, and clarifies that a name query resolves to a best match plus additional matches, which affects how the agent should interpret results.

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

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

Names the resource precisely ('A US company that files with the SEC') and the three accepted identifier types, then enumerates the returned data, so an agent knows exactly what this tool yields. The 'US' qualifier implicitly separates it from uk_company_lookup in the sibling list, but no sibling is named 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 implied by the resource described (use this for SEC-filing US companies), and 'A name returns the best match plus other matches' tells the agent how to interpret a fuzzy query. There is no explicit when-not-to-use or named alternative (e.g., uk_company_lookup for UK entities, or which tool to use for officers).

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 read-only and open-world behavior, and the description adds important context: no API key required, x402 payment, $0.10 USDC per successful call, and supported chains. It does not explain payment failure behavior, rate limits, or x402 flow details, so it is strong but 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?

The core capability is front-loaded and the text is dense with useful detail rather than filler. The platform list and pricing note are compact and each serves a clear purpose.

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 returned data: platform existence, public profile fields, and mention counts. It leaves some details unspecified, such as response structure and behavior for absent platforms, but it is sufficient for an agent to understand the call's output and cost.

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

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

There is one required username parameter and schema description coverage is 100%, so the schema already carries parameter semantics well. The description does not add format details beyond the schema's 'with or without the @' note, 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 states a specific resource (one username), the exact platform set, and the aggregated result fields. The 'at once' framing distinguishes it from platform-specific lookup siblings, though it does not directly compare to the similarly scoped osint-username sibling.

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 cross-platform 'at once' scope, suggesting it is for aggregate username checks rather than per-platform lookups. However, the description names no alternatives and gives no explicit when-to-use or when-not-to-use 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 read-only and open-world behavior, so the description focuses on additional context: successful-call pricing via x402 and the absence of owner/registration data. It does not cover rate limits or failure behavior, but the payment detail is meaningful behavior beyond the 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?

The description is front-loaded with the core purpose, followed by a scope exclusion and pricing note. Every sentence adds useful information, and there is no boilerplate or redundant restatement of the tool name.

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

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

For a simple one-parameter read-only tool with no output schema, the description is complete: it lists the key returned fields, excludes owner/registration data, and explains the payment model. An agent has enough information 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 coverage is 100%, so the schema already documents the single required VIN parameter as a 17-character string. The description adds no additional syntax, formatting, or validation detail 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?

The description states exactly what the tool returns from a VIN — make, model, year, body, engine, plant, and safety recalls — and explicitly scopes out owner/registration data. This is specific enough that an agent can identify the resource and expected payload 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?

The use case is clear: decode a VIN and retrieve recalls. The description also gives a useful exclusion ("No owner or registration data") and pricing context, but it does not name alternatives or explicitly state when not to use this tool.

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

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

With readOnlyHint and openWorldHint already present, the description adds meaningful behavior beyond annotations: it explains the x402 payment model, cost per successful call, supported chains, and the important limitation that personal accounts are not exposed. It does not cover rate limits or failure behavior, but the added context is substantive.

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

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

The description is three tightly written sentences, front-loads the lookup result, then adds the privacy limitation and payment detail. Every sentence contributes useful information without waste.

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 does enough: it explains what is returned, the personal-account exclusion, and the payment model. Nothing critical is missing for an agent to decide whether and how to call it.

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

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

Schema description coverage is 100%, and the single parameter already specifies international digits-only format with an example. The description mentions the phone number concept but adds no syntax or formatting detail beyond the schema, so 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?

The description states a specific verb and resource: checking whether a phone number has a public WhatsApp Business profile and returning business name, photo, and badge. It clearly distinguishes WhatsApp Business data from personal accounts, though it does not explicitly name sibling alternatives such as phone_lookup or osint-phone.

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

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

Usage is implied by the WhatsApp Business focus, and the description usefully states that personal accounts are never exposed. However, it does not explicitly say when to choose this tool over general phone lookup siblings or when not to use it beyond the personal-account limitation.

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