Company Intel

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

Annotations already provide readOnlyHint=true and destructiveHint=false, indicating safe read-only access. The description adds useful context about API usage and cost ($0.01/call, x402 USDC) but does not explain pricing model details, rate limits, or pagination behavior for larger company batches. The description is consistent 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, dense sentence with no filler. It front-loads the action and resource, then enumerates signals, then sets boundaries. Every clause adds value, and the brevity does not sacrifice clarity.

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 4 parameters with 100% schema coverage, no output schema, and simple structure, the description is complete. It covers what inputs produce, how results are categorized (matched roles, remote share, new by window), and caveats (no login/scraping needed). An agent can confidently invoke the tool without needing additional context.

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

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

Schema coverage is 100% with good descriptions for each parameter. The description goes further by explaining how these parameters combine to produce the signal, e.g., 'newWindowDays' is used to filter 'new' postings. It also clarifies the provider:token format for companies, which is essential for correct invocation. However, there is no description of default behavior when 'keywords' or 'newWindowDays' are omitted beyond schema defaults.

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 specific verbs like 'Pull every open role' and clearly identifies the resource as 'a company's public job board from Greenhouse, Lever, Ashby' with concrete signals like 'role count, which functions are growing, remote share, and what's new.' It is clearly distinguishable from siblings like 'layoff-tracker' or 'hiring-trend-index' which cover different hiring-related concepts.

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 tells the agent when to use this tool: to turn job postings into a 'buying/expansion signal.' It also states what it does NOT require ('No login, no scraping, no proxies'), which helps agents exclude this tool for scenarios requiring authentication or custom scraping. The emphasis on public job boards further clarifies when the tool is appropriate.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds value beyond these by specifying 'Keyless, no login – built for AI agents and sales' (ease of access), '$0.01/call, x402 (USDC on base)' (pricing and payment method), and 'live GLEIF registry match' (real-time data freshness). No contradictions with annotations. A small deduction for not mentioning rate limits or latency, but the added context is strong.

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 pricing note – very compact. It is front-loaded with the core purpose and then details the output. The pricing note is helpful but slightly disrupts flow; could be placed in a separate field. No fluff, every sentence adds value. A 5 would require even tighter structuring or separation of concerns, but this is 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 no output schema, the description effectively conveys what the tool returns: a 'company card' with website tech stack (CMS, ecommerce, key tech) for domains and a GLEIF registry match (legal name, jurisdiction, status, LEI). This covers the core output. The two parameters are well-documented in the schema. The description could be improved by mentioning the response format (e.g., JSON structure) but is still complete enough for an AI agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100% (both companies and maxConcurrency have descriptions in the schema). The description does not add significant new parameter-level detail beyond the schema; it mentions the pipe syntax for country hints (e.g., 'stripe.com | US') but that is already present in the schema description for companies. The description's main value is at the tool level, not per-parameter. 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 specific action: 'Turn a domain or company name into one unified company card' with two explicit output components: website tech stack and live GLEIF registry match. This uniquely distinguishes the tool from siblings like company-registry-enricher (which focuses only on registry data) or website-contact-extractor (which extracts contacts). The verb 'turn' and resource 'domain/company name' 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 mentions it is 'built for AI agents and sales' but provides no explicit guidance on when to use this tool vs. alternatives. It does not state when not to use it, nor does it reference any sibling tools. For example, it could have noted that company-registry-enricher provides deeper registry data or that counterparty-risk-rollup covers risk, but it does not. This lack of comparative guidance leaves the agent to infer usage context.

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

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

The annotations already declare readOnlyHint: true and destructiveHint: false, so no contradiction. The description adds behavioral context: it uses GLEIF (free, no key), charges $0.01/call in USDC, and optionally needs a Companies House API key for extra data. This moves beyond the annotations by disclosing the cost, third-party data sources, and optional enrichment 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 a single, dense sentence with key information front-loaded (purpose, outputs, free source) and optional details later (UK API key, cost). It is concise and wastes no words, though it could be split into two sentences for easier 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 moderately complex input (array with optional country hints, optional API key) and no output schema, the description covers inputs, optional enrichment, data source, and cost well. It lacks details on the output format or error cases (e.g., what happens if a name is not found), but the annotations and schema provide a solid foundation. Completeness is good but not exhaustive.

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

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

