openosint

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

No annotations are provided, so the description bears full responsibility for behavioral transparency. It only states the generation function and does not disclose any behavioral traits such as whether it is read-only, requires authentication, or has rate limits. The description lacks sufficient detail for an agent to understand side effects or limitations.

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 a single, well-structured sentence that is front-loaded with the key action and resource. Every word contributes meaning, with no redundancy or 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?

The description adequately explains what the tool does given its simplicity (2 params, no output schema). However, it does not describe the return format (e.g., list of URLs, JSON structure) or provide any context on how the URLs are generated. For a tool with no output schema, this omission leaves the agent partially uninformed.

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 significant value by clarifying the 'target' parameter, providing concrete examples ('name, email, username, domain') that are not in the schema. This helps the agent understand acceptable inputs beyond the raw type definition.

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 action ('Generate') and the resource ('targeted Google dork URLs'), and specifies the types of targets it accepts ('name, email, username, domain'). This distinguishes it from sibling search tools that query databases rather than generate URLs.

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 implies this tool is used for generating dork URLs, distinct from the sibling search tools that perform actual searches. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It does this well by stating the graph is additive, the exact output format (NDJSON, one FtM entity per line), and that whole datasets can be omitted via exclude_datasets. It also warns about the installation requirement. It does not mention what happens when no data exists or whether output is streamed, but these are minor omissions for an export 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 carry all essential information: the action, the resource, the output format, the optional exclusion mechanism, and the installation prerequisite. It is front-loaded with the main purpose and contains no filler or redundant statements. 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 tool with two optional parameters and no output schema, the description provides a clear picture of what the tool emits and how to control dataset exclusion. The only notable gap is the interplay between json_output and the default NDJSON export: the schema says json_output returns structured JSON, but the description does not reconcile this with the NDJSON line-by-line format. Still, the agent can call the tool correctly with just this description.

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 input schema already covers both parameters with descriptions, so the baseline is 3. The description adds value by giving a concrete exclude_datasets example and clarifying that excluding a dataset removes 'every breach-derived fact'. It does not add much to json_output, but that parameter is already well described in the schema. Overall, the description meaningfully enriches the parameter semantics 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 names a specific verb ('Export'), a specific resource ('the additive FollowTheMoney entity graph'), and the output format (newline-delimited JSON, .ftm-compatible). It clearly distinguishes itself from the sibling graph tools like graph_neighbors and graph_review_candidates, which are about querying or reviewing rather than exporting the whole graph.

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 no explicit guidance on when to use this tool versus the graph_neighbors or search_* siblings. It does explain a prerequisite ('Requires the graph extra') and an optional exclusion pattern, but does not state when exporting is appropriate or when another tool would be a better fit. The usage context is only implied by the tool name and the export-focused wording.

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 behavioral burden and does well: it discloses return contents, the optional cross-layer behavior, and the installation prerequisite. It does not discuss failure behavior, performance at max depth, or output format defaults, but the read-oriented nature of traversal is apparent from the wording.

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, each earning its place: one states the core action and output, one explains the optional cross-layer behavior, and one gives the installation prerequisite. Information is front-loaded and there is no redundant 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?

For a tool with no output schema and no annotations, the description is sufficiently complete: it states what is returned, the key optional behavior, and the required dependency. Missing details such as exact JSON shape or invalid entity handling are non-critical for invoking the tool correctly given the schema covers depth and output flags.

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 75%, so the baseline is 3. The description adds meaning for entity_id ("from one entity id") and enriches cross_layer ("surface bridge links into the raw infra correlation graph - IPs, domains, hashes"), going beyond the terse schema text. It appropriately does not need to restate depth or json_output since the schema already documents them.

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 and resource: "Traverse the FollowTheMoney entity graph from one entity id out to a given depth," and states the output contents (entities, edges, per-edge provenance). It is clear and distinct from the sibling tools in focus, though it does not explicitly name a sibling alternative to distinguish against.

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 implies when to use the tool: when you need to traverse from a known entity id and see connected entities with provenance. It also gives context for setting cross_layer=true and mentions the 'graph' extra requirement, but it does not explicitly compare to alternatives like graph_export or investigate_multi or 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?

