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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Check' implies a read-only operation, it doesn't specify what 'configured and available' means in practice, whether there are rate limits, authentication requirements, or what happens if APIs are unavailable. The description lacks crucial operational context.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a zero-parameter status-checking tool and front-loads the essential information.

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

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

Given the tool's simplicity (0 parameters, has output schema), the description is minimally adequate but lacks important context. The output schema will document return values, but the description should better explain what 'configured and available' means and how this tool relates to the many OSINT query 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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema fully documents the empty input structure.

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

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

The description clearly states the tool's purpose with a specific verb ('Check') and resource ('OSINT APIs'), specifying what it does (checking configuration and availability). However, it doesn't explicitly differentiate from its many siblings, which all perform various OSINT operations rather than system status checks.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or relationships to the 20+ sibling tools that perform actual OSINT queries rather than system checks.

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 behavioral disclosure. It mentions the data source ('Have I Been Pwned') but lacks details on rate limits, authentication needs, privacy implications, or response format. For a tool querying external breach data, this omission leaves critical behavioral traits unspecified, though it doesn't contradict any 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 highly concise and well-structured: a clear purpose statement followed by a brief parameter explanation. Every sentence earns its place without redundancy, and the information is front-loaded for quick comprehension. No extraneous details are included.

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

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

Given the tool's moderate complexity (external API call), lack of annotations, and presence of an output schema, the description is minimally adequate. It covers the core purpose and parameter meaning but misses behavioral details like rate limits or error handling. The output schema likely handles return values, so completeness is borderline acceptable but not robust.

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 meaningful context for the single parameter: 'Email to check' clarifies that the 'email' input should be an email address to query. With 0% schema description coverage and only one parameter, this adequately compensates by providing essential semantics beyond the bare schema, though it could specify format constraints (e.g., valid email syntax).

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

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

The description clearly states the tool's purpose: 'Check if email has been in data breaches (Have I Been Pwned).' It specifies the verb ('Check'), resource ('email'), and data source ('Have I Been Pwned'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'osint_email_verify' or 'osint_email_search', which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools focused on email (e.g., 'osint_email_verify', 'osint_email_search'), there is no indication of specific use cases, prerequisites, or exclusions. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what data is retrieved but doesn't mention authentication requirements, rate limits, response format, error conditions, or whether this is a read-only operation. The description is functional but lacks important operational context.

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

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

The description is appropriately concise with two sentences that directly state the purpose and parameter. The structure is front-loaded with the main functionality, though the Args section could be integrated more smoothly. There's no wasted language.

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

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

Given the tool has an output schema (which handles return values) and only one parameter, the description is minimally complete. However, as an OSINT tool with no annotations, it should ideally mention authentication needs, rate limits, or data freshness. The description covers the basics but leaves important operational context unspecified.

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 minimal parameter semantics beyond the schema. It explains that 'ip' is an 'IP address to look up,' which provides basic context, but with 0% schema description coverage and only one parameter, this is adequate but not comprehensive. The baseline for a single parameter with low schema coverage would be higher if more detail were provided.

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

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

The description clearly states the tool's purpose: 'Get Censys data for an IP address' with specific resources listed (services, ports, certificates, ASN). It distinguishes from sibling tools like 'osint_censys_search' by focusing on host/IP lookup rather than general search, though it doesn't explicitly mention this distinction.

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. While the description implies it's for IP address lookups, it doesn't mention when to choose this over similar tools like 'osint_shodan_host' or 'osint_censys_search', nor does it provide any context about 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 provided, the description carries the full burden of behavioral disclosure. It mentions 'Search' and a 'limit' parameter, implying read-only behavior, but lacks details on permissions, rate limits, error handling, or what the search returns (e.g., format, pagination). This is insufficient for a tool with potential complexity in OSINT contexts.

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 well-structured and concise: a clear purpose sentence followed by bullet-point-like 'Args' with brief explanations. Every sentence adds value without redundancy, making it easy to scan and understand 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?

