Company Intel

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 known. The description adds valuable behavioral details beyond annotations: 'No login, no scraping, no proxies' and the cost of '$0.01/call', which helps an agent understand operational constraints. 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, with the first sentence packed with essential info (what it does, sources, outputs) and the second adding cost and limitations. Every word earns its place, and it is front-loaded with the core purpose.

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

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

There is no output schema, so the description must explain return values. It lists key output metrics (role count, growing functions, remote share, what's new) and mentions cost and no-auth requirements. This is sufficient for a moderate-complexity read-only tool, though it could detail response structure more.

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 any extra meaning about parameters beyond the schema; it focuses on outputs and benefits. This is adequate as the schema's parameter descriptions are already thorough.

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: pulling every open role from a company's public job board (Greenhouse, Lever, Ashby) and converting it into hiring signals such as role count, growing functions, remote share, and new roles. This specific verb+resource phrasing distinguishes it from sibling tools like hiring-trend-index 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 provides clear context for use: 'turn it into a buying/expansion signal' indicates this is for assessing company growth via hiring. It does not explicitly name alternatives or when-not-to-use, but the scope is well-defined, so it earns 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?

Annotations already declare read-only, non-destructive behavior. The description adds valuable context beyond that: no login required, $0.01/call cost, and the live GLEIF registry match. This informs the agent about authentication, cost, and real-time data aspects, though it does not discuss rate limits or pagination.

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 remarkably concise: two sentences covering core functionality and key operational attributes (keyless, pricing). Every clause earns its place, with the most important information front-loaded. No fluff or 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 tool with only two parameters and no output schema, the description adequately explains what the output contains (tech stack for domains, GLEIF legal name/jurisdiction/status/LEI) and the operational context (keyless, cost). It does not describe return format or error handling, but the description covers the essential 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?

The input schema already provides rich descriptions for both parameters, including country hint syntax and LEI behavior. The description adds no new parameter-specific details beyond a high-level summary, so the baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool's function: converting a domain or company name into a unified company card with tech stack and GLEIF registry data. It uses a specific verb ('turn into') and names the resource (domain/company name) and output components, effectively distinguishing it from sibling tools that focus on individual data points.

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 by stating it is 'built for AI agents and sales' and highlights its keyless, low-cost nature, which suggests when it is appropriate. However, it does not explicitly name alternative tools for cases where one only needs, say, registry data or tech stack separately, so it lacks explicit exclusion 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 and destructiveHint=false. The description adds valuable behavioral context beyond this by disclosing pricing ($0.01/call), payment method (x402 on base), and the free/no-key nature of GLEIF data, plus the optional API key requirement. 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, with two sentences plus a pricing note. It front-loads the core value proposition and includes only essential details, making it easy to parse quickly. Every sentence earns its place.

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

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

Given the tool's moderate complexity (3 params, 1 required, no output schema) and rich annotations, the description covers key aspects: input types, optional enrichment, pricing, and auth needs. It is complete enough for an agent to use it correctly, though it could mention limits (e.g., 100 max) which are in the schema but not the description.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself mentions the accepted identifier formats and the optional Companies House key, but the schema already provides detailed parameter descriptions (e.g., pipe syntax for country hints). The description adds little beyond what the schema already communicates.

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, listing the specific output fields (legal name, status, jurisdiction, registered address, LEI). It also distinguishes itself from siblings by naming GLEIF and options UK Companies House enrichment, making its purpose unmistakable.

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 for when to use the tool: for official registry data via GLEIF with no key, and optionally for UK directors/SIC codes with a Companies House key. It does not explicitly exclude alternatives (e.g., company-lookup) or state 'use when...', but the context is sufficiently clear for an agent to select it appropriately.

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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable context beyond these: it names the official data source (SEC EDGAR), notes there is no login requirement, and specifies the returned fields. No contradiction with annotations exists, and the additional behavior is appropriately disclosed.

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

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

The description is concise and front-loaded with the core action. Each sentence serves a purpose: the first explains what it tracks, the second emphasizes the official source and low friction, the third lists outputs, and the final provides cost/payment. Though the pricing fragment is somewhat tangential, it is brief and does not bloat the description.

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 no output schema, the description sufficiently explains return values ('company, filing date and a direct document URL for every match'). Parameters are fully covered by the input schema. The tool is simple and read-only, and the description plus annotations provide adequate context for an agent to select and invoke it correctly. Minor gaps like error handling or no-results behavior are not critical.

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 reinforces the queries parameter semantics with 'by company name or sector keyword', but this largely duplicates the schema description already present. It adds no extra meaning for limit, sinceDays, or maxConcurrency, which are all well-documented in 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 opens with a specific verb ('Track') and a precise resource ('recent SEC Form D filings') scoped by 'company name or sector keyword'. It also distinguishes itself from siblings by specifying 'Official SEC EDGAR full-text search' and the exact output (company, filing date, document URL), making its purpose unmistakable.

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 for when to use this tool: when tracking recent Form D filings by company or sector. It states it is free and requires no API key or login, which sets expectations. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.

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

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

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 read-only/non-destructive behavior. The description adds meaningful context beyond annotations: no authentication, no API keys or proxies, $0.01/call, x402 (USDC on base), and data sources (Greenhouse, Lever, Ashby, news). It does not detail output format or error handling, but the added cost and access information is substantial.

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: one sentence with a compelling question and a clear statement of function, followed by cost/access details. No superfluous words; every line 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?

Given the absence of an output schema, the description partly explains return values ('one intent score per company'), which is a useful minimum. It also covers data sources, pricing, and examples through schema prefill. It could further specify score range or additional returned metadata, but the core is adequately complete for a read-only aggregator tool.

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

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

Schema description coverage is 100%, with detailed parameter descriptions for 'companies' and 'maxConcurrency'. The tool description adds no additional parameter meaning beyond the schema, 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 states the tool's function: combines public hiring and news signals into one intent score per company. It uses a specific verb ('combines') and resource ('public hiring activity, recent news') and answers the question 'Is this company in-market right now?' This distinguishes it from sibling tools that focus on single 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 gives a clear use case (assessing if a company is in-market) and mentions practical constraints ('No login, no API keys, no proxies'), but it does not explicitly list alternatives or when not to use the tool. The combination framing implies it is for use when both hiring and news signals are needed, but without explicit 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?

Beyond the readOnlyHint/destructiveHint annotations, the description adds that no login, scraping, or proxies are needed, discloses the return format (headlines, count, summary), and mentions the per-call cost. This is rich behavioral context.

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

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

The description is two sentences that efficiently pack purpose, source, behavioral constraints, return shape, and pricing 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?

With no output schema, the description does well to name the returned data (headlines, count, summary). It could mention potential edge cases or limits, but for a simple read-only tool, it's largely 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?

Input schema already documents all three parameters at 100% coverage, so the description need not re-explain them. It adds marginal context by mentioning company/sector searches, but does not elaborate on sinceDays or maxConcurrency 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 tracks recent tech layoffs by company or sector, sourced from Google News, and positions it as a demand/recruiting signal. This distinguishes it from sibling tools covering hiring, funding, and company data.

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

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

It provides clear usage context ('demand and recruiting signal') and operational benefits (no login/scraping/proxies), but does not explicitly compare to sibling tools or state when not to use it.

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 and schema go well beyond the readOnlyHint annotation, disclosing keyless access, cost per call, output row structure, true case count behavior, approximate count limits, unsupported-jurisdiction handling, and concurrency behavior. No contradiction with annotations exists; the rich behavioral details compensate for any ambiguity.

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 and front-loaded: the first sentence states the core function, the second adds output granularity and data authenticity, and the final clause covers access and pricing. Every clause carries meaningful 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?

The combination of description and schema provides a thorough picture: output structure (one row per company × jurisdiction), core fields (count and links), budget skipping behavior, unsupported jurisdiction handling, and concurrency semantics. Although no output schema exists, the prose is sufficient for a moderately complex tool; a small gap is the lack of explicit field names in the main description, but schema descriptions fill this.

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 (companies, jurisdictions, maxCasesPerRow, maxConcurrency) having detailed semantic descriptions. The main description does not add parameter-specific meaning beyond what the schema already provides, 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 immediately identifies the tool's purpose: screening a company for litigation history across US federal dockets, UK case law, and Polish court judgments. It distinguishes itself from sibling tools like sanctions-screening or counterparty-risk-rollup by specifying the exact legal jurisdictions and output behavior (one row per company × jurisdiction with counts and links).

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 clearly implies the use case—screening litigation history—but never explicitly states when to choose this tool over alternatives like sanctions-screening or counterparty-risk-rollup. The schema hint about unsupported jurisdictions provides some exclusion context, but there is no direct guidance on alternatives or when not to use it.

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, but the description adds useful behavioral context: it reads from public advanced-search results, targets active companies, defaults to a 60-day window, and includes cost/payment details ($0.02/call, x402 USDC). This goes beyond the annotations and helps the agent understand side-effect-free access and potential rate/cost implications.

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, and includes only essential details (data source, defaults, access constraints, pricing). Every sentence adds value, with no redundancy or fluff. It is highly scannable for an AI agent.

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

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

With 100% schema coverage and default values for windowDays (60) and maxConcurrency (5), the description provides enough context for invocation. However, since there is no output schema, a brief mention of the expected return format (e.g., company records with name, incorporation date) would improve completeness. Still, the description covers the essential inputs and access constraints, making it adequate for selection and basic usage.

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, with each parameter (items, windowDays, maxConcurrency) clearly explained. The description does not add significant new parameter semantics beyond the schema, but it provides context about the default window ('~60 days') and the data source, which slightly enriches understanding. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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

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

The description clearly states the tool's purpose: 'Find newly-incorporated UK companies matching a keyword' with a specific data source (Companies House public advanced-search) and a specific scope (active companies, ~60 days). This distinguishes it from sibling tools like company-lookup or company-registry-enricher by focusing on new incorporation detection.

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

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

The description implies when to use the tool (when you need newly incorporated UK companies matching keywords) and mentions that it requires no API key, login, or proxies, which sets expectations for access. It does not explicitly contrast with alternatives, but the scope is clear enough for an agent to select it appropriately among siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context: it invokes an external API, explains the optional API key (sent only in X-Api-Key header, never logged), and indicates results are sorted by most recent. No contradiction with annotations. The additional source and pricing details go beyond the structured metadata.

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 paragraph of about 70 words, front-loaded with the core purpose and followed by essential details (data fields, source, pricing). Every sentence carries useful information with no filler or 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 there is no output schema, the description compensates by listing the exact data fields returned (patent id, title, grant date, assignee, Google Patents link) and the sorting order. It also explains the two data sources and pricing. This is nearly complete for a monitoring tool, though it omits details like pagination limits or error handling, which are not critical for initial selection.

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 has a clear description (e.g., limit, queries, sinceDays, maxConcurrency, patentsviewApiKey). The description reinforces the API key behavior but does not add significant new parameter-level meaning beyond the schema. 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's function: 'Watch keywords or technologies for newly granted US patents.' It specifies the resource (US patents), the action (monitoring), and the output (patent id, title, grant date, assignee, Google Patents link). This distinguishes it from sibling tools like funding-alert or layoff-tracker, which serve different monitoring domains.

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

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

The description provides context for when to use the tool and even guides on source selection: 'Bring your own free PatentsView API key' for the official USPTO-backed source versus 'keyless Google Patents source' for worldwide coverage. It does not explicitly name alternatives or exclusions, but the patent-specific purpose and source guidance make usage clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description complements this by adding 'Free' and noting the tool returns price, payTo address, and network. It also implies that no wallet is required, which is useful behavioral guidance beyond the annotations.

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

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

The description is exactly two sentences, with the primary function front-loaded ('Free — list every paid tool...'). The second sentence offers actionable usage advice. Every word serves a purpose, making it highly 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?

For a parameterless, read-only pricing tool, the description is complete: it states the scope ('company-intel' bundle), the exact output fields (price, payTo address, network), and the recommended invocation order. No output schema is needed because the description explicitly lists what the tool returns.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. With no parameters to document, the description appropriately focuses on output fields (price, payTo address, network) rather than inputs, warranting the baseline 4 for zero-parameter tools.

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 ('list') and identifies the exact resource ('every paid tool in the 'company-intel' bundle'). It clearly distinguishes from sibling intelligence tools by focusing on pricing and payment details rather than data 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 explicitly instructs 'Call this first if you don't have a wallet ready yet,' providing clear context for when to use the tool. It does not explicitly name alternatives, but among the sibling tools, this is the only pricing-related tool, so the guidance is sufficient.

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

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

Beyond the annotations (readOnly/int/destructive), the description adds meaningful behavioral details: keyless no-login access, match-score output, and cost per call ($0.01/call, x402). It also notes 'live' lists, giving the agent a good sense of what to expect without contradicting 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: the first sentence states the core action, the second adds key differentiators (keyless, match score, use case), and the final clause gives pricing. Every sentence earns its place with no wasted words.

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

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

With no output schema, the description provides a high-level understanding of return behavior ('flags potential hits with a match score') and the use case. It covers cost and auth, but could be slightly richer on response structure or error handling. For a simple screening tool, this is 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 coverage is 100%, so baseline is 3. The description adds marginal value by mentioning 'match score' in relation to screening, but does not elabor further on minScore or maxConcurrency semantics. It relies on the schema for parameter details, which is acceptable.

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

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

The description clearly states a specific verb ('Screen') and resource ('live OFAC SDN and EU consolidated sanctions lists'), and distinguishes this from sibling tools like sanctions-update-alert by focusing on name screening. The use case of 'before onboarding a client or counterparty' further clarifies its 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?

The description provides clear context for when to use the tool ('before onboarding a client or counterparty') and notes keyless access, but does not explicitly mention when not to use it or name alternatives. This aligns with 'clear context, no 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?

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.