Clearfront MCP Server

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

With no annotations provided, the description must fully disclose behavior. It states 'Passive, public-source collection', indicating non-destructive action, but does not describe return format, side effects, or authentication requirements. The safety profile is partially clear but incomplete.

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, front-loading the action and then providing usage guidance. Every sentence adds value without redundancy or excess 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?

For a simple tool with two parameters and no output schema, the description covers purpose and target types but omits output format (e.g., list of URLs) and error conditions. This leaves gaps for an agent to understand the full 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?

The description adds meaning to the 'target' parameter by specifying acceptable types (name, email, username, domain), which is not in the schema. However, the 'json_output' parameter is not described beyond its schema description. With 50% schema coverage, the description partially compensates.

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 verb 'Generate', the resource 'targeted Google dork URLs', and the scope 'for any target (name, email, username, domain)'. It effectively distinguishes from sibling tools that perform searches rather than generation.

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 includes an ethical usage note ('Authorized use only') but lacks explicit guidance on when to use this tool versus alternatives like 'search_dorks_live'. No prerequisites or context for selection are provided.

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

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

With no annotations provided, the description fully discloses behavioral traits: parallel execution, report generation, max targets, API key requirement, authorization, and passive nature. This leaves no ambiguity about tool 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?

The description is concise with key information front-loaded. It covers essential aspects in 5 sentences without fluff, though a slightly more structured format could improve 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?

Given one parameter and no output schema, the description comprehensively covers limitations, requirements, ethical use, and scope. It provides sufficient context for an agent to decide invocation.

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

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

Schema description coverage is 100% for the single 'targets' parameter, which already lists item types and max. The description adds context about authorization and passive collection but does not significantly enhance parameter meaning beyond 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 clearly states the tool investigates multiple targets in parallel using the full OSINT tool chain, producing per-target and summary reports. This distinguishes it from sibling tools that are single-target or single-source searches.

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 specifies maximum 10 targets, requirement for ANTHROPIC_API_KEY, authorized use only, and passive public-source collection. It provides clear context for when to use, though does not explicitly exclude 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?

No annotations provided, so the description carries full burden. It discloses bypassing mechanisms, output format, and authorization requirements. However, it does not describe error behavior, rate limits, handling of invalid URLs, or the exact behavior of json_output parameter (which may return structured JSON despite the description stating 'Returns as clean Markdown').

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 focused sentences convey purpose, capabilities, requirements, and constraints without any wasted words. The description is efficiently front-loaded with the key functionality.

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 the tool's moderate complexity (2 params, no output schema), the description covers the essential aspects: what it does, prerequisites, authorization, and output format. Minor gaps include error handling, rate limits, and the exact nature of JSON output, but overall it provides sufficient context for safe and effective use.

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 50% (only json_output has a description). The description adds context for the url parameter (target URL) and implies json_output changes output from Markdown to JSON. However, details like URL format, encoding, max length, and the exact structure of JSON output are missing.

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 verb (fetch/scrape), the resource (any public URL), and the specific capabilities (bypassing Cloudflare, CAPTCHA, bot-protection) with a clear output (clean Markdown). It naturally distinguishes from sibling search tools which focus on querying databases or services.

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 explicitly names required environment variables (BRIGHTDATA_API_KEY, BRIGHTDATA_UNLOCKER_ZONE) and provides authorization guidance ('your own assets or authorized target'). While it doesn't explicitly contrast with alternatives, the tool's unique purpose among siblings makes the usage context clear.

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

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

Describes return values, warning behavior above 50% score, and passive nature. With no annotations, description carries full burden; it is mostly transparent but omits details like rate limits or error 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?

Four sentences, each adds unique value: purpose, returns, warning, prerequisites, authorization. No redundancy, 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?

Covers all essential aspects for a simple 2-parameter tool with no output schema: purpose, return data, warning, prerequisites, and usage authorization. Agent can use 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 50% with only json_output described. Description adds meaning for the ip parameter implicitly but does not specify format or constraints. Baseline 3 due to partial compensation.

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?

