Lead Intelligence

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

Annotations already declare the tool read-only and non-destructive, lowering the burden. The description adds behavior beyond those: it 'finds the ATS itself' and honestly reports 'confirmed zero, partial, and unresolved states,' indicating it won't return false negatives. It also discloses the per-call cost, which is useful operational context not in 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 accomplishes its task in one focused sentence plus a brief pricing note. It front-loads the primary action, lists supported ATS systems, and summarizes key output states without fluff. 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 moderate complexity and absence of an output schema, the description covers the main return values (attributed jobs, function/seniority, evidence, states) and mentions the unresolved-state honesty. It doesn't describe table structure or pagination, but that's partly in the schema. Overall it's sufficient for an agent to select and call the tool.

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

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

The description itself adds no parameter details, but the input schema provides 100% coverage with rich explanations for each of the 4 parameters, including examples, defaults, and edge cases. Baseline 3 is appropriate because the schema handles the heavy lifting and the description doesn't need to compensate.

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

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

The description opens with a specific verb 'Resolve' and a clear resource: company domains to public ATS boards across six named platforms. It distinguishes this tool from siblings by focusing on ATS job scraping, and explicitly lists the output attributes (jobs, seniority, source evidence, states). No 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 implies its use case (resolving domains to ATS jobs) but gives no explicit when-to-use guidance or exclusions. It doesn't reference alternatives among siblings or state when a different tool would be better, relying instead on the schema's detailed parameter descriptions for 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 include readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds context about exact BYOD crawling, no web discovery, and pricing ($0.05/call), which resource beyond annotations. However, it does not disclose potential side effects beyond billing, data persistence, or the nature of 'crawling' behavior. It adds some value but not rich behavioral detail.

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

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

The description is a single concise sentence that front-loads the purpose. It includes pricing and technical constraints without unnecessary fluff. However, the phrase 'exact BYOD crawling and no discovery' is somewhat jargon-heavy and could be clearer, slightly reducing the score.

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 7 parameters, no output schema, and moderate complexity, the description provides basic purpose and constraints but lacks information about return format, lead scoring, or what constitutes a 'gap.' The schema covers parameters, but the absence of output schema and limited behavioral context means the description is not fully complete.

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

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

Schema description coverage is 100%, so all parameters have descriptions in the schema. The tool's description does not add any parameter-specific semantic value; it only refers to analyzing websites. With full schema coverage, the baseline 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 uses a specific verb ('Analyze') and resource ('clinic websites') with a clear outcome ('reception-channel gaps'). It distinguishes itself from sibling tools like 'restaurant-booking-gap-lead-finder' by targeting clinics and reception channels, making its purpose unambiguous.

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

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

The description implies the tool is for analyzing submitted clinic websites, but it does not provide explicit when-to-use guidance or alternatives. The mention of 'exact BYOD crawling and no discovery' hints at constraints but not a clear use case relative to siblings. There is no explicit exclusion or comparison, so the guidance is merely implied.

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 openWorldHint and destructiveHint, but the description adds valuable behavioral context: same-document schema.org verification, no pattern guessing or SMTP probing, and a granular outcome/pricing structure (free for no-match, role mailbox, ambiguous, partial; paid only on published match). It does not mention side effects or return format, but given the annotations cover safety, this is acceptable. 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 and front-loaded with the core purpose. The first clause states the action, followed by verification method, exclusions, and pricing. Every sentence/clause earns its place, and there is no extraneous information. The pricing details are compact yet informative.

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 behavior, verification method, exclusions, and pricing/outcome categories, which is comprehensive for a lookup tool. It does not describe the exact output structure, and since no output schema exists, this is a minor gap. However, the outcome categories (match, no-match, role mailbox, ambiguous, partial) imply what results may look like, making the description largely 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?

Schema description coverage is 100%, with each parameter (people, domain, fullName, inputRef, companyName, maxConcurrency, maxPagesPerPerson) fully documented. The description reinforces that emails must be published and schema.org-verified, but it does not add new parameter-specific details beyond what the schema already provides. Baseline 3 is appropriate when the schema carries the load.

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

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

The description clearly states the tool finds a named person's work email published on their own company website and verified by a same-document schema.org Person assertion. It explicitly excludes pattern guessing and SMTP probing, which sharply distinguishes it from alternative email-finding approaches. The verb 'find' and resource 'work email' are specific and unambiguous.

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 strong usage context: it is for finding published, verified emails on a company website, and explicitly says it does not guess patterns or probe SMTP, so it should not be used when unverified or guessed emails are acceptable. The pricing model ('$0.01 only when a published match is found; no-match... are free') clarifies when the tool is cost-effective, effectively guiding usage decisions. However, it does not name any sibling tools as alternatives, so explicit alternatives are missing.

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 discloses key behavioral traits beyond the annotations: it uses the caller's own BYOK key, charges $0.02 per verified contact via USDC on base, and only bills for verified results (ambiguous/empty are free). It also implies external data provider calls. This adds context that the boolean hint annotations do not capture, such as cost and verification semantics.

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

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

The description is two sentences, with the first sentence front-loading the action and resource, and the second sentence adding pricing and fallback behavior. Every phrase serves a purpose—there is no fluff, repetition, or tangential 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 moderate complexity (4 parameters, no output schema) and sparse annotations, the description provides a solid overview of purpose, pricing, and edge cases. It does not fully describe the output structure, but the title and first sentence imply the output (hiring manager name + email). The schema fills in parameter details, making this reasonably complete for selection and invocation.

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

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