Schema coverage is 100%, but the description still adds meaning: it explains the pipe syntax for country hints, that LEI or UK company numbers bypass name search, and how the optional API key unlocks directors/SIC codes. This exceeds the baseline of 3 by enriching the agent's understanding of input formatting and optional features.

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 turns a company name, LEI, or UK company number into an official registry card with specific fields (legal name, status, jurisdiction, registered address, LEI). It also mentions optional enrichment with UK directors and SIC codes. This purpose is distinct from siblings like 'company-lookup' or 'taiwan-company-kyb-lookup', which likely have different scopes or geographies.

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

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

The description implies when to use the tool (for identity and registration data enrichment) and what inputs are accepted (name, LEI, UK company number). It also explains how to use the optional API key for UK data and notes a cost of $0.01/call. However, it does not explicitly state when not to use it or compare it to siblings like 'company-lookup' or 'litigation-check', leaving room for interpretation.

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: it notes that partial cards are marked and list missing signals, which is a key disclosure about output quality. It also includes pricing/call cost ($0.08/call) and payment method, which is extra transparency not in the annotations. No contradictions with readOnlyHint=false or other annotations.

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

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

The description is two sentences, front-loaded with the core purpose, followed by a concise behavioral note and pricing. Every word earns its place; there's no redundancy or fluff. It efficiently communicates the key facts an agent would need to select and invoke the tool.

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 gives enough to understand the tool's role but omits which signals are included in the rollup. Since the tool has many sibling tools for specific signals, an agent might need this to decide if this rollup covers the desired signals. With no output schema, the partial-card behavior is mentioned but not detailed. It's adequate but has 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?

Schema description coverage is 100%, and each parameter already has a rich description (e.g., domain example, baseline_key purpose, role_keywords maxItems, company_name_override heuristic warning). The tool description does not add parameter-specific meaning; it only gives high-level context. With high schema coverage, 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 produces 'one card per competitor summarising what changed across several signals in the past week.' It identifies a specific verb (summarising) and resource (competitor change rollup), distinguishing it from sibling tools that focus on individual signals. However, 'several signals' is vague and doesn't enumerate which signals, so it's not fully specific.

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 is implied: if you want a consolidated weekly summary of competitor changes, use this tool. But there is no explicit guidance on when to use it vs. alternatives like individual signal tools, nor any exclusions. The openWorldHint annotation suggests it reaches outside, but the description doesn't discuss selection criteria or trade-offs.

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, so the safety profile is covered. The description adds valuable context: it names the underlying data sources (OFAC, EU, GLEIF, US/UK/PL litigation, ATS boards), states 'Keyless sources only' (no authentication needed), and reveals pricing/call format ($0.03/call via x402). It also notes the output shape (one row per company with a documented risk score), going 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 exceptionally concise: two sentences (plus a pricing note) pack in purpose, sources, output shape, keyless requirement, and cost. Every clause earns its place, with front-loaded action ('Screen a counterparty in one call') and no filler. Ideal length 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?

The description provides enough context for an agent to decide when and how to call: it names all four checks, notes output structure (one row per company, risk score), and gives critical operational constraints (keyless, x402 payment). However, with no output schema, it could be more explicit about the returned risk-score scale or row format, and it leaves out any mention of concurrency limits or error handling, though these are partially covered in the input schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics; it only restates the high-level checks, which are already detailed in the 'checks' parameter description. The schema already explains companies, maxConcurrency, and jurisdictionHint thoroughly, and the description adds no extra parameter-level guidance.

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 ('Screen') with a clear resource ('a counterparty') and explicitly lists the distinct checks (OFAC/EU sanctions, GLEIF registry, litigation history, hiring signal) combined into one row with a risk score. It clearly differentiates from sibling tools like sanctions-screening or litigation-check by emphasizing the single-call rollup nature.

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

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