Given 2 parameters with 0% schema coverage and an output schema present, the description partially compensates by explaining parameters but lacks behavioral context (e.g., authentication, errors). The output schema may cover return values, but for an OSINT search tool, more guidance on usage and limitations would improve completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'query' is explained as 'Censys query language search,' and 'limit' as 'Max results (up to 100).' This clarifies usage beyond the schema's basic types, though it could detail query syntax or default behavior more.

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

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

The description clearly states the tool's purpose: 'Search Censys for hosts matching a query (e.g., certificates, services).' It specifies the verb ('Search'), resource ('Censys'), and scope ('hosts'), but does not explicitly differentiate it from sibling tools like 'osint_censys_host' or 'osint_query' beyond the Censys focus.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'Censys' and examples like 'certificates, services,' but does not specify scenarios, prerequisites, or exclusions compared to siblings such as 'osint_censys_host' or 'osint_shodan_host' for similar OSINT tasks.

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 behavioral disclosure. It mentions the data source ('Apollo.io') and enrichment fields, but fails to describe critical behaviors such as rate limits, authentication requirements, error handling, or response format. For a tool with no annotation coverage, this is a significant gap in transparency.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a clear 'Args' section. It is appropriately sized with no redundant information, though it could be slightly more structured (e.g., bullet points for enrichment fields). Every sentence adds value, earning a high score for efficiency.

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

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

Given the tool has an output schema (which handles return values), no annotations, and a simple input schema with one parameter, the description is minimally adequate. It covers the purpose and parameter semantics but lacks usage guidelines and behavioral details. For a data enrichment tool with no annotations, it should do more to be 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?

The description includes an 'Args' section that explains the 'domain' parameter as 'Company website domain,' adding semantic meaning beyond the input schema, which has 0% description coverage. Since there is only one parameter, the description effectively compensates for the schema's lack of documentation, though it could provide more detail (e.g., format examples).

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

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

The description clearly states the tool's purpose: 'Enrich company data using Apollo.io - size, industry, tech stack.' It specifies the verb ('enrich'), resource ('company data'), and source ('Apollo.io'), with concrete examples of enrichment fields. However, it does not explicitly differentiate from sibling tools like 'osint_company_people' or 'osint_company_research', which prevents a score of 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It lacks context on prerequisites, exclusions, or comparisons to sibling tools (e.g., 'osint_company_people' for personnel data or 'osint_company_research' for broader research). This leaves the agent without direction for tool selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data source ('Apollo.io') but doesn't describe key behaviors such as rate limits, authentication requirements, pagination, error handling, or what the output looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding how it operates.

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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a concise parameter list. There's no wasted text, and the structure is easy to parse. It could be slightly improved by integrating parameter explanations more seamlessly, but overall it's efficient.

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

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

Given that there's an output schema (which covers return values), no annotations, and 0% schema description coverage, the description is moderately complete. It explains the purpose and parameters but lacks behavioral context and usage guidelines. For a tool with four parameters and no annotations, it should do more to compensate, but the output schema helps mitigate some 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 description coverage is 0%, so the description must compensate. It lists and briefly explains all four parameters ('organization', 'domain', 'titles', 'limit'), adding meaning beyond the bare schema. However, it doesn't provide details on parameter interactions (e.g., if both 'organization' and 'domain' are required), formats, or constraints, leaving some ambiguity.

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

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

The description clearly states the tool's purpose: 'Find people at a company using Apollo.io.' It specifies the verb ('Find'), resource ('people at a company'), and data source ('Apollo.io'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'osint_person_enrich' or 'osint_linkedin_find', which might have overlapping functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or comparisons to sibling tools like 'osint_company_enrich' or 'osint_person_research'. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'AI-powered' and 'using Perplexity,' hinting at external API usage and potential rate limits or costs, but doesn't specify authentication needs, response format, error handling, or whether it's read-only. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational traits.

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

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

