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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that it queries crt.sh and returns specific data types, which is useful. It does not disclose potential rate limits, pagination, or response formatting, but given the annotation coverage, this is acceptable.

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, tightly worded sentence that leads with the most important outputs (hostnames and email addresses) and includes the source (crt.sh) without redundancy. Every word contributes to understanding the tool's 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 simple read-only search tool with no output schema, the description tells the agent what to expect (hostnames and emails) and the source. It doesn't describe the optional include_expired parameter, but that is fully covered in the schema. The description is effectively complete for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so both parameters ('domain' and 'include_expired') are well-documented in the schema. The description adds no new parameter-specific semantics beyond mentioning 'for a domain', which aligns with the required parameter. Baseline 3 is appropriate as the schema carries the meaning.

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 a specific action (searching certificate transparency logs) and resource (TLS certificates for a domain), and specifies the exact outputs: host names and email addresses. It also differentiates from sibling subdomain tools by emphasizing 'often unlisted subdomains' and the crt.sh source, helping an agent distinguish it from subfinder_subdomain_search.

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: an agent would use this tool when it needs hostnames or email addresses from certificate transparency logs. However, there is no explicit guidance on when to prefer this over sibling tools like subfinder_subdomain_search or theharvester_domain_search, nor any exclusions or when-not-to-use conditions.

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

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

The description adds useful behavioral context beyond the annotations by stating that it queries public DNS-over-HTTPS resolvers and listing the default record types. This is consistent with the read-only, idempotent, open-world annotations and helps the agent understand the external nature of the lookup.

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 short sentences with no filler. The main operation is front-loaded, and the default behavior plus resolver detail are included without unnecessary elaboration.

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 tool with strong annotations, the description covers the essential behavior and parameter semantics. There is no output schema or mention of result formatting, but the return concept of 'DNS records' is clear enough for an agent to proceed.

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 documents both parameters fully, but the description adds value by specifying the default record types fetched when no types array is provided and confirming that an IP triggers a reverse lookup. This goes beyond the schema's basic 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 identifies the resource (DNS records) and the dual mode of operation: forward lookup for a domain or reverse PTR lookup for an IP. It does not explicitly distinguish itself from sibling tools like dnsrecon_domain_scan, but the purpose is specific and understandable.

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

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

There is no guidance on when to choose this tool over alternatives such as dnsrecon_domain_scan, whois_lookup, or subfinder_subdomain_search. The description implies a simple direct DNS lookup, but it does not state when not to use it or which sibling covers broader reconnaissance.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some behavioral context by mentioning zone transfer attempts and DNSSEC zone walking, but much of this is already reflected in the scan_type enum descriptions, and no additional context such as network intensity or external service usage is disclosed.

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

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

The entire description is one dense, front-loaded sentence that packs the tool's purpose, target resource, and capability set without filler. Every clause contributes useful information, and the dependency on scan_type is clearly signaled.

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 parameters, one required, and rich enum documentation, the description is largely sufficient: it identifies the target, the operation family, and the scan-dependent output types. It lacks explicit return-value/pagination details, but no output schema exists and the core request shape is fully inferable from the schema and 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?

Schema description coverage is 100%, with both domain and scan_type already documented, so the baseline is 3. The description mentions scan_type and lists scan-dependent outputs, but it does not add semantic detail beyond what the schema enum descriptions already provide.

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 names the action ('DNS reconnaissance') and the resource ('a domain') and enumerates the specific record types and operations covered, such as SOA, NS, MX, zone transfer attempts, and certificate-log names. It does not explicitly distinguish itself from the sibling dns_lookup tool, but the broader scope is evident from the detailed capability list.

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

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

The description provides no guidance about when to choose this tool over alternatives such as dns_lookup, subfinder_subdomain_search, or whois_lookup. It only notes that execution depends on scan_type, which is a parameter detail rather than a selection criterion or exclusion.

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

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

Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable behavioral details beyond those: it generates multiple categories of lookalikes (typos, homoglyphs, other TLDs), checks registration status, and returns specific DNS record types (A, MX, NS). This gives the agent a solid expectation of the tool's behavior without repeating the annotations.

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

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

The description is a single sentence that packs in the action, scope, output, and use case with no filler or redundancy. It is front-loaded with the core functionality and remains easy to parse for an agent scanning multiple tool definitions.

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 (2 params, 1 required, schema fully covering them, no output schema), the description is largely complete: it states the input, the transformations, the filtering option behavior implied by 'registered', and the DNS records returned. It does not describe output format or pagination, but that is not critical for a simple read-only generator tool.

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

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

Schema description coverage is 100%, so the schema already fully documents both the 'domain' and 'registered_only' parameters. The description does not add parameter-level details beyond what the schema provides, but it does not need to. Baseline 3 is appropriate.

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

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