The description gives clear context: use this for a consolidated counterparty screening in one call, with keyless sources. It implies when to use it instead of individual sibling tools, but it does not explicitly state exclusions (e.g., 'if you only need sanctions, use sanctions-screening'). The context is sufficient for an agent to infer appropriate usage.

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 goes beyond the annotations (readOnlyHint, openWorldHint, destructiveHint) by disclosing a crucial behavioral trait: when mailbox-level existence cannot be established, the field is null rather than a guess. This is a valuable reliability statement. It also discloses the exact cost and payment method ($0.02/call, x402 USDC on base), which is practical contextual information. 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?

The description is compact: one leading sentence defining the core function, one sentence on the null-behavior policy, and one short pricing note. Every sentence provides distinct, useful information. It is front-loaded and wastes no words.

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

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

For a tool with two parameters and no output schema, the description covers the essential behavior, the honesty policy around null results, and the cost. It lacks explicit mention of output structure or error handling, but the null-field hint gives some indication of the return format. Given the tool's simplicity, this is a high level of completeness, but not a perfect 5.

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%; both parameters have descriptions. The description supplements the 'emails' parameter by explaining what verification means (syntax, domain, MX), giving semantic depth beyond the generic 'Email addresses to verify.' The 'maxConcurrency' parameter is fully described in the schema and needs no further elaboration. Overall, the description adds meaningful semantic context for the primary 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 explicitly starts with 'Checks email addresses' and enumerates the specific checks: syntax, domain, and mail exchangers (MX records). This is a specific verb+resource combination that clearly distinguishes it from the sibling tools, all of which are company-related rather than email-focused. The null-behavior statement further clarifies the scope.

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

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

The description implies the tool should be used for email verification by stating exactly what it does. There are no close sibling alternatives, so exclusions are unnecessary. However, it does not explicitly state 'use this when you need to verify email addresses' or provide when-not-to-use guidance. Given the context and lack of competing tools, the usage context is clear, earning a 4.

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 stateful behavior (baseline creation, only returning changes) and cost details ($0.05/call, x402/USDC on base), which go beyond the annotations. The annotations already indicate non-read-only and non-destructive, and the description adds useful context about the tool's operational characteristics.

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 sentences plus a brief cost note—and every element adds value. It front-loads the core purpose and key behavioral detail while keeping the text minimal and focused.

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 schema richness, and the annotations, the description covers the essential purpose and behavior. The main gap is that it does not describe the output format (since there is no output schema), but the core usage and stateful aspects are sufficiently explained for an agent to select and use 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 input schema provides 100% coverage with detailed descriptions for all parameters, including the filtering and baseline semantics. The description does not add parameter-specific meaning beyond what the schema already explains, so 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 uses a specific verb ('Watches') and clearly defines the tool's unique behavior: monitoring funding announcements for a saved filter and returning only changed results since the previous check. This distinguishes it from sibling tools like funding-round-tracker, which likely tracks all announcements rather than just deltas.

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 intended use case—monitoring for new or changed funding announcements—and explains the first-run baseline behavior. However, it does not explicitly state when to prefer this tool over alternatives such as funding-round-tracker, nor does it provide any exclusion criteria.

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 mark the tool as read-only and non-destructive. The description adds value by disclosing it uses official SEC EDGAR full-text search, is free, and includes a per-call cost ($0.02). It does not contradict annotations and provides useful behavioral context beyond the structured fields.

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 concise sentences plus pricing information. It front-loads the core purpose, sources, and outputs, with no wasted words. Every sentence serves a distinct purpose, making it easy for an agent to quickly understand the tool.

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

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

Given no output schema, the description adequately explains return values (company, filing date, document URL). It covers all four parameters via schema descriptions and contextualizes the queries. Minor gaps exist (e.g., no mention of pagination or empty result behavior), but the tool is simple enough that this is 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 coverage is 100%, so the description does not need to repeat parameter details. It adds meaning by linking the 'queries' parameter to company names or sector keywords and clarifying outputs (company, filing date, document URL) in the absence of an output schema. This contextualizes the parameters without redundancy.

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 tracks SEC Form D filings by company name or sector keyword. It specifies the data source (SEC EDGAR), the outputs (company, filing date, document URL), and distinguishes itself from a sibling like 'funding-alert' by focusing on regulatory filings rather than general funding news.

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

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