With no annotations, the description carries full burden and does so well: it reveals that reject permanently excludes future suggestions, that accept merges, that no auto-merge happens, and that this is the only write path for judgement='positive'. These are exactly the side effects 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 description is dense but every clause carries information: purpose, action modes, filters, verdict semantics, side effects, and authority. It front-loads the core purpose and uses punctuation to separate related facts without 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 10-parameter tool with no output schema or annotations, the description provides enough to invoke list or decide correctly and understand consequences. The main gap is that return values are not described beyond the candidate fields listed, though json_output hints at structured output.

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 80%, so the schema already handles most parameter meaning. The description adds value beyond schema by grouping parameters into list filters (schema, score range, dataset) and decide fields (pair, decision, reviewer), and by mapping decision values to judgement outcomes.

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 opening sentence names a precise resource (human review queue for graph-dedup same_as matches) and the two actions it supports. This clearly distinguishes it from graph_export/graph_neighbors and the search_* 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?

The description gives explicit conditions for each action: action='list' for pending candidates and filters, action='decide' for recording accept/reject verdicts. It does not name sibling alternatives that would cover the same job, hence 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?

With no annotations, the description carries the behavioral burden and does substantial work: it discloses parallel execution, per-target report generation, summary generation, the 10-target cap, and the ANTHROPIC_API_KEY dependency. It does not detail how reports are returned or whether artifacts persist, but the core operational traits 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?

Four short sentences, each carrying a distinct fact: action, output artifacts, limit, and authentication requirement. The purpose statement 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?

The description covers the single parameter well and reveals major behavioral details, but with no output schema it should also explain how the agent receives or accesses the generated reports. That missing return-value detail makes this minimally viable 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 description coverage is 100%, so the baseline is 3. The description only restates the 10-target limit already in the schema and adds no additional meaning about target formatting, type validation, or edge cases.

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 action (investigate) with a clear resource (multiple targets) and a distinguishing mode (parallel execution using the full OSINT tool chain). The per-target report files and summary report further differentiate it from the single-source search_* 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?

Gives clear context for when to use the tool: batch investigation of multiple targets in parallel, with a hard limit of 10. It does not explicitly name excluded alternatives, but the batch-vs-single-target framing provides a strong selection signal.

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 discloses key behaviors: bypassing Cloudflare/CAPTCHA/bot-protection and returning clean Markdown. However, it does not mention the json_output parameter's effect (JSON return), nor failure modes, rate limits, or consequences of non-public URLs. This leaves gaps in what an agent should expect when invoking the 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?

The description is two concise sentences with no fluff. The primary action is front-loaded ('Fetch any public URL'), and the key capabilities and dependencies are stated immediately. Every word earns its place, making it easy for an agent to parse quickly.

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 fetch tool with no output schema, the description covers the main action and return format, but omits the conditional json_output behavior. It also does not mention error handling, timeout limits, or what counts as 'public'. These gaps could lead an agent to misassume behavior, especially when json_output=true is set. The description is adequate 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% (json_output has a description, url does not). The description adds the 'public' constraint to the url parameter, which is useful but minimal. It does not clarify URL format requirements or how json_output interacts with the Markdown output. The added semantic value is modest and does not fully compensate for the undocumented url parameter.

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

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

The description uses a specific verb ('Fetch') and resource ('any public URL'), and clearly distinguishes the tool from the sibling search tools (search_*, graph_*) by being the only generic URL fetcher. It also states the value proposition (bypasses bot protections, returns clean Markdown), leaving no ambiguity about what the tool does.

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 clearly implies usage for fetching arbitrary public URLs when bot protection is a barrier. It does not explicitly name alternatives or provide when-not-to-use conditions, but the context of a URL-scraping tool among search and intelligence tools makes the usage context clear. No exclusions are stated, but none are obviously needed.

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 behavioral disclosure burden and largely succeeds: it states the data source (AbuseIPDB v2), the exact fields returned, the warning behavior above a 50% threshold, and the authentication dependency on ABUSEIPDB_API_KEY. It does not mention error handling, rate limits, or what happens when the API key is missing, which keeps it from a perfect score.

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 focused sentences that front-load the core purpose, then list the return fields and key behaviors. Every sentence contributes meaning, with no repetition of schema details or filler 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?