Description uses a specific verb ('Generate'), names the resource ('lookalike domains'), and specifies the exact technique (typos, homoglyphs, other TLDs) and output (A, MX, NS records). This clearly distinguishes it from sibling tools like subfinder_subdomain_search or dnsrecon_domain_scan, which focus on subdomains or DNS enumeration rather than typo-squatting detection.

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 a use case: 'Useful to spot phishing domains.' This gives the agent clear context for when to invoke this tool over alternatives. It does not explicitly name sibling tools or state when not to use it, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it invokes ExifTool and reads local metadata, but it does not disclose potential behavior such as requiring ExifTool to be installed or failing on unsupported file types. This is acceptable given the annotations, but not richly 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 focused sentence that front-loads the action and resource, then adds concrete examples of the metadata categories. Every phrase earns its place with no repetition of schema fields or annotation values.

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

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

For a simple one-parameter, read-only tool with no output schema, the description gives enough context for an agent to invoke it correctly and understand what it will retrieve. A small gap is that it does not mention output format or failure modes, but these are not critical given the tool's simplicity and the safe-read annotations.

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

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

Schema coverage is 100% and the only parameter, file_path, is already described as an absolute path to the photo, video, or document. The description reinforces this by mentioning local files but adds little semantic detail beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Read'), a clear resource ('metadata of a local photo, video or document'), and the method ('with ExifTool'). It also enumerates concrete metadata categories (GPS, camera, author, software, timestamps), making the tool's purpose immediately recognizable and distinct from the OSINT 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 word 'local' clearly establishes that this tool is for on-disk files rather than online investigations, which implicitly differentiates it from the sibling tools (email, username, domain searches). However, it does not explicitly state when not to use it or name an alternative, so it stops short of 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?

Annotations already declare the operation read-only, idempotent, and non-destructive, so the description's burden is lower. It adds meaningful behavioral context by requiring a one-time `ghunt login`, which an agent must know before invocation, and it briefly lists what data will be returned. It does not discuss failure modes or rate limits, but those are secondary given the annotation coverage.

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 with zero filler: the action and accepted identifier forms are front-loaded, the returned data fields are listed compactly, and the login prerequisite is stated separately. 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 single-parameter read-only lookup with no output schema, the description supplies the input forms, the likely result contents, and the critical login prerequisite. It could be more explicit about error cases or unrecognized accounts, but nothing essential to selecting and invoking the tool is missing.

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

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

The single `identifier` parameter is fully described in the schema ('Google account email address, or numeric Gaia ID'), so the description adds no genuinely new syntax or formatting detail. Reinforcing the two accepted input forms is useful but does not exceed the baseline for 100% schema description 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 opens with a specific verb ('Look up') and resource ('Google account'), then names the two accepted identifier forms (email address or Gaia ID) and enumerates concrete data fields (name, profile picture, Gaia ID, Maps reviews, calendar). This makes the tool's scope unambiguous and clearly distinguishes it from the sibling username/email OSINT tools.

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

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

The description gives clear context: this tool is for Google-account enumeration keyed by email or Gaia ID, and it flags the `ghunt login` prerequisite. It does not explicitly name alternatives or state when not to use it, but the platform-specific scope is enough to steer an agent toward this tool over the siblings.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat those safety traits. The description adds useful scope context ('about 120 websites'), but does not mention network behavior, rate limits, or possible caveats about coverage; with strong annotations this is acceptable but not exceptional.

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 focused sentence with no filler. It front-loads the core action and scope, and every word contributes to understanding the tool's 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 read-only lookup with one required parameter and rich annotations, this is mostly complete. However, there is no output schema and the description does not indicate what the result report looks like or how the timeout/only_used options affect output, leaving some ambiguity 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 description coverage is 100%, so the input schema already documents all three parameters. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Check') and a clear resource: the set of about 120 websites where an email address may be registered. It clearly identifies this as an email-based registration lookup, which distinguishes it from the sibling username-search tools, though it does not explicitly name a sibling.

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

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

The intended use is implied by the wording 'Check which of about 120 websites have an account registered to an email address,' so an agent can infer when to call it. However, there is no explicit statement of when not to use it or which sibling tool to prefer for similar lookups.

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

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