The description provides context on when to use this tool (tracking recent private capital raises via Form D) and highlights its free, no-login nature. However, it does not explicitly contrast with sibling tools like 'funding-alert' or state when not to use it, leaving some ambiguity for the agent.

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 that partial results are marked partial and list what is missing, which is a useful behavioral trait beyond the annotations. However, it does not mention that the tool stores watch state and tracks changes over time, which is a side effect implied by readOnlyHint=false and explained only in the parameter schema. 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 two sentences plus cost info, with no filler. It front-loads the core purpose and a key behavioral note, and every word adds value. Structure is clean and immediately scannable.

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

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

For a tool with three parameters and no output schema, the description gives a serviceable overview but omits the tool's change-tracking behavior and the two slice types, both of which are covered in the schema. The reliance on schema details is acceptable, but the description alone would leave an agent without a full picture of statefulness and integration with company-hiring-radar.

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 each parameter (especially 'slices') has detailed descriptions covering format, examples, and behavior. The tool description adds no parameter-level meaning beyond what the schema already provides, so 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 clearly identifies the tool as providing a cross-section of hiring demand by role and geography, assembled from multiple job sources in one call. This gives a specific resource and scope, though it lacks an explicit verb like 'get' or 'retrieve'. It also implies differentiation from siblings by emphasizing the multi-source aggregation, but does not name an alternative.

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

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

The description implies when to use the tool ('in one call' suggests an aggregate view), but provides no explicit guidance on when to prefer this over sibling tools like company-hiring-radar. There are no exclusions or alternative recommendations, leaving usage context to be inferred from the multi-source framing.

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, covering the safety profile. The description adds value by disclosing pricing ($0.01/call), the lack of authentication requirements, and the data sources used. This helps the agent understand cost and access prerequisites beyond what annotations provide.

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

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

The description is extremely concise, using two sentences and a pricing line to convey purpose, data sources, and ease of use. It is front-loaded with a question that hooks the use case, and every sentence adds essential information 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?

Given the tool has no output schema, the description should clarify the return format. It mentions an 'intent score per company' but does not specify whether it's a number, label, or structured object. For a simple tool with 2 parameters and no nested objects, the description is somewhat complete but lacks output details needed for an agent to interpret results.

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

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

Schema description coverage is 100%, with both parameters (companies and maxConcurrency) already well-documented in the schema (e.g., company format options, concurrency limits). The description does not add new meaning or additional usage details for the parameters, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: it computes an intent score by combining public hiring activity and recent news for a company, mentioning specific sources (Greenhouse, Lever, Ashby) and news categories. However, it does not explicitly differentiate from sibling tools like company-hiring-radar or funding-alert, which could provide individual signals.

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 assessing market intent ('Is this company in-market right now?') and emphasizes ease of use (no login, no API keys), but it does not provide explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions or when-not-to-use, leaving the agent to infer context from the tool's name and siblings.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: 'No login, no scraping, no proxies,' cost ($0.01/call), and return format (headlines, mention count, summary). It goes beyond annotations without contradicting them, though rate limits or update frequency could add more depth.

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 at roughly three sentences, front-loading the core purpose and resource. It includes necessary details without excess, though the cost and payment info, while transparent, could be seen as slightly tangential to tool selection. Still, it's efficient and well-structured.

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

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

For a simple three-parameter tool with no output schema, the description covers the main aspects: purpose, source, output format, cost, and lack of authentication requirements. Missing details like example output or error scenarios are minor given the low complexity. The description adequately complements annotations and schema.

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

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

Schema coverage is 100% with each parameter having a clear description. The tool description restates some parameter info but does not add new semantic meaning beyond what is already in the schema. Baseline 3 is appropriate since the schema already does the heavy lifting.

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

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

The description clearly states it tracks recent tech layoffs by company or sector from Google News, with a specific purpose as a demand and recruiting signal. This distinctively separates it from sibling tools like hiring-trend-index or company-hiring-radar, which focus on positive hiring signals.

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 for layoff-related signal gathering but does not explicitly state when to use this tool versus alternatives or when not to use it. No direct comparisons to sibling tools are provided, so the agent must infer the context from the tool's 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?