Clearly states it checks an IP address against AbuseIPDB for abuse reputation, specifying key returned data. Distinguishes from sibling IP tools by naming the specific source and data returned.

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 mentions required API key environment variable and authorized use conditions. Does not list alternatives or when not to use, but context from sibling tools provides differentiation.

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?

Notes it's passive and public-source, implying read-only. No annotations, so description bears full burden. Lacks detail on return format, rate limits, or data freshness.

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

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

Three sentences, front-loaded with main purpose, no waste. Efficient and well-structured.

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 and no annotations; description omits return type (e.g., boolean, list of breaches). Incomplete for a query 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 coverage 50% (only json_output described). Description adds meaning for email (primary query input) but doesn't clarify its format. Baseline 3 due to partial 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?

Clearly states it checks email against data breaches via HaveIBeenPwned, with explicit verb and resource. Distinguishes from sibling tools like search_email (general lookup) and search_exposure (broader).

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?

Provides prerequisites (HIBP_API_KEY) and authorization policy. Does not explicitly exclude alternatives or contrast with siblings, but context is clear enough.

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

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

With no annotations provided, the description must fully disclose behavior. It specifies the tool is passive, public-source, requires authorization, and distinguishes IP vs domain capabilities. However, it omits details on rate limits, error handling, and response format.

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

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

Four sentences, each adding essential information: purpose, examples, usage constraints, and authorization. Front-loaded with the core purpose, no wasted words.

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 no output schema, the description adequately covers return data for IP and domain. It does not mention pagination or error scenarios, but for a search tool of this nature it provides sufficient context 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?

The schema has 50% description coverage (only json_output described). The description compensates by explaining the 'target' parameter with examples of how different inputs (IP/domain) yield different data. The json_output flag is not elaborated, but the schema already describes it.

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 ('Search') and resource ('Censys for internet-facing infrastructure data'), with concrete examples for IP and domain queries. It clearly distinguishes from sibling search tools by specifying the data source (Censys).

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 when to use (searching internet infrastructure), prerequisites (CENSYS_PAT), limitations (free vs paid), and ethical boundaries (authorized use only). It provides good context but does not explicitly contrast with alternative sibling tools.

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

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

Describes behavior as passive, keyless, and using public CA logs, which is sufficient for a non-destructive tool. No annotations provided, so description carries weight. Lacks details on rate limits or output size, but core behavioral traits are 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 sentences, front-loaded with purpose, then usage and behavioral notes. No unnecessary words, but could be more structured by separating guidelines from behavioral traits. Still concise and efficient.

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?

Lacks details on return format, pagination, or limits. No output schema provided. While common knowledge for crt.sh, a newer AI agent might benefit from knowing whether results are truncated or how to handle large outputs. Adequate but not complete.

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

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

Description does not elaborate on parameter semantics. Schema describes json_output but not domain. The description adds no meaning beyond the schema; e.g., it doesn't specify domain format or constraints. Schema coverage is 50%, and description fails to compensate.

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

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

Clearly states it enumerates subdomains via crt.sh certificate transparency logs. This is a specific verb and resource, distinguishing it from sibling tools like search_dns or search_censys which use different data sources.

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?

Provides explicit guidance: keyless, passive, public-source collection, and authorized use only. It surfaces non-resolving internal/staging hosts, implying use for passive reconnaissance. Does not explicitly mention when to avoid or alternatives, but context is clear.

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

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

Without annotations, the description carries full burden. It discloses read-only behavior ('Passive, public-source collection') and keyless access. However, it lacks details on error handling, rate limits, or what happens for invalid addresses.

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

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

Three sentences, no redundancy, and the main action is front-loaded. Every sentence adds value 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 tool with 2 parameters and no output schema, the description covers purpose, input summary, and output contents (balance, transactions, total received). It is mostly complete but could mention potential errors.

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 50%, and the description does not add any parameter-specific meaning beyond the schema. The 'address' parameter is not described, and 'json_output' is only described in schema. The description should clarify valid address formats or input constraints.

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

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