The description is front-loaded with the core purpose in one sentence, followed by a clear 'Args:' section listing parameters. It avoids redundancy and wastes no words, though the parameter explanations are overly brief. The structure is efficient, but could benefit from slightly more detail in the args to enhance clarity without sacrificing 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 no annotations, 0% schema coverage, and an output schema present (which handles return values), the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral details like rate limits or error cases. For a research tool with external dependencies, more context on usage constraints would improve completeness, though the output schema mitigates some 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 description coverage is 0%, so the description must compensate. It lists 'company' and 'domain' parameters with brief labels but no details on format, constraints, or interaction (e.g., if domain is optional for disambiguation). This adds minimal meaning beyond the schema's type definitions, partially addressing the coverage gap but not fully explaining usage nuances.

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

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

The description clearly states the tool performs 'AI-powered company research using Perplexity,' which specifies the verb (research), resource (company), and method (Perplexity). It distinguishes from siblings like 'osint_company_enrich' or 'osint_company_people' by focusing on general research rather than enrichment or people-specific data. However, it doesn't explicitly contrast with 'osint_query' or 'osint_person_research,' leaving some ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like initial company discovery, competitive analysis, or when to prefer it over siblings such as 'osint_company_enrich' for detailed data or 'osint_query' for broader searches. The lack of context makes it unclear how this tool fits into the OSINT workflow.

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 behavioral disclosure. It states the action ('Perform DNS lookups') but lacks details on permissions, rate limits, or response behavior. For a tool with no annotations, this is a significant gap, as users need to know if it's read-only, has constraints, or what the output entails beyond the existence of an output schema.

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

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

The description is concise and well-structured, with a clear purpose statement followed by an 'Args' section. It avoids unnecessary words and is front-loaded with the main action. However, the 'Args' section could be integrated more smoothly, and it lacks additional context that might be useful.

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 (1 parameter) and the presence of an output schema, the description is somewhat complete. It covers the basic action and parameter, but with no annotations and missing usage guidelines, it falls short. The output schema means return values don't need explanation, but behavioral aspects like rate limits or error handling are omitted.

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 minimal semantics beyond the input schema. It explains that 'domain' is the 'Domain to look up', which clarifies the parameter's purpose. However, with 0% schema description coverage and only one parameter, this is adequate but not comprehensive. The baseline is 3 since the schema handles the structure, but the description doesn't add format details or examples.

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

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

The description clearly states the tool's purpose: 'Perform DNS lookups - A, MX, NS, TXT records.' This specifies the verb ('Perform DNS lookups') and resource (DNS records), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'osint_shodan_domain' or 'osint_whois', which may also involve domain-related 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where DNS lookups are appropriate, such as for security analysis or network troubleshooting. Without this, users might struggle to choose between this and similar tools like 'osint_shodan_domain' or 'osint_whois'.

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 for behavioral disclosure. While 'Find someone's work email address' implies a lookup/query operation, the description doesn't disclose important behavioral traits: success rates, data sources, privacy/ethical considerations, rate limits, authentication requirements, or what happens when no email is found. For an OSINT tool with no annotation coverage, this represents significant gaps in behavioral transparency.

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 perfectly structured and concise. It leads with the core purpose in a single clear sentence, then provides parameter explanations in a clean Args section. Every sentence earns its place - the first establishes purpose, the three parameter lines provide essential context. No wasted words or redundant information.

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

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

Given that an output schema exists (which should describe the return format), the description doesn't need to explain return values. However, for a 3-parameter OSINT tool with no annotations, the description should do more to explain behavioral context - success conditions, limitations, data sources. The parameter explanations are good, but the overall context for how and when this tool works is incomplete.

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

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

With 0% schema description coverage, the description must compensate - and it does by clearly explaining all three parameters in the Args section. Each parameter (domain, first_name, last_name) gets a brief but meaningful explanation that adds semantic context beyond the bare schema. The description successfully clarifies that 'domain' means 'Company domain' and that the names refer to the person whose email is being sought.

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

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