Annotations already declare the tool read-only, open-world, idempotent, and non-destructive, so the safety burden is largely covered. The description adds useful context by mentioning it extracts profile data and filters false positives, but it does not disclose rate limits, network behavior, or output size.

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 focused sentences with no filler. The core action and scope are front-loaded, and the output behavior is stated efficiently.

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 gives a reasonable high-level view of purpose, scope, and output. However, it lacks guidance on choosing it over sherlock_username_search and doesn't fully describe the expected return format, so it isn't fully self-sufficient 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 coverage is 100%, so the baseline is 3. The description adds a small amount of extra meaning, like '3000+' sites with all_sites, but the parameters are already well documented in the schema and the description does not add essential semantic detail beyond that.

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 action ('Search a username') and resource (Maigret), with clear scope details ('500 most popular sites by default, 3000+ with all_sites'). It also says what the tool extracts and that it filters false positives, but it does not differentiate it from the sibling sherlock_username_search, which is also username-focused.

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

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

There is no explicit guidance on when to choose this tool over sherlock_username_search or when not to use it. The coverage details imply broad username enumeration, but the description doesn't provide selection criteria, exclusions, or alternative routing.

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

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

Annotations already communicate safety (readOnly, idempotent, non-destructive). The description adds behavioral context by stating the tool reports status and installation instructions rather than performing installations, which clarifies its non-mutating scope. It could mention response format, but the core behavior is transparent enough.

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 fluff. The key information—what the tool reports and when to use it—is front-loaded and 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 zero-parameter status tool with annotations covering safety, the description is complete: it identifies the tool's purpose, the information it provides, and the precise invocation trigger. No output schema is required because the tool's outputs are summarized adequately by the 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 tool has zero parameters, so the baseline is 4; there is no parameter burden for the description to address. The description still clarifies what the tool covers, which is sufficient given the empty 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 this tool reports which OSINT tools the server can run on this machine and how to install missing ones. It is distinct from the sibling tools, which perform specific OSINT searches rather than report on toolbox availability.

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 explicitly tells the agent when to call it: 'Call it when a tool you need is not available.' This direct trigger condition is sufficient for a meta-status tool and no alternative is needed since siblings are the tools being checked, not competitors.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds meaningful context: carrier/line type requires an API key and the scan involves search engine queries, implying external web activity. This goes beyond the annotations without contradicting them.

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 stating the action and then efficiently enumerating the result categories. There is no filler or redundant information, and every element 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?

With one parameter, no output schema, and annotations covering safety, the description provides a clear outline of the returned information domains. It lacks explicit response structure or error/edge-case details, but the tool's low complexity makes this a minor gap.

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

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

The input schema already fully documents the single 'number' parameter with format (E.164) and example (100% coverage). The description does not add any additional parameter-level detail, so the baseline 3 applies.

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

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

The description uses the specific verb 'scan', names the resource (a phone number), and lists concrete outputs: country, number formats, carrier/line type (with an API key), and search engine queries. This clearly differentiates it from sibling tools targeting emails, usernames, domains, or 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 intended use case is implied by the tool name and description — scanning phone numbers — but it never explicitly states when to choose this tool over alternatives or when not to use it. Sibling tools are obviously for other entity types, so the context is clear but not directly articulated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds the scope (400+ sites) and output format (profile URLs), but doesn't disclose potential rate-limiting, network variability, or that results depend on site availability. With annotations covering the safety profile, a 3 is fair.

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

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

Two sentences with zero waste. The core function is front-loaded, and the output is described immediately. 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?

For a read-only, idempotent tool with 100% schema coverage and no output schema, the description is complete enough. It explains what the tool does, what it returns, and the scope. It doesn't mention edge cases like network failures or site availability, but those are minor given the annotations and 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 description coverage is 100%, so the schema already documents all four parameters. The description adds the context that the tool checks 400+ sites and returns profile URLs, but doesn't add meaning beyond what the schema provides for each parameter. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description states a specific verb ('Find accounts'), a clear resource (username across 400+ social networks), and the output (sites where the username exists with profile URLs). It clearly distinguishes itself from sibling tools like holehe_email_search (email-based) and theharvester_domain_search (domain-based).

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 have a username and want to find associated accounts across many platforms. It doesn't explicitly name alternatives or exclusions, but the sibling list and the description's focus on username-based search make the use case clear. A 4 is appropriate because it provides clear context without explicit when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it detects target type automatically, groups results by event type, and discloses time expectations (minutes vs 30+ minutes). This goes beyond what annotations provide.

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 with no waste. The core action is front-loaded, and the time guidance is efficiently packed into the final sentence.

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

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

For a tool with 2 params, 100% schema coverage, and safety annotations, the description is nearly complete. It explains what happens during the scan, how results are organized, and time expectations. It doesn't mention output format, but with no output schema and the annotations covering safety, this is a minor gap.

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

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

Schema coverage is 100%, so the schema already documents both parameters thoroughly. The description adds the time-duration context for use_case values, which is useful, but doesn't add meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate.

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

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