The description clearly states it validates a Bitcoin or Ethereum address and returns a keyless on-chain summary. This specific verb+resource combination distinguishes it from sibling tools that search for other data types.

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 an explicit authorization requirement ('Authorized use only'), which is a clear usage guideline. However, it does not directly compare to sibling tools or state when not to use it. Given the siblings are distinctly different, this is adequate.

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

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

With no annotations, description carries full burden. Mentions no external API or credentials required and passive public-source collection, but does not disclose any limitations, rate limits, or performance characteristics.

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 plus usage note, no redundant or irrelevant content. Efficiently conveys key 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?

Lacks output schema; description mentions record types and misconfigurations but does not specify return format or structure. While informative for a DNS enumeration tool, omits some expected behavioral 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 50% (only json_output has description). Description does not add parameter-level details; domain is implied but not explicitly described. Fails to compensate for the missing schema descriptions.

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

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

Description explicitly states it enumerates DNS records (A, AAAA, MX, etc.) and highlights email security misconfigurations. Clearly distinguishes from siblings like search_domain.

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?

States authorized use only (own assets or authorized targets). Does not explicitly say when not to use or suggest alternatives, but provides sufficient context for appropriate use.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions passivity and public sources but omits details on rate limits, response format, or any side effects, leaving significant gaps.

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 extremely concise with two sentences, no fluff, and the main action is front-loaded. Every sentence adds value.

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?

Without output schema or additional behavioral details, the description lacks completeness. It does not explain return values, error handling, or pagination, which is important for a subdomain enumeration 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 coverage is 50% with domain having no schema description. The description does not elaborate on parameter usage or format, failing to compensate for the missing schema detail.

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 tool enumerates subdomains of a target domain using sublist3r, providing a specific verb and resource. However, it does not explicitly differentiate from sibling tools like search_harvester which also enumerates subdomains.

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 includes an authorization condition and notes that the collection is passive and from public sources. However, it lacks guidance on when to use this tool versus alternatives such as search_dns or search_harvester.

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

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

With no annotations, description discloses it is a paid API call, requires specific secrets, is passive and read-only, and returns live results. It doesn't detail error handling or rate limits, but for a search tool this is sufficient 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?

Three sentences that front-load the core purpose, then add essential details (billing, setup, legal). No extraneous words; every sentence earns its place.

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

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

For a 2-parameter tool with no output schema, the description covers what the tool does, data source, result structure, default behavior, prerequisites, and legal context. Complete enough for an agent to use 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 50% (only json_output has description). The description adds context for 'target' as the search target but doesn't specify format. It does not elaborate on json_output beyond what schema already provides; baseline 3 is appropriate given partial 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 it executes Google dork queries via Bright Data SERP API and returns structured results with title, URL, and snippet. It distinguishes itself from sibling tools like search_email or search_domain by explicitly focusing on dork queries.

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?

Describes when to use (for dork queries), mentions default limit of 5 dorks, billing implications, required env vars, and authorized use. However, it does not explicitly state when not to use this tool instead of alternatives like search_domain or search_crt.

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

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

No annotations provided, so description bears full burden. It mentions passive public-source nature and use of holehe, but does not disclose rate limits, reliability, or what happens on failure. Some behavioral context is given but insufficient.

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 concise sentences: purpose, authorization, nature. No wasted words. Front-loaded with key info.

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 no output schema and simple parameters, the description covers purpose and authorization but omits output format (except json_output) and limitations. Acceptable but not thorough.

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 50% (only json_output has description). The description adds no parameter-level details beyond what schema gives. 'email' is obvious, but no clarification on format or constraints.

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

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

The description clearly states it uses holehe to enumerate accounts linked to an email. It distinguishes from sibling tools (e.g., search_username, search_maigret) by targeting email specifically. Verb+resource is 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?

Explicitly states 'Authorized use only: your own assets or a target you are authorized to assess.' Also notes passive, public-source collection. Could mention alternatives like search_breach for data breaches, but the authorization guidance is strong.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It states the tool is passive and public-source, implying no destructive effects, but lacks details on rate limits, error handling, or network dependencies. This is adequate but not exhaustive.

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

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