The description clearly states the tool's purpose: 'Find someone's work email address' - a specific verb ('Find') and resource ('work email address'). It distinguishes itself from siblings like 'osint_email_search' and 'osint_email_verify' by focusing on finding a specific person's work email rather than general email searching or verification. However, it doesn't explicitly contrast with these siblings in the description text itself.

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

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

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools in the OSINT domain (like osint_email_search, osint_person_enrich, osint_linkedin_find), there's no indication of when this specific email finder is appropriate versus other tools that might find email addresses through different methods or with different inputs.

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 behavioral disclosure. It mentions the data source (Hunter.io) and the action (finding email addresses), but lacks details on rate limits, authentication needs, data freshness, privacy implications, or error handling. For a tool with external API integration and no annotations, this is a significant gap in transparency.

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 appropriately concise and front-loaded, with the core purpose stated first followed by parameter explanations. It avoids unnecessary details and uses clear language. However, the 'Args:' section could be integrated more smoothly, and it lacks structural elements like bullet points for better readability.

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

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

Given the tool's moderate complexity (2 parameters, external API integration) and the presence of an output schema (which reduces the need to describe return values), the description is partially complete. It covers the basic action and parameters but misses key contextual elements like behavioral traits (e.g., rate limits) and usage guidelines. With no annotations, it should provide more context to be fully 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 adds minimal semantics beyond the input schema. It explains that 'domain' is for a 'Company domain' and 'limit' is for 'Max results,' which provides basic context. However, with 0% schema description coverage and 2 parameters, this doesn't fully compensate for the lack of schema details (e.g., format constraints for domain, range for limit). The baseline is 3 since the description adds some value but not enough to overcome the coverage gap.

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

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

The description clearly states the tool's purpose: 'Find email addresses for a company domain using Hunter.io.' It specifies the verb ('Find'), resource ('email addresses'), and target ('company domain'), and distinguishes itself from siblings like osint_email_finder and osint_email_verify by focusing on domain-based searches. However, it doesn't explicitly differentiate from osint_company_people, which might also involve email-related data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions Hunter.io as the data source but doesn't explain how it differs from siblings like osint_email_finder or osint_company_people, nor does it specify prerequisites, exclusions, or optimal use cases. Usage is implied only by the tool name and description.

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 behavioral disclosure. It states the action ('Detect') but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, privacy implications, or what the output looks like. For a tool that likely queries external services, this lack of transparency is a significant gap.

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

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

The description is concise and front-loaded: the first sentence clearly states the purpose, followed by a parameter section. There's no wasted text. However, the structure could be improved by integrating parameter details more seamlessly or adding brief usage notes.

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 an output schema (which handles return values), no annotations, and low schema coverage, the description is incomplete. It covers the basic purpose and parameter but misses behavioral context, usage guidelines, and deeper parameter semantics. It's minimally viable but leaves gaps for an AI agent to infer 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 0%, so the description must compensate. It adds the parameter 'email' with a brief explanation ('Email to check'), which provides basic semantics. However, it doesn't detail format requirements, validation rules, or examples. With only one parameter, this is minimally adequate but lacks depth.

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

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

The description clearly states the tool's purpose: 'Detect which services an email is registered with using Holehe.' It specifies the verb ('Detect'), resource ('services an email is registered with'), and method ('using Holehe'). However, it doesn't explicitly differentiate from sibling tools like osint_email_verify or osint_email_search, which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like osint_email_verify or osint_email_search, nor does it specify use cases, prerequisites, or exclusions. The only context is the parameter description, which is insufficient 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 carries the full burden of behavioral disclosure. It states the tool verifies email validity and deliverability, implying a read-only check, but does not disclose critical traits such as rate limits, authentication requirements, data sources (e.g., SMTP checks, DNS lookups), or what 'deliverable' entails (e.g., inbox existence vs. bounce detection). This is a significant gap for a tool with no 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief 'Args' section for the parameter. Every sentence earns its place with no wasted words, making it efficient and easy to parse for an AI agent.

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 (1 parameter, no nested objects) and the presence of an output schema (which likely details return values), the description is minimally complete. However, it lacks behavioral context (e.g., rate limits, data sources) and usage guidelines, which are important for an OSINT tool with no annotations. The output schema may cover return values, but the description should still address operational aspects.

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 has 1 parameter with 0% description coverage, and the description compensates by explaining the parameter: 'email: Email to verify.' This adds meaning beyond the schema's basic type definition, clarifying the parameter's role. Since there is only one parameter, the description adequately covers it, earning a baseline 4 for low parameter count and effective compensation.

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

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