Given no output schema, no annotations, and only two parameters, the description adequately covers the tool's function, outputs, authentication mechanism, and a notable behavioral rule. It is missing explicit usage guidance relative to sibling tools and details about the json_output parameter, but these are minor given the tool's limited 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% because json_output has a description but ip does not; the description clarifies that ip should be an IP address, but it does not discuss the json_output parameter at all. The description adds minimal value beyond the schema for ip and no new information for json_output, so it only partially compensates for the schema 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 uses the specific verb 'Check' with the resource 'an IP address against the AbuseIPDB v2 API', and enumerates concrete outputs such as abuse confidence score, total reports, and ISP. This makes the tool's purpose immediately distinguishable from sibling IP-lookup tools like search_ip, search_virustotal, or search_ip2location.

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 implies when to use it—whenever an IP's AbuseIPDB reputation is required—but does not explicitly compare it to alternatives or state when not to use it. Sibling tools like search_virustotal and search_censys are not referenced, so an agent must infer the distinguishing criteria from the API name 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?

With no annotations, the description carries the transparency burden. It discloses the external dependency (HaveIBeenPwned) and the environment-variable auth requirement, but it doesn't say what the default output looks like, whether a plain-text vs JSON result is returned, or how errors/rate limits surface. This is partial but not full disclosure.

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 no filler; the core purpose is front-loaded and the auth prerequisite is appended without clutter. Every clause earns its place.

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

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

For a two-parameter lookup with no output schema and no annotations, the description gives the essential purpose and a key prerequisite, but it omits the return format and error behavior. An agent could call the tool correctly, but would be guessing about what the response contains unless it sets json_output.

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 already has a description, while email has only a type. The description adds meaning by identifying email as the address to check, but doesn't specify format, normalization, or how json_output changes the response. It doesn't fully compensate for the undocumented email parameter.

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

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

States a precise action ('Check if an email appears') and a specific resource ('data breaches via HaveIBeenPwned'), which distinguishes it from sibling tools like search_email. The name 'search_breach' is reinforced rather than merely restated.

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 implies when to use the tool—any time an email's breach status is needed—but it doesn't explicitly name alternatives, exclusions, or the conditions that would route to a sibling tool. The HIBP_API_KEY prerequisite is mentioned, which is helpful operational context.

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 does disclose the CENSYS_API_ID and CENSYS_SECRET env var dependency and what data categories come back, which is useful. However, it does not explicitly state read-only behavior, output format, or 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?

The description is three compact sentences with no filler. It front-loads the main purpose, then gives concrete examples of inputs and outputs, then mentions the required environment variables. 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 tool with no annotations and no output schema, the description is reasonably informative: it covers authentication and result categories. Still, it omits explicit return shape, usage boundaries, and any limitations, leaving an agent with moderate uncertainty when choosing among many reconnaissance siblings.

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 50%; the description compensates for the undocumented target parameter by explaining IP and domain use cases. The json_output parameter is already explained in the schema, so the description adds value to the key parameter but does not fully cover all 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 uses a specific verb and resource ('Search Censys') and then details the exact data returned for IP and domain targets. This clearly separates it from generic sibling tools like search_ip or search_domain by naming the source and the output categories.

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 about when to use this tool over alternatives like search_shodan or search_virustotal. The description implies usefulness for internet-facing infrastructure recon but never states when-not or names a competing 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 no annotations, the description carries the full burden. It discloses that the tool performs live DNS queries without requiring external APIs or credentials, which implies read-only behavior. However, it does not mention potential limitations like rate limiting, caching, or query timeout. The explanation of email security misconfigurations adds useful 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?