The description is three sentences, each serving a distinct purpose: tool function, prerequisites, and ethical use. It is front-loaded with the core purpose and contains no redundant 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?

Given no output schema and moderate schema coverage, the description covers the key aspects: tool function, data source, authorization, and passivity. It could be improved by mentioning output format or potential errors, but overall it is sufficiently complete for an AI agent.

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 covers 50% of parameters (json_output has a description). The description adds context by explaining the overall purpose and what the email parameter is used for (reputation checks). It does not further elaborate on json_output beyond the schema, so the added value is moderate.

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 provides an email reputation and footprint summary via EmailRep.io, including profiles seen and breach/abuse flags. This is specific to a single service and distinguishes it from sibling tools like search_breach or search_email which may have different scopes.

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 explicitly requires the EMAILREP_API_KEY and restricts use to authorized assets, providing clear ethical guidelines. It also notes the passive, public-source nature. However, it does not differentiate from other email-related tools or specify 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?

No annotations are provided, so the description bears full responsibility. It discloses that it uses exiftool, is passive/public-source, and flags GPS location. However, it does not mention whether it modifies the file or any side effects, which is acceptable given the read-only nature implied by 'passive'.

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 long with an additional authorization sentence. It front-loads the core action and avoids redundancy. Every sentence adds value.

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?

Without an output schema, the description should detail the return format. It lists some metadata fields but does not specify whether output is always JSON or text, or how errors are handled. The presence of a json_output parameter suggests configurable output, which is not explained.

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 50% (only json_output has a description). The description clarifies that the 'file' parameter is a local file path, adding value beyond the schema. However, it does not explain the json_output parameter beyond what the schema already says, leaving the default output format unmentioned.

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 explicitly states the tool extracts embedded metadata (EXIF/IPTC/XMP) from a local file using exiftool, listing specific fields like camera make/model, GPS coordinates. This clearly distinguishes it from sibling tools that search online or perform other operations.

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 clear authorization guidelines: 'Authorized use only: your own assets or a target you are authorized to assess.' It does not explicitly compare to alternatives, but the local file focus inherently differentiates it from sibling tools. No when-not-to-use or 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?

With no annotations, the description discloses behavioral traits: 'Passive, public-source collection' indicates a safe read operation. It also mentions authorized use, adding transparency beyond what the schema provides.

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 concise sentences: first states purpose and content, second gives usage tip, third adds legal/ethical context. No wasted words.

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 no output schema and 2 params, the description covers the tool's output types and usage context well. It lacks output structure details but is sufficient for agent understanding.

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 50% (only json_output described). The description adds meaning for the ip parameter (omit or pass 'me' for own IP) but does not detail format or constraints for either parameter fully.

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 it provides a 'Risk-ranked IP exposure report' with specific data types (geolocation, ASN, reverse-DNS, DNS blocklists, VPN/Tor flags), distinguishing it from sibling tools like 'search_ip' which likely offers basic IP info.

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 context on when to use (risk-ranked exposure) and includes a specific usage tip ('Omit ip or pass me'). It also notes authorized use but does not explicitly state when not to use or provide 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?

With no annotations, the description fully discloses key behaviors: passive public-source collection, billing per query, automatic source switching (DuckDuckGo vs. Bright Data), and authorization. No destructive or unintended behaviors are omitted, though it could mention rate limits or result 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 four sentences, each serving a distinct purpose: core action, output format, source mechanics, and usage policy. No redundant words; information is front-loaded. It efficiently packs multiple aspects without being verbose.

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 the tool's complexity (multi-entity search, graph output), the description covers purpose, output (structured results and graph nodes/edges), source, billing, and authorization. Without an output schema, it explains return values adequately. Missing details like result count limits or pagination prevent a perfect score.

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 67%, with json_output and max_queries already described. The description adds critical context for the target parameter by listing valid entity types (email, username, domain, phone, full name), which the schema lacks. This goes beyond the baseline of 3 for high coverage, though some meaning is still inferred.

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 tool finds 'real public profiles' across multiple entity types (email, username, domain, phone, full name), which distinguishes it from sibling tools like search_email or search_username that focus on a single type. The verb 'search' combined with specific resource and entity-awareness provides high clarity.

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 includes authorization requirements ('Authorized use only') and notes the default source (DuckDuckGo) and optional Bright Data usage. However, it does not explicitly compare against sibling tools or state when not to use this tool, which slightly reduces guidance strength.

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

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