The description clearly states the tool's purpose: 'Verify if an email address is valid and deliverable.' It specifies the verb 'verify' and the resource 'email address,' with additional qualifiers 'valid and deliverable' that add specificity. However, it does not explicitly differentiate from sibling tools like 'osint_email_finder' or 'osint_email_search,' which likely serve different purposes (e.g., finding emails vs. verifying them).

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

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

The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites (e.g., needing an email address to verify), exclusions (e.g., not for bulk verification), or comparisons to sibling tools like 'osint_email_finder' (for finding emails) or 'osint_breach_check' (for checking breaches). This leaves the agent without clear usage instructions.

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

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

No annotations are provided, so the description carries the full burden. It states 'Get LinkedIn company data' which implies a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, data freshness, error conditions, or what specific data fields are returned. For an OSINT tool with zero annotation coverage, this is a significant gap in transparency.

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 appropriately sized with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient, though the parameter section could be more integrated. There's no wasted text, but it could be slightly more polished in presentation.

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 an output schema (which handles return values), 2 parameters with 0% schema coverage, and no annotations, the description provides basic purpose and parameter context but is incomplete. It doesn't cover behavioral aspects like data sources, limitations, or error handling, which are important for OSINT tools. The presence of an output schema raises the baseline, but more context is needed for full completeness.

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

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

The description adds parameter semantics by explaining that 'linkedin_url' is a 'Company LinkedIn URL' and 'domain' is a 'Company domain (alternative)', which provides meaning beyond the schema's technical definitions. However, with 0% schema description coverage and 2 parameters, this explanation is minimal. It doesn't clarify format requirements (e.g., URL structure), mutual exclusivity, or which parameter takes precedence. Baseline 3 is appropriate given the schema has no descriptions.

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

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

The description clearly states 'Get LinkedIn company data' which specifies the verb ('Get') and resource ('LinkedIn company data'). It distinguishes from siblings like osint_linkedin_profile (for individuals) and osint_company_enrich (broader company enrichment), though it doesn't explicitly mention these distinctions. The purpose is clear but lacks explicit sibling differentiation.

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

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

The description implies usage through the parameter documentation ('Args: linkedin_url: Company LinkedIn URL, domain: Company domain (alternative)'), suggesting this tool can be used with either identifier. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like osint_company_enrich or osint_company_research, nor does it specify prerequisites 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what the tool does (find URLs) without describing how it works, success rates, rate limits, authentication needs, privacy implications, or what happens when multiple matches are found. For an OSINT tool with no annotation coverage, this leaves critical behavioral aspects unexplained.

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 appropriately sized with two sentences: a clear purpose statement followed by parameter explanations. It's front-loaded with the main function. The Args section is structured but could be more integrated. No wasted words, though slightly terse for a tool with no annotations.

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 annotations, 0% schema description coverage, but an output schema exists, the description is minimally complete. It covers the basic function and parameter purposes, but doesn't address behavioral aspects, limitations, or sibling differentiation. The output schema likely handles return values, so that gap is mitigated. However, for an OSINT tool with privacy implications, more context would be beneficial.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'name' should be a 'Full name' and 'company' is for 'disambiguation', which clarifies parameter purposes beyond the bare schema. However, it doesn't provide format examples, search strategies, or handling of null company values, leaving gaps for a tool with 2 parameters.

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

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