Two concise sentences, front-loaded with the primary action and record types, followed by additional valuable information (email security and credentials). No superfluous 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?

Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the purpose, scope, and a key constraint (no credentials). It could mention the response format or potential delays, but overall it provides adequate context for an agent to understand the tool's capabilities.

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 overall context but does not directly explain the 'domain' parameter beyond what is implied. For 'json_output', the schema already provides meaning. The description's mention of DNS enumeration indirectly covers the domain parameter, but it does not add explicit parameter-level detail. Baseline is 3 due to moderate schema coverage combined with some contextual support.

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 clearly states it performs comprehensive DNS record enumeration and lists specific record types (A, AAAA, MX, NS, TXT, CNAME, SOA). It also highlights additional email security checks, making the purpose very specific and distinguishable from sibling tools that deal with 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 indicates that no external API or credentials are required, which is a clear usage guideline. However, it does not explicitly state when to use this tool versus alternatives like 'search_censys' or 'search_shodan', though the context implies it's for DNS enumeration. A slight lack of exclusion criteria prevents a perfect score.

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; description merely states the action without disclosing behavioral traits such as rate limits, result format, or side effects. The mention of sublist3r hints at external dependency but insufficient 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?

Single concise sentence, front-loaded with action, no unnecessary 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, no annotations, and description does not cover result format, error conditions, or scope of enumeration. Leaves significant gaps for an 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?

Schema has 50% coverage (json_output described). Description adds 'using sublist3r' but does not clarify the domain parameter's format or constraints. No value beyond schema for the domain parameter.

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

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

Description clearly states verb 'enumerate', resource 'subdomains of a target domain', and tool 'sublist3r'. Distinct from sibling tools like search_dns or search_breach.

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 tool versus alternatives like search_dns or search_censys. Implicit usage but lacks explicit context or exclusions.

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 disclosure burden and does well: it states the default behavior (up to 5 dorks), the operational cost (each is billable), and the required environment variables. It could add error behavior or result-format details, but the core side effects are 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 description is a single compact sentence with key operational details front-loaded. It says what the tool does, how many runs occur, the cost implication, and the auth dependencies without wasting 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 the tool's low complexity and lack of output schema, the description covers purpose, return fields, default limits, billing impact, and environment prerequisites. The main gap is target semantics, but the overall usage context is strong enough for an agent to call it without critical missing information.

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 documents json_output but leaves target undescribed. The description adds only vague target semantics by saying 'for a target' and does not specify the expected format or examples. Since schema coverage is only 50%, the description does not fully compensate for the undocumented target parameter.

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

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

The description names a precise verb and resource: execute Google dork queries via the Bright Data SERP API and return live structured results. It even specifies the result fields (title, URL, snippet), which clearly separates it from siblings like generate_dorks.

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 functional context: it runs live dork queries and warns about the default limit and billable calls. It does not explicitly say when not to use it or name an alternative tool, but an agent can infer its intended role among the sibling search 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?

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says 'enumerate' without explaining whether the tool is read-only, requires permissions, has rate limits, or potentially sends network requests (holehe is a passive enumeration tool but could be interpreted as active).

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 a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple tool, though additional context could be added without harming conciseness.

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 two parameters and no output schema, the description is incomplete. It does not explain the return format (beyond the json_output flag) or typical response structure (list of accounts, links, or errors). For a simple enumeration tool, more context is needed for correct invocation.

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

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

Schema description coverage is 50%: json_output has a description, but email does not. The description mentions email in context but does not add format or validation details. The missing email description is partially compensated by the tool's name and context, so score is at baseline 3.

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

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