The description adds transparency beyond the annotations by disclosing that identity confidence is reported as 'guessed' when no override is supplied, and it also states pricing and payment method. There is no contradiction with the annotations; the tool is correctly marked as not read-only and not destructive.

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

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

The description is two sentences plus a pricing phrase, front-loading the core function and including only a key behavioral caveat and cost. Every sentence earns its place and there is 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?

The description provides the essential 'what' and a critical behavioral nuance (identity guessing) while the rich schema handles parameter details. It could have mentioned the parallel checks or the 25-cap explicitly for full completeness, but those are present in the schema, making the description 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?

The input schema already provides 100% coverage with detailed descriptions for all three parameters, including the company_name_overrides field. The main description only adds a brief hint about the override's effect, so it does not add significant meaning beyond the schema 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 the tool's function with a specific verb ('Scores') and resource ('domains for buying readiness'), and 'from several of our own signal sources in one call' distinguishes it from single-signal lookups. It is immediately clear 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 phrase 'in one call' implies this is an aggregation tool for scoring multiple signals efficiently, providing a buying-readiness score. However, no explicit alternatives, when-not-to-use instructions, or exclusions are given, so the guidance is only 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?

The description goes beyond the readOnly/openWorld annotations by disclosing that the operation is keyless, produces one row per company x jurisdiction, includes true case counts and source links, and carries a $0.03/call cost. It does not mention rate limits or error handling, but the annotations already cover safety, so this is sufficient.

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 short sentences, front-loaded with the core purpose, and each additional sentence supplies actionable details (keyless access, output shape, cost). There is no filler or repetition.

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 moderately complex I/O profile, but the description covers the purpose, jurisdictions, output format, security model, and pricing. Since the schema already documents all four parameters and annotations cover safety, the description provides sufficient context for a caller to understand what will happen, including the one-row-per-company-jurisdiction behavior.

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

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

All four parameters are fully described in the schema (100% coverage), so the description needs no additional parameter details. The description's 'one row per company x jurisdiction' mirrors the schema's explanation for the companies parameter, adding no new semantic value beyond what the schema already provides.

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 ('Screen') and a specific resource ('a company for litigation history') and names three concrete jurisdictions (US federal dockets, UK case law, Polish judgments), which clearly distinguishes it from sibling tools like sanctions-screening. It also notes output structure (one row per company x jurisdiction) and keyless access, leaving no ambiguity about what the tool does.

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

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

While it doesn't name alternative tools explicitly, the description gives clear context that this tool is for litigation-history screening across specific jurisdictions, which implies it's not for sanctions checks or general company lookups. The inclusion of jurisdictions and court types makes the applicable use case obvious, but it lacks explicit when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds valuable context: it is a public data scraper ('no API key, no login, no proxies'), and mentions cost ($0.02/call). No contradictions are present, and the description reinforces the safe, read-only nature.

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 sentences) with no wasted words. Every sentence provides essential information: purpose, source, time window, constraints, and cost. Highly 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 low complexity of this tool (3 parameters, no output schema, safe annotations), the description covers the most important aspects: what it does, where it gets data, cost, and limitations. It does not explain the return format, but with no output schema, the agent might need to infer structure. Still, for a simple search tool, this is 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 coverage is 100%, so baseline is 3. The description does not add much beyond the schema: it mentions keyword and time window but doesn't elaborate on parameter formatting or behavior beyond what the schema already specifies. No significant added value for 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 finds newly-incorporated UK companies matching a keyword. It specifies the data source (Companies House), the time window (last ~60 days by default), and key constraints (no API key needed). This clearly distinguishes it from siblings like company-hiring-radar or company-lookup which have different scopes.

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: it is for finding recent UK companies via keyword, with no authentication needed. It does not explicitly state when not to use it or name alternatives, but the behavior is well-defined enough that the agent can infer appropriate use cases (e.g., not for non-UK companies or old registrations).

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 value beyond these by disclosing cost ($0.02/call), payment method (x402 USDC), data source (PatentsView API, USPTO-backed), and the need for an API key. 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?

The description is three sentences, front-loaded with the core purpose. It includes relevant details (API key, output fields, cost) but the pricing and payment method could be considered extraneous for core functionality. Minimal waste, but not perfectly concise.

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?