The description clearly states the tool's purpose: 'Find someone's LinkedIn profile URL' - a specific verb (find) and resource (LinkedIn profile URL). It distinguishes from siblings like osint_linkedin_company and osint_linkedin_profile by focusing on URL retrieval rather than company data or profile enrichment. However, it doesn't explicitly contrast with osint_person_enrich or osint_person_research which might overlap.

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 is provided. The description doesn't mention when this tool is appropriate compared to siblings like osint_person_enrich, osint_email_finder, or osint_username_search. It also doesn't specify prerequisites, limitations, or typical use cases beyond the basic function.

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 behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify permissions, rate limits, data freshness, or potential privacy/legal considerations. For an OSINT tool with zero annotation coverage, this leaves significant gaps in understanding its 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 brief but could be more front-loaded. The first sentence clearly states the purpose, but the second sentence ('Args: linkedin_url: LinkedIn profile URL') is redundant with the schema and could be integrated more efficiently. It avoids waste but lacks optimal structure for quick scanning.

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

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

Given the tool's moderate complexity (single parameter, OSINT context), no annotations, but with an output schema present, the description is minimally adequate. It covers the basic purpose and parameter meaning but misses behavioral details and usage guidelines. The output schema likely handles return values, so the description doesn't need to explain those.

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 meaningful context beyond the input schema. The schema has 0% description coverage for the single parameter 'linkedin_url', but the description specifies it's a 'LinkedIn profile URL', clarifying the expected format and purpose. Since there's only one parameter and the description compensates for the schema gap, this earns a high score.

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

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

The description clearly states the tool's purpose: 'Get full LinkedIn profile - experience, education, skills.' It specifies the verb ('Get'), resource ('LinkedIn profile'), and scope of data returned. However, it doesn't explicitly differentiate from sibling tools like 'osint_linkedin_company' or 'osint_linkedin_find', which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'osint_linkedin_company' or 'osint_linkedin_find', nor does it specify prerequisites or exclusions. The only usage hint is the parameter description, which is insufficient for effective tool selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool enriches data using Apollo.io but does not cover critical aspects such as rate limits, authentication needs, data accuracy, privacy implications, or what happens on partial matches. This leaves significant gaps for an OSINT 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 appropriately sized and front-loaded, with the core purpose stated first ('Enrich person data using Apollo.io - find email, title, social profiles.') followed by a parameter list. It avoids unnecessary details, though the parameter explanations are minimal and could be more efficient.

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

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

Given the complexity (OSINT tool with 4 parameters, no annotations, but an output schema exists), the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines. The presence of an output schema means it doesn't need to explain return values, but other gaps remain, making it adequate but with clear room for improvement.

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

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