The description clearly states the tool enumerates accounts linked to an email using holehe, with a specific verb and resource. It distinguishes from sibling tools that search by different identifiers (domain, username, IP, etc.), but could be more precise about what 'accounts' means (e.g., social media profiles).

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 tool versus alternatives like search_breach or search_username. There are no explicit when-to-use or when-not-to-use conditions, nor are alternative tools mentioned for comparison.

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 behavioral burden. It discloses the external API dependency, required environment variables, query behavior, and the graph-oriented output shape. It does not cover rate limits, failure modes, or cost details, but the schema already mentions billable queries for max_queries.

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 with no filler. The core purpose is front-loaded, followed by behavior/output details and environment variable requirements. 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 tool with no output schema and no annotations, the description covers the main invocation concerns: target semantics, external API, env var prerequisites, and return shape. It is slightly incomplete only in not addressing alternative tool selection or operational caveats like 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?

The description adds significant meaning to the undocumented 'target' parameter by listing accepted entity types: email, username, domain, phone, or full name. The other parameters are already described in the schema, so the description compensates for the 67% schema coverage without needing to repeat existing parameter docs.

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 ('Collect'), a specific resource ('public search-engine footprint via the Bright Data SERP API'), and a distinctive behavior (entity-type detection and entity-type-aware Google queries). This clearly differentiates it from the specialized siblings like search_email, search_username, and 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?

The description gives clear context by explaining that this tool detects the entity type rather than requiring a pre-selected type, which implies it is appropriate for broad or unknown targets. However, it does not explicitly state when not to use it or point to specialized siblings as 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 exist, so the description carries the full burden. It usefully discloses that no API key is needed and that the return is a text summary plus a raw GeoJSON FeatureCollection, but says nothing about rate limits, result freshness, paging/truncation behavior, or what happens when bbox is omitted.

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

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

Three tight sentences, front-loaded with the core action and data source; each sentence adds distinct information (source, auth, return shape, optional scoping) with no 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 5-parameter read tool with no output schema, the description covers the essentials: what it searches, that no key is needed, and what comes back. Missing only operational details like rate limits and empty-result 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 80% (bbox, timespan, maxpoints all documented inline), so the schema carries most parameter meaning. The description only echoes the optional bbox scope and adds no format or ordering detail beyond what the schema already says.

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

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

States a specific verb ('Search') and a well-defined resource ('worldwide, geolocated news coverage via the GDELT GEO 2.0 API'), plus the scope constraint (bounding box). It is easy to distinguish from the other search_* siblings, which target whois, DNS, breach, IP, 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 notes that no API key is required and that bbox scoping is optional, implying when the tool is usable and how to narrow it, but it never states when to prefer this tool over siblings or what kinds of queries it is suited to. Usage is inferred rather than guided.

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?

Since no annotations are provided, the description carries full burden. It discloses rate limit differences and response variations based on query type. It doesn't explicitly state safety (read-only), but search is inherently non-destructive.

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-load the main purpose and provide essential details without fluff. Every sentence adds distinct value: purpose, behavior details, and rate limit 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?

The description covers main aspects: query types, response content, rate limit. It lacks explicit mention of default output format (likely text vs JSON). Given no output schema, this is a minor gap but overall sufficient for the tool's 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 description coverage is 50% with only json_output described. The description adds meaning for the query parameter by explaining its purpose and behavior logic. This compensates for the undocumented query parameter 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 tool searches GitHub for a username, email, or keyword. It distinguishes from sibling tools by naming the platform and specifying behavior differences for exact vs non-exact 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?

The description provides context on behavior (exact match returns full profile, other queries top 5) and rate limit with GITHUB_TOKEN. It doesn't explicitly state when to use or alternatives among siblings, but the specificity to GitHub implies usage context.

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 should fully disclose behavioral traits. It mentions the data source but does not discuss rate limits, authentication requirements, or whether the operation is read-only.

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 a single, efficient sentence that immediately conveys the tool's purpose. Every word 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?

Given no output schema, the description could hint at the structure of the returned data. It mentions geolocation and ASN but doesn't outline fields, which would help an agent parse results.

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 tool description adds no extra meaning for the 'ip' parameter, leaving its expected format (IPv4/IPv6) unspecified.

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 action (retrieve) and the resource (geolocation and ASN data for an IP address), and distinguishes from sibling tools by specifying the data source (ipinfo.io).

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 is provided on when to use this tool versus alternatives like search_ip2location or search_shodan, nor any context on prerequisites or limitations.

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

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