No annotations are provided, so the description carries full burden. It discloses return types, secret/key search with token, rate limits, and passive nature. No destructive or contradictory behavior is implied.

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?

Six sentences, front-loaded with core purpose, then details in logical order. No wasted words.

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, so description must explain returns. It does: full profile/repos/emails for exact username, top 5 accounts otherwise, plus secrets/keys search. Also covers rate limit and authorization.

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 has 2 params with only json_output described. Description adds rich context for query (accepts username, email, keyword) and explains behavior based on query type, compensating for meaning 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 clearly states the tool searches GitHub for a username, email, or keyword, and it differentiates behavior for exact username matches vs other queries. This verb+resource combination is specific and distinguishes it from sibling search 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 explains when to get full profile vs top 5 matches, and includes an authorization note. It does not explicitly contrast with sibling tools like search_username, but the context signals provide differentiation.

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

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

With no annotations, the description discloses that the tool is passive and public-source, implying no destructive side effects. It lists the type of data returned, which provides transparency beyond the name alone.

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 concise sentences: first states purpose and output, second gives usage guideline, third notes passive nature. No filler or redundant information.

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

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

For a simple lookup tool with two parameters, the description covers purpose, authorized use, data returned, and operational nature. Lacks mention of behavior when email has no Gravatar, but overall adequate.

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 has 50% coverage (only json_output has a description). The description does not elaborate on the email parameter beyond the verb 'look up', but the parameter name is self-explanatory. The json_output parameter is already described in 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 clearly states the verb 'Look up', the resource 'email's public Gravatar profile', and lists specific data fields (avatar, display name, bio, location, linked/verified accounts). It distinguishes from sibling tools by specifying Gravatar as the service and notes it as passive, public-source collection.

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?

Includes explicit authorization requirement ('Authorized use only: your own assets or a target you are authorized to assess') and notes the passive nature. However, it does not provide when-not-to-use or compare with alternatives like search_email.

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

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

No annotations provided, but the description discloses the passive, public-source nature and the rate limit. It does not discuss error handling or behavior on exceeding limits, but the core behavioral traits are 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?

Three sentences: purpose/results, rate limit, authorization. Front-loaded with key information, no redundant words.

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, but the description enumerates return fields. It covers authorization, rate limits, and data source. Lacks error handling details but is sufficient for a simple IP lookup with the given complexity.

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 50% (json_output has a description). The description adds value by listing output fields but does not clarify the expected format for the ip parameter (e.g., IPv4/IPv6, CIDR). This partially compensates but leaves a gap.

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

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

The description clearly states the tool checks an IP against the GreyNoise Community API, explains its purpose (distinguishing internet background noise from targeted actors), and lists returned data (classification, noise/RIOT flags, org, last-seen). This differentiates it from sibling tools like search_shodan or search_virustotal.

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?

Provides explicit context: rate limit of 50 lookups/week and authorized use requirement. However, it does not specify when not to use or suggest alternative tools, which would improve 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?

The description emphasizes 'passive only, no active probing' and 'passive, public-source collection,' clearly disclosing non-invasive behavior. However, without annotations, it omits details on authentication requirements, rate limits, or data handling practices.

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 concise with three sentences, front-loading the core purpose and key constraints (passive, authorized use). Every sentence adds value without redundancy.

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 no output schema and only two parameters, the description covers the tool's purpose and passivity but lacks information on return values, pagination, or error handling. Adequate for a simple passive search tool but not fully 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 coverage is 50% with only the 'json_output' parameter having a description; the 'domain' parameter has no schema description. The tool description does not add parameter-specific details beyond what is already in the schema, failing to compensate for missing schema descriptions.

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

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