The input schema already provides 100% description coverage for all 4 parameters, including details like 'Direct posting link on a supported board' and 'Your own key, used on your own quota.' The main description adds high-level context about Greenhouse/Lever and BYOK, but it does not significantly extend the meaning beyond what the schema already explains, meeting the baseline for high schema coverage.

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

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

The description clearly states the tool's function: 'Turn a Greenhouse or Lever vacancy into the named hiring owner behind it, with a provider-verified work address.' This is a specific verb ('turn') with a specific resource ('vacancy') and output ('hiring owner' + 'verified work address'). It distinguishes itself from sibling tools like domain-to-verified-work-email by focusing on job posting URLs and ATS boards.

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 context—it's for Greenhouse or Lever vacancies with a BYOK enrichment key, and notes that unsupported boards yield free empty results. However, it does not explicitly state when to use this tool versus alternatives, nor provides clear exclusions beyond the board-type limitation. The guidance is mostly implied rather than explicit.

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 and non-destructive. The description adds useful context: per-call pricing, detailed output (rejections, confidence gaps, safe actions, run summary), and emphasis on auditability. 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 a single information-dense sentence plus pricing, front-loading the main actions. It is efficient though slightly dense due to the list of outputs.

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 complex tool with no output schema, the description explains return values and context well. Input mechanics are left to the schema, which is fully covered.

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?

All 6 parameters have full schema descriptions, so the description need not add much. It references the checks (dedupe, email, domain, score) but does not expand on parameter details 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 what the tool does: normalize, deduplicate domains/emails, check DNS/MX, score leads, and provide a run summary. It distinguishes itself from sibling lead-finder tools by focusing on cleaning/hygiene and CRM staging.

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

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

The description provides clear context (auditable CRM staging) and the schema adds integration guidance, but it does not explicitly name alternatives or say when not to use this 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 define readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds context about scanning five fixed Socrata datasets and returning evidence-backed signals, and mentions pricing, but it does not disclose side effects, failure behavior, or rate limits. This is acceptable given the annotation coverage, but not particularly rich.

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

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

The description is a single, information-dense sentence followed by a pricing note. It is front-loaded with the core purpose and contains zero redundant words. Every phrase ('Detect', 'five fixed Socrata datasets', 'evidence-backed signals') 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 tool has six parameters and no output schema, yet the description is minimal. It does not explain what 'evidence-backed signals' looks like, how the parameters influence output, or any additional context about the datasets. However, the schema fully covers parameters, and annotations cover safety, so the description is just sufficient for a basic understanding.

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

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

Schema description coverage is 100%, and the description itself provides no additional parameter semantics. The baseline of 3 applies because the schema fully documents parameters like maxResults, lookbackDays, and freshnessMinutes, leaving no gap that the description needs to fill.

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 ('Detect') and identifies a clear resource ('commercial permit and license openings from five fixed Socrata datasets'), which fully distinguishes this tool from siblings like restaurant-booking-gap-lead-finder or lead-list-cleaner. The title and description align to convey exactly what the tool does.

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

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

The usage context is implied by the tool's name and description, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It does not mention scenarios such as 'use when you need permit leads' or 'not for residential permits'.

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 and destructiveHint=false. The description adds 'Free' and the instruction to call it first, which conveys no-cost access and an ordering dependency—useful context 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 entire description is one efficient sentence, front-loaded with 'Free' and a clear action. Every phrase adds value with no redundancy.

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

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

For a zero-parameter, read-only tool with no output schema, the description covers what it does, what it returns, its cost, and when to use it. It is fully adequate for the agent to select and invoke correctly.

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

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

The tool has 0 parameters, so the description need not explain parameter behavior. The baseline of 4 applies, and the description reinforces that no input is required.

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 lists every paid tool in the 'lead-intelligence' bundle with price, payTo address, and network. It uses a specific verb ('list') and resource, and it distinguishes itself from sibling lead-finder tools by focusing on pricing.

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 'Call this first if you don't have a wallet ready yet,' providing a clear condition for when to invoke it. It does not mention when not to use it or name alternatives, but this context is sufficient for the tool's simple role.

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

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

The description adds useful behavioral context beyond the annotations: a per-call cost of $0.05, pricing currency (USDC on base), and the crawling mode ('exact BYOD' and 'no discovery'). It does not contradict the annotations, which already declare destructiveHint=false and readOnlyHint=false. However, 'BYOD' remains unexplained, and there is no mention of rate limits or failure 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 extremely concise—a single sentence that front-loads the core function and follows with cost and technical constraints. Every phrase adds value, and there is no redundant or filler content, making it easy to scan.

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

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

Without an output schema, the description does not clarify the structure or scoring of the 'gap leads' that will be returned. The cost statement is ambiguous ('per call' could mean per restaurant or per request). Inputs are well covered by the schema, but the overall context is incomplete for a paid tool with side effects (external crawling).

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 coverage is 100%, so the schema already provides detailed descriptions for all 7 parameters. The description does not add additional parameter-specific meaning beyond clarifying the high-level purpose (analyzing restaurant websites for booking gaps). The baseline of 3 is appropriate given the complete schema coverage.

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

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

The description clearly states the tool 'Analyze submitted restaurant websites for booking-channel gaps', which includes a specific verb, resource, and expected outcome. It distinguishes itself from sibling tools like 'clinic-reception-gap-lead-finder' by targeting restaurants, though the 'BYOD' acronym is unexplained and slightly obscures the purpose.

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

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

Usage guidance is implied rather than explicit. The phrase 'submitted restaurant websites' signals that users should provide the websites, and 'no discovery' indicates this tool does not find websites on its own. However, there is no explicit 'when to use this vs. alternative' statement, and no mention of scenarios where a different tool would be more appropriate.

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