With no annotations, the description carries the full burden, and it does disclose a third-party dependency, the IP2Location Security Plan, and the IP2LOCATION_API_KEY environment variable. It does not mention whether the operation is read-only, potential rate limits/costs, or what happens when the API key is missing.

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-loaded with the main value proposition and return categories. 'Sponsored integration' is mildly extraneous, but the dependency and env-var note are relevant operational context.

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

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

For a simple two-parameter lookup, the description gives enough high-level return content and dependency context to attempt a call. It is incomplete in not explaining response format, error behavior, or how json_output affects the result, especially with no output schema or annotations to fill those gaps.

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 only 50%, and the description adds no explicit meaning for the required ip parameter beyond the tool name/context, nor does it mention json_output. The schema documents json_output, but the description does not compensate for the undocumented ip parameter.

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

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

The description names a specific verb ('Returns'), a resource (IP intelligence), and concrete data categories (geolocation, ISP, ASN, VPN/proxy/Tor/datacenter detection), which distinguishes it from a plain IP lookup. It does not explicitly name sibling alternatives like search_ip, so it stops short of full 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?

Usage context is implied by 'Enhanced IP intelligence' and the detection features: an agent can infer this is for richer IP enrichment. However, there is no explicit when-to-use or when-not-to-use guidance relative to siblings such as search_ip, search_shodan, 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 carries full burden but only mentions the source (psbdmp.ws), not rate limits, auth, or result behavior; minimal disclosure.

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?

Single sentence, no fluff, but slightly under-specified; appropriate length but could be more 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?

Does not explain output, json_output effect, or differentiate usage from siblings; incomplete for a simple tool with 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 50%, and description adds no extra meaning beyond the schema; does not explain query format or json_output behavior 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?

The description clearly states it searches Pastebin dumps for an email or username via psbdmp.ws, specifying the verb, resource, and source, distinguishing it from siblings like search_email and search_username.

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 tool versus alternatives like search_email or search_username; lacks context for usage decisions.

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 fully carries the burden. It mentions 'gather carrier and geolocation data' but does not disclose side effects, authentication needs, rate limits, or failure modes. Minimal behavioral insight.

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 redundancy. The purpose is front-loaded, and the format instruction is directly useful. Every word 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?

No output schema or annotations exist. The description lacks details on return format (beyond 'geolocation data'), error handling, or limitations. Not sufficiently complete for a data-gathering tool with two parameters.

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 the essential E.164 format requirement for the 'phone' parameter, which is not in the schema. The json_output parameter's schema description is clear but not enhanced. With 50% schema coverage, the description compensates well.

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 gathers carrier and geolocation data for a phone number using phoneinfoga, and the E.164 format requirement. It is specific to phone numbers, distinguishing 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 instructs using E.164 format, but provides no guidance on when to use this tool vs alternatives (e.g., for email or domain searches). No when-not or context exclusions 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?

No annotations exist, so description carries the burden. It discloses use of SHODAN_API_KEY env var (auth requirement), and states the dual behavior (IP vs keyword). It adds value by explaining output scope (open ports, org, CVEs) but doesn't mention rate limits, return format, or error behavior. Given zero annotations, this is solid but not exhaustive.

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

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

Three sentences, no filler. First sentence states purpose, second gives parameter semantics, third names auth dependency. Every sentence carries weight.

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, this is nearly complete. It covers purpose, input semantics, and auth. Missing: what the return value looks like (unstructured text vs JSON default), rate limits, or error handling. Given the tool is a Shodan search with no schema complexity, it's 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 description explains the 'query' parameter's semantics in detail: IP → host lookup, other string → keyword search. This compensates for the schema's lack of description on 'query'. It also mentions 'json_output' indirectly by saying 'Return result as structured JSON' in the schema. The description goes beyond schema 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?