There is no output schema, so the description should clarify the return structure. It lists fields but does not specify the format (e.g., array of objects) or mention pagination, error handling, or rate limits. Adequate but not fully complete given the lack of an output schema.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds marginal value by mentioning the Google Patents link in output, but does not add new meaning to the parameters beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool watches keywords for newly granted US patents, lists specific fields returned (patent id, title, grant date, assignee, Google Patents link), and is distinct from all sibling tools (none are patent-specific). This meets the 'specific verb+resource, distinguishes from siblings' criterion.

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 for patent monitoring by keywords, but it does not explicitly state when to use this tool versus alternatives (e.g., other alert tools). There are no sibling patent tools, so the context is implicit, but no exclusions or when-not-to-use guidance is provided.

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:true, destructiveHint:false, and openWorldHint:false, so the safety profile is clear. The description adds behavioral context by indicating that the tool is free (overriding a potential assumption that pricing tools incur costs), and by specifying it lists pricing for paid tools—implying it discloses what remains proprietary. However, it does not describe what happens if no paid tools exist in the bundle or whether the response is a list or single object; these are minor gaps given the tool's simplicity.

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

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

The description is a single sentence of 20 words, front-loading the most important information ('Free') and then immediately stating the action and output. Every word earns its place with no fluff or repetition. It is highly efficient while being complete.

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 no parameters, no output schema, and a simple purpose, the description covers the essential facts: what data it returns (prices, payTo, network), for which bundle (company-intel), and how it relates to the user's wallet readiness. A minor gap is that it does not explain whether the tool lists all paid tools once or can be filtered, but with zero params, the expectation is low. It is complete enough for an agent to correctly invoke this 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 tool has zero parameters and schema description coverage is 100% (empty schema). The description adds value beyond the schema by clarifying that the pricing is specifically for the 'company-intel' bundle, which is not stated in the structured input. It also mentions the details returned: price, payTo address, and network. This effectively compensates for the lack of 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 starts with 'Free' to quickly communicate the cost, then specifies the action 'list every paid tool in the 'company-intel' bundle with its price, payTo address and network.' This clearly describes what the tool does (lists pricing info) and what resource it operates on (the company-intel bundle). It also distinguishes itself from siblings by being the only tool dedicated to pricing; other tools like company-lookup or funding-alert serve 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 explicitly advises the agent to 'Call this first if you don't have a wallet ready yet.' This gives clear when-to-use guidance, implying that the tool is useful for discovery before payment actions. It also contrasts with sibling tools that require a wallet or other setup, effectively guiding the agent's decision-making.

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, and destructiveHint=false. The description adds valuable behavioral traits beyond annotations: 'Keyless, no login' (authentication model), 'live' lists (real-time nature), 'match score' (result granularity), and pricing ($0.01/call, x402 USDC). It does not contradict annotations and enriches the agent's understanding of side effects and constraints.

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, each earning its place: first sentence for core action, second for access and purpose, third for pricing. It is front-loaded with the primary verb and resource, uses no filler, and is immediately scannable. Perfectly sized for the tool's simplicity.

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 no output schema, so the description should compensate by outlining the return format. It mentions 'flags potential hits with a match score' but does not specify the structure (e.g., list of matched names, scores, match details). For a screening tool, an agent would benefit from knowing what to expect in the response. Given the moderate complexity and well-covered parameters, the description is adequate but not fully complete.

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

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

The input schema has 100% description coverage, with each parameter (names, minScore, maxConcurrency) already well-documented. The description adds high-level context ('live lists,' 'match score') but does not provide additional parameter-specific details beyond what the schema offers. The baseline of 3 is appropriate, as the description adds marginal value to parameter semantics.

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

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

The description clearly states the action ('Screen names'), the resource ('live OFAC SDN and EU consolidated sanctions lists'), and the outcome ('flags potential hits with a match score'). It distinguishes itself from sibling tools like 'sanctions-update-alert' and 'litigation-check' by focusing on live screening for onboarding, 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 explicitly mentions a use case: 'before onboarding a client or counterparty,' which guides when to use the tool. However, it does not explicitly state when not to use it or point to alternatives (e.g., 'sanctions-update-alert' for updates). The context is clear enough for an agent to infer appropriate usage, but lacks direct exclusion cues.

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?