Schema description coverage is 0%, so the description must compensate. It lists the parameters (first_name, last_name, organization, domain) and briefly explains them (e.g., 'Person's first name'), but does not add meaningful semantics like format constraints, examples, or how parameters interact (e.g., if domain is required when organization is provided). This provides basic clarification but falls short of fully compensating for the lack of schema descriptions.

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

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

The description clearly states the tool's purpose: 'Enrich person data using Apollo.io - find email, title, social profiles.' It specifies the verb ('enrich'), resource ('person data'), and data sources (Apollo.io), but does not explicitly differentiate it from sibling tools like 'osint_person_research' or 'osint_email_finder', which likely have overlapping functions.

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. The description lists what it does but does not mention when it should be used, prerequisites, or exclusions, despite having many sibling tools that might serve similar purposes (e.g., 'osint_person_research', 'osint_email_finder').

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 behavioral disclosure. It mentions 'AI-powered' and 'synthesizes web info', which hints at generative or summarized output, but lacks details on rate limits, data sources, accuracy, privacy implications, or response format. For a tool that likely queries external APIs and processes personal data, this is a significant gap in transparency.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clear 'Args:' section listing parameters. There's no wasted text, and the structure aids readability. It could be slightly more concise by integrating the args into the main description, but it's efficient overall.

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

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

Given the tool's moderate complexity (AI-powered research with external data), no annotations, and an output schema present, the description is partially complete. It covers the basic purpose and parameters but lacks behavioral context (e.g., how results are synthesized, limitations). The output schema reduces the need to explain return values, but more guidance on usage and transparency would improve completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It adds basic meaning for both parameters: 'name' as the person's name and 'context' as additional details like company or role. However, it doesn't provide examples, formatting rules, or constraints (e.g., name format, context length). With two parameters and low schema coverage, this is a minimal but adequate explanation.

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

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

The description clearly states the tool's purpose: 'AI-powered person research using Perplexity - synthesizes web info.' It specifies the verb ('research'), resource ('person'), and method ('using Perplexity'), making it distinct from siblings like 'osint_person_enrich' or 'osint_username_search'. However, it doesn't explicitly differentiate from all siblings, such as 'osint_company_people', which might also involve person data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'osint_person_enrich' or 'osint_query', nor does it specify prerequisites or exclusions. The only implied usage is for person research, but this is already covered by the purpose clarity.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'AI-powered' and 'using Perplexity' which suggests some intelligence/processing, but doesn't disclose rate limits, authentication needs, data sources, privacy implications, or what kind of OSINT results to expect. For a tool with no annotation coverage, this leaves significant behavioral questions unanswered.

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 efficiently structured with a brief purpose statement followed by parameter clarification. Both sentences earn their place by providing essential information. It's appropriately sized for a single-parameter tool, though it could be more front-loaded with clearer differentiation from siblings.

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 an output schema (which handles return values), 1 parameter with description coverage, and no annotations, the description is minimally adequate. However, for a general OSINT query tool among many specialized alternatives, it should provide more context about its role in the ecosystem. The existence of output schema helps, but the description lacks completeness about when and why to use this versus other tools.

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

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

With only 1 parameter and 0% schema description coverage, the description compensates well by explaining that 'prompt' should be a 'Research question or query'. This adds meaningful context beyond the bare schema, clarifying the expected input format and purpose. The baseline for 0 parameters would be 4, and this meets that standard.

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

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

The description states the tool performs 'AI-powered OSINT query using Perplexity', which indicates a general-purpose intelligence gathering function. However, it's vague about what specific OSINT activities it performs compared to its many specialized siblings (like email search, DNS lookup, breach checks). It doesn't clearly distinguish itself from these alternatives.

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 about when to use this tool versus the 20+ specialized OSINT siblings. The description doesn't indicate whether this is a general-purpose fallback, a starting point, or when specific tools like osint_email_search or osint_dns_lookup would be more appropriate. There's no context about use cases 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't mention critical details like rate limits, authentication requirements, error handling, or data freshness. For a tool accessing an external API like Shodan, this is a significant gap in transparency.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief parameter explanation. There's no wasted text, though the structure could be slightly improved by integrating the parameter note more seamlessly. Overall, it's efficient but not perfectly polished.

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

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

Given the tool's moderate complexity (external API call), lack of annotations, and an output schema (which handles return values), the description is minimally complete. It covers the basic purpose and parameter intent but misses behavioral context (e.g., API constraints) and usage differentiation from siblings. The output schema reduces the need for return value details, but other gaps remain.

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 minimal semantics for the single parameter 'domain' by stating 'Domain to look up,' which clarifies its purpose. However, schema description coverage is 0%, and the description doesn't provide format details (e.g., TLD requirements) or examples. Since there's only one parameter, the baseline is higher, but the lack of enrichment keeps it at an adequate level.

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

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

The description clearly states the tool's purpose: 'Get Shodan DNS data - subdomains and DNS records.' It specifies the verb ('Get') and resource ('Shodan DNS data') with concrete examples ('subdomains and DNS records'). However, it doesn't explicitly differentiate from sibling tools like 'osint_dns_lookup' or 'osint_shodan_host', which would be needed for a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'osint_dns_lookup' (general DNS) or 'osint_shodan_host' (Shodan host data), nor does it specify prerequisites (e.g., Shodan API access) or use cases (e.g., security reconnaissance). This leaves the agent to infer usage from the purpose 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 full burden of behavioral disclosure. It mentions what data is retrieved (ports, services, vulnerabilities) but lacks details on rate limits, authentication needs, error handling, or response format. This is a significant gap for a tool that likely involves external API calls.

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

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

The description is brief and front-loaded with the core purpose, followed by a clear 'Args' section. It avoids unnecessary words, though the structure could be slightly improved by integrating the parameter info more seamlessly.

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

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

Given the tool's moderate complexity (external API call), no annotations, and an output schema present, the description is minimally adequate. It covers the basic purpose and parameter but lacks behavioral context like rate limits or error cases, which the output schema alone doesn't address.

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

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

Schema description coverage is 0%, but the description compensates by specifying the 'ip' parameter as 'IP address to look up', adding semantic meaning beyond the schema's type definition. However, it doesn't provide format details (e.g., IPv4 vs. IPv6) or examples, leaving some ambiguity.

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 ('Get Shodan data') and resource ('for an IP'), specifying it retrieves ports, services, and vulnerabilities. It distinguishes from siblings like 'osint_shodan_domain' by focusing on IP addresses, but could be more explicit about the distinction from other host-related tools like 'osint_censys_host'.

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 explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for IP lookups but doesn't mention when to choose it over similar tools like 'osint_censys_host' or 'osint_dns_lookup', nor does it specify prerequisites 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?

No annotations are provided, so the description carries the full burden. It mentions the tool uses 'Sherlock' (implying an external service), but doesn't disclose behavioral traits like rate limits, authentication needs, data sources, error handling, or what 'accounts across platforms' entails (e.g., social media, forums). This is inadequate for a tool with potential complexity.

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

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

The description is extremely concise and front-loaded: the first sentence states the purpose, and the second provides parameter semantics. There's no wasted text, and it's structured for quick comprehension.

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 an output schema (which handles return values), no annotations, and low complexity (one parameter), the description is minimally complete. It covers purpose and parameter meaning but lacks behavioral context and usage guidelines, making it adequate but with clear 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?

The description adds meaningful context for the single parameter: 'username: Username to search' clarifies it's a search target. With 0% schema description coverage and only one parameter, this compensates well. However, it doesn't specify format constraints (e.g., case sensitivity, special characters), so it's not a full 5.

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

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

The description clearly states the tool's purpose: 'Find accounts across platforms for a username using Sherlock.' It specifies the verb ('Find'), resource ('accounts'), and method ('using Sherlock'), which distinguishes it from sibling tools focused on email, company, or domain searches. However, it doesn't explicitly differentiate from similar username search tools (none exist in siblings), so it's not a perfect 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, limitations, or compare it to sibling tools like osint_person_enrich or osint_query that might overlap in functionality. The agent must infer usage from the purpose 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get WHOIS registration data') but doesn't add any context about rate limits, authentication needs, data freshness, or what the output entails. For a tool with no annotations, this leaves significant gaps in understanding its operational 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 highly concise and well-structured: a clear purpose statement followed by a minimal parameter explanation. Every sentence earns its place without redundancy, making it easy to scan and understand 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?

Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the core purpose and parameter basics, though it lacks behavioral context and usage guidelines. For a simple lookup tool, this is adequate but not fully comprehensive.

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 includes a brief parameter section: 'domain: Domain to look up,' which adds basic meaning beyond the input schema (which has 0% description coverage). However, it doesn't specify format constraints (e.g., TLD requirements) or examples, so it only partially compensates for the low schema coverage. With 1 parameter and some added semantics, a 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 clearly states the tool's purpose: 'Get WHOIS registration data for a domain.' It specifies the verb ('Get') and resource ('WHOIS registration data'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate this tool from its siblings (like osint_dns_lookup or osint_shodan_domain), which could provide similar domain-related information but for different purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or exclusions, and with many sibling tools (e.g., osint_dns_lookup, osint_shodan_domain) that might overlap in domain-related queries, the agent is left without clear direction on tool selection.

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