The description clearly states the tool performs passive organization/domain recon using theHarvester to gather emails, people, and subdomains from public sources. The verb 'recon' and specific resource types distinguish it from siblings like search_domain or search_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 mentions authorized use only, but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. It implies usage for passive domain recon but lacks exclusion 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?

With no annotations, the description fully discloses behavioral traits: uses free masked tier, never returns passwords or login URLs, passive public-source collection. It also states output includes metadata (count, dates, OS, etc.). No contradictions with missing 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 in the first sentence. It covers usage, behavior, and output in a single paragraph without redundancy. Every sentence adds value.

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 2 params, no output schema, and no annotations, the description sufficiently covers purpose, usage, behavior, and output format. It explains limitations (masked tier, no passwords) and metadata contents. The agent can decide and invoke correctly.

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

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

Schema coverage is 50% (only json_output described). The description adds meaning by clarifying that 'target' is an email or username and that the output reports exposure and metadata. It compensates for the undocumented parameter and provides useful context 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 specifies a clear verb and resource: 'Check whether an email or username appears in Hudson Rock's free Cavalier infostealer index'. It distinguishes from sibling tools by focusing on malware-stolen credentials from a specific source, with explicit output details (exposure yes/no plus infection metadata).

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 clear usage context: 'AUTHORIZED-USE ONLY: for your own or an authorized identifier's exposure so credentials can be rotated.' It also notes keyless access and passive collection. It does not explicitly name alternatives but provides sufficient guidance on appropriate use.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool performs passive, public-source collection via ipinfo.io, and highlights authorized use. This adequately covers the behavioral traits for a simple lookup tool, though rate limits or data freshness are not mentioned.

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 sentences long, information-dense, and front-loaded with the core action. Every sentence adds value: function, usage variation, and authorization. No redundancy.

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 low-complexity tool with no output schema, the description explains input parameters and the nature of the data. The json_output parameter covers return format. It is complete enough for an agent to correctly invoke the tool, though example usage or expected output structure could be added.

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 has two parameters with 50% description coverage (json_output has a description, ip lacks one). The description adds significant value: it explains the 'ip' parameter can be omitted or set to 'me' for auto-detection, and clarifies the purpose (geolocation and ASN data). This compensates for the missing schema description.

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

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

The description clearly states the tool retrieves geolocation and ASN data for an IP address using ipinfo.io. It also specifies the optional auto-detect feature. This is distinct from sibling tools which target emails, usernames, domains, etc., providing clear differentiation.

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 includes authorization requirements ('Authorized use only: your own assets or a target you are authorized to assess') and notes that omitting 'ip' or passing 'me' auto-detects the caller's IP. While it does not explicitly state when to use this tool over alternatives, the context of IP lookup versus other search domains makes it clear.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool is passive and uses public-source collection, and lists the types of data returned. It does not cover rate limits or error handling, but the key behavioral traits (read-only, API key needed) are clear.

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?

Five focused sentences with no redundancy. Each sentence adds distinct value: enhanced capability, output details, sponsorship, prerequisite, usage restriction, and passive nature. Front-loaded with 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?

For a tool with no output schema, the description adequately describes return values (geolocation, ISP, ASN, detections). It also covers authorization and API key requirements. It is slightly lacking in error handling details (e.g., invalid IP, missing API key), but overall complete for the scope of this 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 coverage is 50% (json_output described in schema). The description does not add parameter-specific details beyond the schema's description of json_output. For the 'ip' parameter, the description implies it is an IP address but provides no format or constraints. Baseline 3 is appropriate as description adds minimal value over 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 clearly states it provides 'Enhanced IP intelligence' including geolocation, ISP, ASN, and detection of VPN, proxy, Tor, and datacenter hosting. This distinguishes it from simpler sibling tools like search_ip by specifying the additional detection capabilities.

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 explicitly mentions the requirement for IP2LOCATION_API_KEY and authorized use only for own assets or authorized targets. It implies use when enhanced intelligence (VPN/proxy detection) is needed, but does not directly contrast with alternative sibling tools like search_greynoise or search_abuseipdb.

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

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