The description clearly states the tool runs a SpiderFoot scan, detects target type, and runs matching modules. It distinguishes itself from sibling tools by focusing on SpiderFoot's multi-type target scanning rather than a single search type.

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 the use_case options and their time implications, giving an agent context on when to choose 'passive' vs 'all'. It doesn't explicitly name sibling alternatives, but the target-type flexibility and scan duration guidance provide clear 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?

Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive). The description adds useful behavioral context by stating that results come from passive sources and that the return includes reporting sources, but it does not disclose additional traits like rate limits or the default fast source set beyond what the schema already mentions.

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

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

Two compact sentences with no filler. The core action and scope come first, and the return behavior is stated in the second sentence. 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 simple read-only discovery tool with annotated safety and fully documented parameters, the description is complete enough. It explains the return value even though there is no output schema. It could add a note about when to prefer sibling tools, but that gap is minor.

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

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

Schema description coverage is 100%, so the parameters domain, timeout, and all_sources are already fully documented. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Find subdomains of a domain in passive sources'. It also scopes the tool explicitly to passive discovery (certificate logs, DNS datasets) and names subfinder, making its role distinct from active or broad sibling tools like dnsrecon_domain_scan.

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 passive-source wording gives clear context for when to use this tool: passive subdomain discovery. It does not explicitly state when not to use it or name an alternative sibling, but the intended use is implied strongly 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds that data comes from 'public sources', hinting at external queries, but does not disclose potential rate limits, network latencies, or result unpredictability beyond the openWorldHint. 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?

The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and output. There is no redundant filler or repetition of schema details.

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

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

For a read-only recon tool with rich annotations and fully documented parameters, the description is nearly complete. It covers what data is collected and from where. It does not describe the output structure or potential empty-result behavior, but the annotations and schema already carry much of the burden, and the listed data types imply the return content.

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

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

Schema description coverage is 100%, so every parameter (domain, limit, sources) is already documented in the schema. The tool description adds context about domain or company name input and the variety of output data, but it does not add significant parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific action ('Collect') and a clear resource ('email addresses, subdomains, hosts, IP addresses and URLs for a domain or company name'). It also names the data source ('public sources') and the underlying tool (theHarvester). This clearly distinguishes it from sibling tools that search by username, email, phone, or scan infrastructure.

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 makes it clear the tool is for domain or company name reconnaissance, which implies when to use it relative to siblings like sherlock_username_search or holehe_email_search. It does not explicitly mention when not to use it or name an alternative, but the context and resource scope provide clear usage guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral detail beyond annotations by specifying ordering ('newest first') and that links to view snapshots are included, but it does not add much else about response behavior 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-formed sentence with no fluff, filler, or repetition. Key information is front-loaded: what the tool returns, the data source, ordering, and the link behavior.

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

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

For a read-only list tool with fully documented parameters and rich annotations, the description conveys the essential return content (archived snapshots, newest first, links to view). There is no output schema, but the description gives a minimally sufficient picture for an agent to interpret the response, even if field-level details are not specified.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the input schema, including url semantics, defaults, and the match enum. The description adds no parameter-level meaning beyond what the schema provides, which matches the baseline expectation.

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

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

The description clearly identifies the resource (archived snapshots of a URL/site/domain in the Wayback Machine) and the output (newest first, with links to view each one). It is clear and distinguishable from the OSINT sibling tools, though it lacks an explicit verb like 'list' or 'retrieve', so it stops just short of the top tier.

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 the use case: when a user needs historical archived versions of a web resource from the Internet Archive. However, it does not mention when not to use it or name alternative sibling tools, so usage guidance is only implicitly conveyed.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds value by disclosing that it uses RDAP or WHOIS depending on registry support, and that data may be limited to public information ('where public'). This contextualizes the tool's behavior beyond the annotations.

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

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

The description is two sentences, front-loaded with the data scope and fields, followed by the protocol note. Every word earns its place; there is no redundancy or fluff.

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

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

For a single-parameter, read-only lookup tool with no output schema, the description covers what the tool does, what data it returns, and the protocol nuance. It sufficiently equips an agent to decide when to invoke it and what to expect.

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 fully documents the query parameter with format examples (domain, IP, CIDR, AS number). The description repeats these same resource types without adding new semantic detail, so it provides borderline marginal value over the schema. Baseline 3 is appropriate given 100% 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?

The description clearly identifies the tool as returning registration data for domains, IPs, networks, or AS numbers, with specific data fields (registrar, dates, name servers, holder, contacts). This is distinct from sibling tools like DNS lookup or subdomain search, so an agent can easily differentiate it.

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 registration data is needed for the listed resource types) but does not explicitly mention alternatives or exclusions. It provides clear context for the tool's purpose, though it stops short of naming sibling tools to avoid.

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