JobVerify

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context about using crt.sh with no key required, aligning with the safe, idempotent nature. No contradictions.

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 clear, front-loaded sentences with no filler. Every sentence adds value: action, interpretation guidance, usage context.

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

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

For a simple lookup tool with output schema and annotations, the description covers what it does, when to use, how to interpret results, and relationship to a sibling. No 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% (though schema has descriptions for both parameters). The description does not add parameter details beyond what schema provides, so it meets baseline but doesn't compensate.

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

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

The description clearly states the verb ('look up') and resource ('domain's SSL certificate history'), specifies the source ('crt.sh'), and distinguishes from sibling 'check_domain' by noting it complements RDAP age 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?

Provides explicit when-to-use ('when you have a company/link domain and want infra age corroboration'), how to interpret results (fresh certs = phishing, long history = established), and references an alternative sibling ('Complements check_domain').

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows the tool is a safe, idempotent read operation. The description adds that no key is needed and that being listed is a strong fraud signal, but it does not go beyond the annotation context significantly.

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: two short paragraphs with no wasted words. The purpose and usage are front-loaded in the first sentence, and the second paragraph provides a clear trigger condition.

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 (context signal) and is simple (one required parameter), the description covers the essential usage context and purpose. It does not need to explain return values because the output schema handles that. The only minor gap is the lack of parameter detail, but the schema and context compensate.

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% per context signals, meaning the input schema has no descriptions beyond the JSON structure. The description mentions address type (BTC/EVM) but does not detail the response_format parameter or provide additional meaning beyond the schema's property titles.

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

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

The description clearly states the verb 'Check' and the resource 'crypto address' against scam databases. It specifies the type (BTC/EVM) and the action (checking against open databases), distinguishing it from sibling tools that check other entities.

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 says 'Use when: extract_entities found a crypto address in the message', providing clear context for when to use the tool. It also warns that a request for crypto for a job is a red flag. However, it does not explicitly mention when not to use or list alternatives.

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

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

Annotations already provide readOnly, idempotent, non-destructive hints, so the description's addition about scam signals is helpful but not necessary. No contradictions with 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?

Three sentences, no waste, front-loaded with purpose and usage guidance.

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

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

Covers the key scenario and usage. Has an output schema so return values need not be described. Slight gap: no mention of error handling or edge cases, but overall sufficient for a straightforward lookup 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 0%, but the schema itself provides parameter descriptions. The tool description does not add parameter-level detail; baseline 3 is appropriate.

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

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

The description clearly states the tool looks up domain registration via RDAP and assesses its age, distinguishing it from siblings like check_typosquatting or check_domain_auth.

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

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

Explicitly states when to use it ('Use when: you have a company website, job-portal link, or email domain'), providing clear context for selection.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds value by specifying exactly what DNS records are checked and how to interpret results for spoofability, which is beyond annotations.

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

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

The description is three sentences long, front-loaded with the purpose, and contains no fluff. Every sentence adds value.

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

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

Given the read-only nature, annotations, and presence of an output schema, the description adequately covers purpose, usage context, and interpretation of results. No major 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 input schema already has descriptions for both parameters (domain, response_format). The tool description does not add any additional meaning about the parameters themselves, so 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 verb 'check' and the resource 'a domain's SPF and DMARC DNS records'. It provides context about email spoofability, which implicitly differentiates from siblings like check_domain or check_email, but does not explicitly distinguish.

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 says 'Use when: you have the sender's / company's domain.' This gives clear context. However, it does not mention when not to use it or suggest alternatives like check_domain.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by listing the checks performed and mentioning the optional company_domain parameter, but does not cover potential error conditions or rate limits.

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

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

The description is concise, with only three sentences that efficiently cover purpose, usage condition, and output. No redundant information.

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

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

Given the simplicity of the tool and the presence of an output schema, the description adequately covers the key aspects: what it does, when to use it, and what the output looks like. It could mention the response_format parameter more explicitly, but it's acceptable.

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 provides detailed descriptions for all three parameters. The description adds marginal value by summarizing the checks (e.g., disposable domain, MX records) but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the tool assesses a recruiter's email for disposable domain, free provider, MX records, and company domain matching. It distinguishes itself from sibling tools (e.g., check_email_footprint, parse_email_headers) by focusing on risk assessment and domain verification.

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

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

The description includes a 'Use when' clause specifying the condition (having the sender's email). It does not explicitly mention when not to use or list alternative tools, but the context is clear enough for an AI to decide.

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. The description adds 'no key' as a minor behavioral detail but does not disclose other behaviors like what happens if email is invalid or rate limits. Given annotations cover safety, this is adequate.

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 exceptionally concise: three short sentences covering purpose, value interpretation, and usage. No wasted words.

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

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

Given the existence of an output schema, the description need not detail return values. It provides clear context about the tool's function and usage. Minor gap: no mention of what 'linked accounts' includes, but overall sufficient.

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

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

Schema description coverage is 0%. Description implicitly covers the 'email' parameter but omits 'response_format'. No parameter-specific details are given beyond what the schema provides, leaving the response_format parameter underexplained.

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

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

The description clearly states the tool checks an email's public Gravatar profile and linked social accounts. It uses specific verb and resource, distinguishing it from sibling tools like check_email, check_domain, etc.

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

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

The description provides explicit guidance on when to use ('quick digital-footprint read on a sender's email') and hints at context (legitimacy signal vs. throwaway). It does not explicitly mention when not to use, but the context is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that no key is needed, but does not disclose behavior on failure (e.g., org not found) or any rate limits. Adequate given 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 compact with no wasted words. It front-loads the purpose and ends with a clear usage hint. 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?

The description covers the main functionality and usage context. An output schema exists, so return values are not needed. Missing details on edge cases (e.g., partial matches) but still sufficient for typical use.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions org_or_name implicitly and expected_domain via 'domain match', but does not describe response_format or clarify the input format for org_or_name. Partially compensates but leaves gaps.

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

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

The description clearly states it verifies a GitHub organization's existence, age, repo count, and domain match. It distinguishes from sibling tools that check other entities like certificates, domains, or emails.

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

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

The description provides a specific use case ('when the company claims to build software/tech'), which helps the agent decide when to invoke. It lacks explicit alternatives but context from sibling names implies its niche.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the tool is safe. Description adds value by noting no API key required and interpreting results ('red flags'), which aids agent decision-making.

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 in the first paragraph cover the core functionality, and a second contextual sentence provides usage guidance. Concise, front-loaded, no redundant information.

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

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

With output schema available, the description covers tool purpose, usage, and key result interpretation. Missing details like data freshness or rate limits, but acceptable for a read-only tool with openWorldHint.

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 0% at top level, but property descriptions exist for both parameters. The tool description reinforces the ip parameter but does not elaborate on response_format. Overall, schema handles details adequately, yielding baseline 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 explicitly states the tool checks an IP against specific blocklists (FireHOL, Tor exit list) and identifies ASN/org/country, with a datacenter heuristic. It clearly distinguishes from sibling check_* tools by focusing on IP addresses.

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

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

Provides explicit use case ('when you have an originating IP from email headers') but lacks explicit when-not-to-use or alternative tools. Still, the context is clear and helpful.

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 indicate read-only, idempotent behavior. The description adds context that validation is performed offline using libphonenumber and that VoIP/invalid numbers are flagged as red flags. No contradiction with 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?

Extremely concise: two sentences covering purpose and usage. No filler, front-loaded with the core function. Every sentence is valuable.

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 and the presence of an output schema (not shown but confirmed), the description covers the main behavioral aspects including offline validation and red flag indicators. It lacks details about required permissions or prerequisites, but these are implied by the read-only annotation.

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 does not add meaning beyond the input schema, which already has descriptions for each parameter. With schema description coverage at 0%, the description should compensate but fails to explain parameter usage or formats in detail.

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

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

The description clearly states the tool's purpose: validating a phone number, including checking validity, type (mobile/VoIP/premium), region, and carrier. It uses specific verbs and resources, and is distinct from sibling tools that check other types of data like emails or domains.

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

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

Provides a concrete use case ('a recruiter gives a phone/WhatsApp number'), giving context for when to use the tool. However, it lacks explicit guidance on when not to use it or mention of alternative tools for related 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?

Description adds 'offline, no key' and implies deterministic operation, complementing annotations (readOnlyHint, openWorldHint, idempotentHint). No contradictions.

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

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

Two sentences plus a use-when line; every sentence is informative. Extremely concise with no wasted words.

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

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

Tool is simple (1 required param), schema and description fully cover purpose, usage, and parameters. Output schema exists (not shown but indicated). Complete guidance.

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?

Input schema already describes parameters (text, response_format) well. Description adds value by listing the specific scam patterns checked, providing context beyond schema.

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

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

Description clearly states 'Scan message text for known recruiter/job-scam tactics', listing specific tactics. It distinguishes from sibling check_* tools by focusing on scam patterns in text.

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

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

Explicitly states 'Use when: you have the raw offer text and want deterministic TTP hits.', providing clear condition for use.

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

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

Annotations already provide readOnlyHint and idempotentHint. Description adds key behavioral traits: 'offline, no key', and lists detection types (IDN, typos, high-abuse TLDs). No contradiction.

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

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

Two concise sentences, front-loaded with core purpose. Every sentence adds value without redundancy.

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

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

Tool is simple with one required param and optional brand/format. Description covers core detect function, usage context, and operational constraint. Output schema exists to handle return details.

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?

Input schema has descriptions for all parameters (100% coverage). Description adds marginal value by explaining brand usage with examples, but not significantly beyond schema.

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

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

Clear verb 'detect' with specific resource 'lookalike/typosquatting/homograph domains'. Provides concrete examples like 'google-careers' and 'linkedln'. Distinguishes from sibling 'find_lookalike_domains' by focusing on brand comparison.

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

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

Explicitly states when to use: 'you have a domain and a real brand it might be impersonating'. No explicit when-not or alternatives, but context is clear and relevant.

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, destructiveHint=false. Description adds value by specifying the data sources and interpretation ('Any hit means high risk'), providing behavioral context beyond annotations.

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

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

Description is extremely concise: two short paragraphs that front-load the main action and usage context. No unnecessary words.

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

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

Given the tool's simplicity, the description covers purpose, usage context, data sources, risk interpretation, and is complemented by an output schema. No 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?

Input schema has descriptions for both parameters (url, response_format), so schema coverage is high. Description doesn't add parameter-specific details beyond what schema provides, but the mention of 'no API key' is a minor contextual addition.

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

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

Description clearly states the tool checks URLs/domains against specific phishing and malware blocklists (Phishing.Database, URLhaus), and defines what a hit means. Differentiates from sibling check tools by specifying threat types and sources.

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

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

Explicit guidance is given: 'Use when: the offer contains a link (application portal, form, download).' This tells the agent when to apply, though it lacks explicit when-not-to-use or alternatives.

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

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

Annotations already declare read-only, open-world, and idempotent hints. The description adds substantial behavioral context: it checks three specific platforms, reveals online history and account age, and interprets an absent result as a sock-puppet signal. It also notes 'no key' meaning no API key required. No contradiction with 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 concise (two short paragraphs), front-loaded with the core functionality, and every sentence adds value. No redundant or vague 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's simplicity, the presence of an output schema, and thorough annotations, the description is complete. It explains the platforms, the unique signal (sock-puppet), and the use case. The output schema would cover return format details, so no further description needed.

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 provides descriptions for both parameters ('username' and 'response_format'). The description adds minimal parameter semantics beyond noting that no key is needed. Schema coverage is effectively high despite stated 0% in context signals (likely an error), so baseline 3 applies. The description does not elaborate on parameter formats or constraints.

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

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

The description clearly states the tool checks usernames across GitHub, Reddit, and Keybase, reveals online history and account age, and signals sock-puppet accounts. It uses a specific verb ('check') and resource ('username'), and distinguishes from sibling tools by listing specific platforms and the unique sock-puppet insight.

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

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

The description provides explicit usage context: 'Use when: you have a recruiter's handle/username to vet.' It also suggests a complementary action ('web-search the username' for broader coverage), but does not explicitly state when not to use this tool, leaving room for minor improvement.

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 value beyond annotations by explaining that a missing or recent first snapshot indicates a new page and that it serves as a legal proxy for account age. No contradictions with annotations (readOnlyHint, idempotentHint). However, it does not disclose potential rate limits or error behavior.

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

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

The description is three sentences, front-loaded with the main purpose, followed by interpretation and usage guidance. Every sentence adds value, no 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?

The description covers the core purpose and usage. With an output schema present, the return values do not need to be explained. However, it lacks details on potential edge cases (e.g., unreachable URLs) or the exact nature of the first snapshot.

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% per context, but the description does not discuss the parameters in detail. It only mentions URLs by example, and the response_format parameter is not addressed. The description should have compensated for the lack of schema descriptions but did not.

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

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

The description clearly states the tool checks Internet Archive history of a URL with examples (LinkedIn profile, company site) and explains its purpose as a proxy for account age. It distinguishes from sibling tools like check_url and check_domain by specifying this is for web archive history.

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 says 'Use when: you have a profile/company URL and want an age lower-bound.' It provides clear context but does not mention when not to use or alternative tools, which are implied by sibling tool names.

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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it is 'offline, no key' and comprehensive, which are useful behavioral details 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 concise (3 sentences) and front-loaded with the core action and entity types, followed by usage guidance. No wasted words.

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

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

Given the presence of an output schema (not shown) and the description covering extraction purpose, entity list, and workflow with siblings, the description is complete for the tool's complexity.

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

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

Schema description coverage is 0% for properties according to context signal, but actually the schema has descriptions for each parameter. The description does not add new parameter-specific meaning beyond listing entity types; it meets the baseline.

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

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

The description clearly states that the tool parses raw recruiter messages into structured entities, listing specific entity types (emails, domains, etc.) and noting it is offline and keyless. This distinguishes it from the sibling check_* tools that investigate specific entities.

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

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

Explicitly instructs to 'Run this FIRST, then feed each entity to the specific check_* tools so nothing is missed' and provides a 'Use when' condition. This gives clear sequencing and 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 indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that it reads web.archive.org snapshots (not live) and is the legal way, plus returns snapshot date. No contradictions.

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, with two sentences covering action and usage. No unnecessary words.

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

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

Given the tool's simplicity and presence of an output schema, the description adequately covers return value (extracted text and snapshot date) and usage context. Could mention response_format options but not required.

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%, meaning the description does not add meaning to parameters. While the schema itself has parameter descriptions, the tool description does not explain them, and with low coverage, compensation is required but not 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 it fetches archived text from the Internet Archive for LinkedIn profiles/company pages, distinguishing from live LinkedIn and specifying the legal method.

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 says to use when you have a LinkedIn/company URL and want to evaluate content, providing clear context. However, it does not specify when not to use or offer alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds minimal extra behavioral context: 'no key' and 'return the ones that actually resolve in DNS'. It does not disclose rate limits or other nuances. With annotations covering the safety profile, a 3 is appropriate.

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 plus a 'Use when' line, extremely concise and front-loaded. Every sentence adds value: defines the action, output, and use case. Zero wasted words.

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

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

Given the output schema exists (not shown but present) and annotations are comprehensive, the description is mostly complete. It covers the tool's purpose and primary use case. The only gap is not mentioning optional parameters (max_checks, response_format), but these are well-documented in the schema. The description adequately fits the tool's complexity.

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

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

Schema description coverage is 0%, meaning the tool description does not explain any parameters. The schema itself has good descriptions, but the description must compensate due to low coverage. It does not add any parameter-level guidance beyond the schema, so the score is below baseline.

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

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

The description uses a specific verb 'generate' and identifies the resource 'typo/homoglyph/TLD permutations of a REAL brand domain', clearly stating the output 'ones that actually resolve in DNS'. It distinguishes from sibling tools like check_domain or check_typosquatting by focusing on generating permutations rather than checking a single domain.

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

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

The description explicitly says 'Use when: you know the real company domain and want to hunt impersonators', providing clear context. However, it does not explicitly mention when not to use or compare with alternatives like check_typosquatting, which is a sibling tool.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool is offline and requires no API key, which is valuable beyond the annotations. No contradictions.

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

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

Two sentences: the first defines action and outputs, the second provides usage guidance. No redundant information; every sentence serves a 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?

The tool has a simple interface with one required parameter and an output schema (implied). The description covers the key analyses performed and even suggests a related tool (check_ip). All essential information is provided.

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 provides detailed descriptions for both parameters (raw_headers and response_format), so schema coverage is 100%. The description does not add parameter-level details beyond the schema, but the context about offline usage is general.

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 analyzes raw email headers for spoofing, specifying SPF/DKIM/DMARC results, header mismatches (From vs Return-Path vs Reply-To), and the originating IP. This distinguishes it from sibling tools like check_email or check_domain_auth.

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 says 'Use when: the user can paste the full raw headers of a suspicious email,' providing clear context. It does not explicitly state when not to use or list alternatives, but the usage guidance is direct and helpful.

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 context: it uses Google News RSS (no key), and is especially useful for small companies. It does not mention rate limits or result limitations, but given annotations cover the safety profile, the description adds meaningful behavioral context.

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

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

The description is well-structured with a main paragraph and an important note. It uses bold for emphasis and is concise—every sentence adds value. It is front-loaded with the core purpose and then provides usage guidance and parameter semantics. No wasted words.

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

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

Given the tool's complexity (search with optional parameters) and the presence of annotations and output schema, the description is complete. It covers purpose, usage guidelines, behavioral context, and parameter semantics. The output schema handles return value details, so the description does not need to explain them.

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 schema itself contains descriptions for parameters. The description adds significant value by explaining the critical 'country' parameter and how 'company_domain' can infer it. The 'language' parameter is said to be inferred from country, and 'response_format' is straightforward. The description compensates for the lack of schema descriptions for the most important 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: 'Search regional/local news for a company via Google News RSS (no key).' It also explains its specific value for small companies not covered by GLEIF/SEC, differentiating it from sibling tools that focus on domain, email, or address 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 explicitly states when to use the tool: 'Use when: verifying a small/local company beyond registries.' It also provides crucial prerequisite guidance: determine the company's actual country first and pass it as 'country' or infer it via 'company_domain'. It does not explicitly state when not to use, but the context is clear enough.

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

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

Annotations declare readOnlyHint, idempotentHint, and not destructive, so core safety is covered. The description adds valuable behavioral context: uses OpenStreetMap (no key), assesses business vs. residential, and flags unresolved or residential HQs. This enhances transparency without contradiction.

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 efficiently convey the tool's purpose, usage context, and key behavioral details. No wasted words; front-loaded with the primary function.

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 existence of an output schema (not shown but indicated), the description need not detail return values. It covers the main input (address), the core behavior (geocoding and classification), and usage context. It is complete for a verification tool of this nature.

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 provides descriptions for both parameters (address, response_format), so baseline is 3. The description adds meaning beyond schema by explaining the verification logic (geocoding, classification, red flag), which helps the agent understand what happens with the address parameter.

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

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

The description clearly states the tool geocodes a physical address via OpenStreetMap and classifies it as business or residential. It distinguishes from sibling tools by focusing on address verification rather than email, domain, or phone 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 includes an explicit 'Use when' clause ('when an offer lists a company address to verify'), providing clear context. While it doesn't explicitly state when not to use, the sibling tools cover other verification needs, making the guidance sufficient.

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. The description adds valuable context: it searches the LEI database without an API key, and explains the significance of 'ACTIVE status' vs 'no match'. This goes beyond the annotations to inform the agent about data source and evidence strength.

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 (2 sentences) and front-loads the purpose. Every sentence adds value: source, evidence interpretation, and usage condition. No wasted words.

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

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

Given the tool's simplicity and the presence of an output schema, the description covers the core purpose, data source, evidence interpretation, and usage context. It lacks details on optional parameters but is otherwise complete for an agent to decide when to use it.

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

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

The description only mentions 'company name', ignoring the optional 'jurisdiction' and 'response_format' parameters. Even though the input schema provides descriptions for these (schema coverage appears high), the description adds no value for parameters beyond the name. It fails to guide the agent on available optional inputs.

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

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

The description clearly states the verb 'Search' and the resource 'global LEI database (GLEIF)' for a company name. It distinguishes itself from sibling tools (e.g., check_domain, check_email) by specifying a unique data source and purpose. The evidence interpretation ('active status is strong evidence') further clarifies the tool's role.

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 'Use when: a company name is claimed in the offer.' This provides clear context for when to invoke the tool. It does not explicitly mention when not to use or alternatives, but the context is sufficient given the sibling list.

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