With no annotations, the description must carry full weight. It indicates passive, read-only behavior and authorization requirements, but lacks details on rate limits, error handling, or specifics of profile detail extraction.

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 efficiently convey purpose and usage constraints without extraneous information, front-loading the core action.

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 the tool's complexity (3,400+ sites), lack of output schema, and sibling competition, the description is brief and omits return format, result interpretation, and what 'profile details' entails.

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 50% (json_output described, username not). The description adds no parameter-specific guidance, such as expected username format or behavior of json_output, failing to compensate for the schema's gap.

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

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

The description clearly states the tool performs broad username/identity discovery across 3,400+ sites using maigret, and distinguishes itself from sibling tools like search_username by emphasizing breadth and profile detail extraction.

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 explicitly mandates authorized use only and notes passive, public-source collection, providing clear context for when the tool is appropriate. However, it does not contrast with alternatives or state when not to use.

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

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

With no annotations, the description carries the full burden. It mentions passive, public-source collection and HIBP paste index, but does not discuss any side effects, rate limits, or output behavior beyond mentioning json_output. It is adequate but not rich in behavioral detail.

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 sentences, each providing critical information: purpose, authorization, and passive nature. No wasted words; the information is front-loaded and concise.

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 the tool has only 2 parameters, no output schema, and no nested objects, the description is complete enough. It covers the query source, authorization, and passive nature. It might benefit from mentioning default output format, but for a simple tool this is sufficient.

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 covers 50% of parameters (json_output described). The description adds value by specifying that query is an email or username, which is not stated in the schema. For json_output, the schema already provides a description. Overall, the description compensates for the schema's lack of query semantics.

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

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

The description clearly states the tool's purpose: searching public paste sites for an email or username using HIBP and search-engine dorking. It distinguishes itself from sibling tools like search_breach (focused on breach data) and search_dork (which may search different sources).

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 explicitly states authorized use only and passive public-source collection, giving clear guidance on when to use the tool. It does not explicitly list alternatives, but the context implies when not to use (e.g., unauthorized or active collection).

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

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

With no annotations, the description carries the full burden. It states the tool is 'passive' and uses 'public-source collection', indicating non-destructive, read-only behavior. More detail on rate limits or error handling would improve it.

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 concise sentences front-load the core purpose, followed by format and usage restrictions. No wasted words.

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 tool (2 params, no output schema), the description covers input format, authorization, and tool behavior. It could mention the type of data returned (e.g., carrier name, location), but is otherwise 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 coverage is 50%, but the description adds 'Use E.164 format' for the phone parameter, which is not in the schema. The json_output parameter has a description in the schema, so the overall meaning is enhanced.

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 verb ('gather') and resource ('carrier and geolocation data for a phone number'), and distinguishes from siblings like search_email and search_username by specifying the use of phoneinfoga.

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 includes format requirements ('E.164') and authorization conditions ('Authorized use only'). While it doesn't explicitly name alternatives, the sibling tools cover different data sources, making the context clear.

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

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

With no annotations, description fully discloses behavior: passive, public-source collection, non-destructive, requires API key, and authorized use. Explains how different query types are handled.

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?

Six sentences, front-loaded with purpose. Every sentence adds value with no redundancy. Efficient and well-structured.

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

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

Covers input, requirements, and authorization. Lacks detail on output format for keyword search (only host lookup output is described). With no output schema, a bit more on return structure would improve 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?

Schema lacks description for 'query'; tool description compensates by explaining query semantics (IP vs other string) and resulting behavior. For 'json_output', description echoes its schema documentation.

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?

Description states clear verb 'Query' and resource 'Shodan', distinguishes behavior for IP vs other strings, and lists returned data (open ports, org, CVEs) for host lookup. Differentiates from siblings by specifying Shodan-specific behavior.

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?

Provides clear context for when to use: host lookup or banner search based on query type. Mentions required env var and authorization. Does not explicitly compare to sibling tools or state when not to use.

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

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

No annotations provided, so description carries full burden. It describes the tool as passive, public-source collection using specific tools, but lacks details on process (e.g., concurrent queries, rate limits) or error 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 concise sentences: first covering purpose and method, second usage guidelines. No wasted words, front-loaded with key 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?