Beyond annotations (readOnlyHint=false), the description discloses cost ($0.05/call), payment method (USDC on base), the baseline behavior on first run, and the focus on changed statuses. This adds meaningful behavioral context, though it does not detail how the baseline is stored or retained.

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 pricing note, perfectly front-loaded with the core function. Every phrase adds value, and no words are wasted.

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 moderate-complexity tool, the description plus schema covers the essential behavior: what it checks, what it returns, baseline semantics, and cost. The lack of an output schema is mitigated by the explicit statement that only changed entries are returned, though the exact response format is 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?

Schema coverage is 100% with detailed descriptions for all four parameters, so the schema already carries the semantic burden. The description adds context about the baseline but does not materially expand parameter meaning 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's specific function: re-screening a saved watchlist against sanctions lists and returning only status changes. This distinguishes it from the sibling 'sanctions-screening' tool, which presumably performs initial full screening.

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 conveys clear usage context: it is for repeated checks against the same watchlist, with the first run creating a baseline. However, it does not explicitly name alternatives or say 'use sanctions-screening for initial screening,' so it stops short of full 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?

The description discloses the monetary side effect (billed only for complete unambiguous results) and the free outcomes, which is behavioral context beyond the sparse annotations. It also names the official keyless open-data source. No contradiction with annotations; the readOnlyHint=false is consistent with the charging 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 composed of two concise sentences and a price tag, each carrying necessary information: purpose, source, billing conditions, and cost. No fluff or redundancy; fully front-loaded.

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 purpose, data source, and commercial terms, while the schema thoroughly documents all parameters. However, there is no output schema and the description does not detail what an 'evidence-backed KYB card' contains, leaving a minor gap in expected return semantics. Still sufficient for its narrow scope.

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

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

Schema coverage is 100% with rich descriptions for each parameter (Unified Business Number pattern, legal-name length, includeBoard default, maxConcurrency behavior). The description only mentions the two identifiers at a high level, adding no additional semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb ('Resolve') and an explicit resource ('Taiwan companies') using either identifier (統一編號 or legal name), clearly producing an 'evidence-backed KYB card' from a named official registry. This distinguishes it from sibling tools like generic 'company-lookup' by being Taiwan-specific and KYB-focused.

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

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

The description sets clear context for Taiwan-company KYB lookup via the MOEA GCIS registry and explains when billing applies (free for structural checks, not-found/ambiguous/error; billed only for a complete card). It does not explicitly name alternatives or exclusions, but the niche is well defined.

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 non-destructive behavior. The description adds meaningful behavioral context beyond that: the honesty check that flags third-party/placeholder addresses rather than presenting them as the company's own, plus pricing details. This provides transparency into how the tool handles potentially misleading data.

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

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

The description is a single, well-structured sentence that front-loads the core function ('Extract public contacts...') and appends the differentiator and pricing in a logical dash-separated clause. No wasted words—every element earns its place.

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

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

With 4 parameters and no output schema, the description covers the essential purpose and a key behavioral trait (honesty check). It does not explicitly describe the output structure, but the phrase 'flags third-party/placeholder addresses' implies output includes contact entries with flags. Given the rich schema descriptions, the description is sufficiently complete for practical use, though it could mention return format or limits.

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

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

The input schema has 100% parameter description coverage, thoroughly explaining domains, checkPages, maxConcurrency, and maxPagesPerDomain. The tool description itself adds no parameter-specific semantics; it only restates the overall purpose. Since the schema carries the burden, the baseline of 3 applies.

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

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

The description states a specific verb ('Extract') and resource ('public contacts a company posted on its own site: email, phone, social links'). It also conveys a key differentiator (the honesty check) that separates it from sibling tools like email-verifier or company-lookup.

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 a use case (finding contacts a company publicly posted on its own site) but does not explicitly explain when to prefer this tool over alternatives, nor does it state exclusions. There is context but no direct alternative comparison or when-not-to-use guidance.

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