Description clearly states 'Query Shodan for host intelligence or banner search', provides a concrete mechanism (IP address → host lookup vs keyword search), and lists what the host lookup yields (open ports, org, CVEs). It also distinguishes from sibling search_* tools by naming the specific service (Shodan). This is a specific verb+resource with clear differentiation from 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?

The description provides explicit usage guidance: IP address → host lookup, any other string → keyword/service search. This tells the agent when the tool is relevant (any Shodan query) and is clear on input semantics. However, it doesn't explicitly mention when not to use it vs other sibling tools like search_censys or search_ip, so it lacks explicit exclusions.

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 mentions 'using sherlock' but does not disclose behavioral traits such as network usage, rate limits, accuracy, speed, or any side effects. The verb 'enumerate' implies an interactive process, but details are missing.

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 a single concise sentence that immediately states the core purpose. It is front-loaded and contains no unnecessary 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 tool with no output schema and only two parameters, the description is too sparse. It does not explain what the output looks like, how to interpret results, or any operational details (e.g., network requirements). Given sibling tools, more context would help differentiate use cases.

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 50% (only json_output has a description). The description does not add meaning for the username parameter, and does not clarify the format or constraints beyond what the schema provides. This is inadequate given the low 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 the tool enumerates platforms where a username is registered using sherlock. It specifies a specific verb (enumerate) and resource (platforms for a username), and it distinguishes from sibling tools that focus on emails, domains, IPs, 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?

No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or context about prerequisites. The description simply states what it does without helping the agent decide when it is appropriate.

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 burden. It discloses the key behavioral trait: auto-detection of input type, and the dependency on VIRUSTOTAL_API_KEY env var. However, it does not disclose rate limits, whether the tool can fail on unknown types, or what the default output format is when json_output is false. This is adequate but not rich.

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 no filler. The core function is front-loaded, the auto-detection behavior is stated, and the auth dependency is included. 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 tool with 2 params and no output schema, the description covers the main purpose and the key behavioral trait (auto-detection) and auth. However, it lacks details on output format when json_output is false, potential error conditions (e.g., invalid target), and rate limits. Given the tool's moderate complexity and the absence of annotations, a bit more context would be needed for fully confident 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 50%: the 'target' parameter has no description, while 'json_output' has a basic one. The description adds meaning by explaining that 'target' can be an IP, domain, URL, or file hash and that input type is auto-detected. This compensates partially for the missing schema description, but it doesn't specify formats (e.g., hash type, URL encoding) or the exact effect of json_output beyond 'structured JSON'.

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 ('Check') and resource ('IP, domain, URL, or file hash against VirusTotal's 70+ antivirus engines and threat intelligence'). It clearly distinguishes itself from sibling tools like search_ip, search_domain, and search_dns by covering multiple input types and naming VirusTotal specifically. The auto-detection note further clarifies its scope.

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 implies when to use this tool: when you need to check any of the listed indicator types against VirusTotal. It does not explicitly state when not to use it or name alternatives, but the sibling list and the multi-type coverage make the context clear. A small gap is the lack of explicit exclusion guidance (e.g., 'for phone numbers use search_phone').

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 present, so the description must disclose behavioral traits. It only describes the action without mentioning rate limits, data availability, read-only nature, or potential redactions (e.g., GDPR). This is insufficient for informed invocation.

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 a single, efficient sentence that communicates the core purpose without redundancy. It is appropriately sized, though it could benefit from additional context without becoming 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 absence of annotations and output schema, the description is too minimal. It fails to explain what data is returned (e.g., registrar, dates, contacts) or any constraints like domain format. This leaves the agent with insufficient information to handle results properly.

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 50%, but the tool description adds no extra meaning to either parameter. The 'domain' parameter lacks explanation, and 'json_output' is only partially covered by the schema. The description does not compensate for low 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 explicitly states the verb 'retrieve' and the resource 'WHOIS registration data' for a domain, which clearly distinguishes it from sibling tools like search_dns or search_domain. It leaves no ambiguity about what the tool does.

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 is provided on when to use this tool versus alternatives like search_domain. There is no mention of prerequisites or context for appropriate use, leaving the agent without decision support.

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