Covers purpose, method, and authorization, but lacks output details. Since no output schema exists, description should hint at result format or behavior when username not found, which it does not.

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 50% with only json_output described. The description does not add meaning beyond the schema for either parameter; username lacks any format or constraint details. Minimal enrichment.

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 tool enumerates and verifies platforms where a username is registered, using specific sources (sherlock and WhatsMyName subset). It distinguishes from sibling tools focusing on other entities like domains or emails.

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

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

Explicitly states authorized use only and passive nature. While it does not compare to sibling tools, it provides clear context for when to use (authorized assessment of own assets or authorized 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?

Without annotations, the description provides key behavioral context: it is passive (read-only) public-source collection, auto-detects input type, and requires authorization. It does not detail rate limits or error handling, but the passive nature is well conveyed.

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 sentences with no wasted words. It front-loads the purpose, then adds requirements and usage policy. Each sentence adds distinct value.

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 the tool has only 2 parameters, no output schema, and no annotations, the description covers input types, requirements, and ethical boundaries. It could detail the expected output format better, but the json_output parameter helps. Overall, it is adequate for simplified selection.

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 description adds significant meaning to the 'target' parameter by listing acceptable input types (IP, domain, URL, file hash) and noting auto-detection. The 'json_output' parameter already has a schema description, but the description clarifies the tool's capabilities beyond the schema's sparse coverage (50%).

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 specifies the tool checks IP, domain, URL, or file hash against VirusTotal's 70+ antivirus engines and threat intelligence. It clearly states the action (check) and the resources (various input types), distinguishing it from sibling tools that focus on other data sources.

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 explicitly requires the VIRUSTOTAL_API_KEY environment variable and restricts use to authorized assets. It implies usage for threat intelligence, but does not explicitly state when not to use it versus siblings like search_ip or search_domain.

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

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

With no annotations provided, the description carries the transparency burden. It mentions passive, public-source collection and the keyless CDX API, indicating non-destructive behavior. However, it lacks details on rate limits, pagination, or output format, which would be helpful for an AI agent.

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 sentences, front-loaded with the core function. It is efficient but the final phrase 'Passive, public-source collection' slightly repeats earlier information. Overall, it earns its 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?

For a simple tool with two parameters and no output schema, the description covers key aspects: domain-based listing, passive collection, and pairing with scrape_url. However, it omits details on output format (beyond json_output) and any pagination or size limits, leaving gaps for a complete understanding.

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 50% (only json_output has a description). The description adds meaning by implying target is a domain, but it does not explicitly describe the target parameter's format or constraints. The json_output parameter is already explained in the schema, so no addition there.

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 it lists URLs archived under a domain in the Internet Archive via the keyless CDX API. It specifies the tool's passive nature and use case: recovering deleted, forgotten, or historical pages. This distinguishes it from sibling search tools that target other sources.

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 explicitly pairs this tool with scrape_url to fetch recovered pages, providing a clear workflow. It also states authorized use only. However, it does not explicitly mention when not to use this tool or list alternative sibling tools, limiting full 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?

With no annotations provided, the description carries the full burden. It discloses the tool is passive and collects from public sources, indicating safe behavior. It does not mention any destructive or rate-limiting aspects, but overall it transparently describes the tool's nature.

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, front-loading the core purpose first, then usage and behavior. Every sentence adds value with no redundancy.

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 no output schema and simple parameters, the description covers purpose, usage restrictions, and passivity. It could mention the response format (e.g., raw HTML or JSON) but is adequate for a straightforward 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?

The schema coverage is 50% (only json_output has a description). The description does not add any meaning to the 'domain' parameter (e.g., expected format, example). It should compensate for the lack of schema description but does not.

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 tool retrieves WHOIS registration data for a domain, specifying the verb 'Retrieve' and the resource 'WHOIS registration data'. This distinguishes it from sibling tools that search other types of data (IPs, emails, etc.).

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 explicitly states authorized use for own assets or authorized targets, providing ethical guidelines. However, it does not compare to alternatives or specify when not to use this tool, which would have made it clearer.

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