Company Facts

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and idempotency profile is fully covered. The description adds only the return-field list (name, developer, price, rating, version, genres, link) and says nothing about rate limits, quotas, or partial-failure behavior when some ids fail — acceptable given annotation coverage but not rich.

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

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

Two tight sentences with the capabilities front-loaded and the return shape second — nothing wasted. Slightly dense mode enumeration, but each clause carries a distinct mode so it earns its space.

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 an 11-parameter, zero-required tool with no output schema, the description covers both the operation set and the response fields an agent would need to plan a call. Defaults, enum-like values and limits live in the schema, so the only gap is behavioral edge cases, which the annotations largely carry.

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 every parameter already documents its semantics (mode defaults, up-to-50 ids, page 1-10, chart types, country codes). The description only echoes 'per country' and 'by id or bundle id'; it adds no syntax or format detail beyond the schema, so the baseline 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?

Names a specific resource (Apple App Store) and enumerates the four distinct operations it supports: search, id/bundle-id lookup, reviews, and top charts per country. It also lists the returned fields, so an agent knows exactly what capability it is selecting without opening the schema.

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 enumeration of modes ('search... look apps up by id or bundle id, read customer reviews, or get the top free, paid and grossing charts, per country') implicitly routes the agent to the right mode, and the schema's mode param spells out the defaults. No sibling tools compete — the other 16 tools are unrelated (email, domain, SEC), so no exclusions are needed.

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 cover read-only, idempotent, non-destructive and open-world behavior, so the bar is lower; the description still adds real value by disclosing the key limitation that the mailbox is never contacted, meaning a nonexistent mailbox at a valid domain still passes, and that the response reports this. It does not mention rate limits, lookup failures, or timeouts, which keeps it short of a 5.

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

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

Two sentences with no filler: the first front-loads the decision framing and the check list, the second immediately qualifies what a 'pass' means. Every clause 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?

There is no output schema, so the description bears some responsibility for signaling return content, and it does so by naming the check categories and noting that the answer discloses the mailbox-not-contacted caveat. It stops short of describing the response shape (e.g., per-check fields or overall verdict format).

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

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

Schema description coverage is 100% and the single parameter is fully typed and required, so the schema carries parameter meaning. The description adds no syntax examples, format constraints, or edge-case handling (e.g., how malformed input is reported), so the baseline 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 names the exact resource (an email address) and enumerates the specific checks performed: syntax, domain existence and mail servers, throwaway/role/free-provider classification. An agent knows precisely what the tool returns a verdict on, and no sibling tool (company/job/page tools) overlaps with this 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 framing question 'Is this address worth sending to' implies the use case (pre-send deliverability triage), but there is no explicit when-to-use/when-not statement and no named alternative. Usage is inferable rather than stated, and there are no sibling tools that would need routing away from.

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 readOnly/idempotent/openWorld, so the safety bar is low, and the description adds genuinely non-obvious behavior: every part is attributed to its source and empty parts explain themselves (partial-result semantics). It doesn't hint at cost or latency, which matters for a multi-source aggregation call.

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

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

Three tight sentences, front-loaded with the core promise and followed by the optional-input conditions and the result contract. No filler and no repetition of the tool name.

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?

No output schema exists, and the description does most of the work by naming the sections returned and how empty sections are reported. What's missing is any sense of result shape/size or whether parts can be selectively requested, which for a broad aggregation tool would help an agent decide whether to call it or a narrower sibling.

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 explains that name+country unlocks the register and ticker unlocks SEC revenue. The description restates those couplings without adding format, fallback, or precedence rules (e.g. what happens if name/country combination is invalid). Baseline 3 is right.

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?

States a specific verb+resource+scope: everything public about one company, keyed off its domain, and enumerates the returned parts (registrar, DNS, email provider, tech stack, hiring with roles/salary/timing). The enumeration is what distinguishes it from its many narrow siblings like domain_lookup, detect_tech_stack, and list_open_jobs — it is the aggregate view.

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?

"Add name and country for the official register entry, or ticker for SEC figures" gives useful enrichment conditions, but there is no guidance on when to call this versus siblings — notably company_search for when you don't already have a domain, or the narrower tools when only one part is needed. Usage is implied, not stated.

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 cover read-only, idempotent, open-world and non-destructive, so the bar is lower. The description adds genuinely non-structured behavior: results come back 'newest first', the payload includes register details, website, technologies and job board, and 'No match is never charged' discloses a billing trait an agent would otherwise not know.

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?

Front-loaded with the core capability, followed by corpus scope, filters, and return shape in three tight sentences. The long middle clause enumerating states is a bit list-heavy but every element carries information an agent needs to judge coverage.

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 an 11-parameter, no-output-schema tool, the description covers what the corpus contains, what can be filtered, what is returned, and result ordering. Only the pagination story (limit/offset interplay) is left entirely to the schema, which is acceptable since those fields are documented there.

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 schema already explains every filter including the `has`, `tech` and `source` vocabularies. The description only restates the filter categories in prose (e.g. 'technology on their site (for example Shopify or WordPress)'), adding illustration but little new semantics 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?

States a specific verb and resource ('Finds companies') and scopes the corpus precisely: newly formed businesses in five named states with a verified website, plus every FDIC-insured bank. That corpus definition implicitly separates it from siblings like search_company_registry or company_lookup, though no sibling is named explicitly.

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 by the enumeration of filters ('Filter by state, source, city, name, formation date, technology...'), so an agent can infer this is the broad filtered-search entry point. However, it never states when to prefer company_lookup, search_company_registry, new_businesses, or compare_companies, nor any exclusions or prerequisites.

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

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

Annotations already declare read-only, open-world, idempotent, non-destructive behavior, so the description's extra details add useful context: results use the same field names across systems and one company's failure does not lose the others. It stops short of documenting auth, rate limits, or exact return 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 short and front-loads the core capability in the first sentence. The remaining sentences add relevant differentiation and failure behavior, though the 'thing no single applicant-tracking system can do' wording is slightly promotional.

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 two-parameter, read-only, open-world tool with rich annotations and complete schema descriptions, the definition covers purpose, normalization, and partial-failure behavior. It does not describe the output fields or how results are ordered, which keeps it from being fully complete in the absence 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 description coverage is 100%, so the schema already documents both 'companies' and 'per_company' including limits and default. The description only reinforces the multi-company scope and adds no extra parameter semantics 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 first sentence states a specific verb and resource (open jobs) with an explicit multi-company scope and normalized schema. It is clear what the tool does, though it never names or contrasts with the sibling tools find_company_board and list_open_jobs.

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 'across several companies at once' implies the comparison use case, but the description gives no explicit when-to-use/when-not-to-use guidance or named alternatives. The vendor sentence is a value proposition rather than routing 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 readOnly, idempotent, openWorld and non-destructive, yet the description adds real value: the evidence sources it inspects (HTML, headers, cookies, DNS), that each detection comes with a confidence and supporting evidence, and the single-page-load limitation. It does not mention cost, rate limits, or behavior on an unreachable URL, which keeps it below a 5.

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

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

Two sentences, front-loaded with the action and output shape, then the mechanics and the key limitation. Every clause carries information and nothing is redundant.

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 carries the burden of explaining returns and does so (technologies by category, each with confidence and evidence). Combined with the source list and the JS-rendering caveat, an agent has everything needed to decide to call it and 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 coverage is 100%, so both parameters are already documented including the min_confidence default of 50. The description only reinforces the meaning of confidence ('with a confidence and the evidence for each') and the 'one page load' scoping, adding no syntax or format detail beyond the schema — appropriate baseline of 3.

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?

States a concrete verb and resource ('Fetch one web page and report the technologies behind it') and enumerates the detection categories (CMS, ecommerce, analytics, CDN, web server, frameworks, payment processors, email provider), which clearly separates it from generic page-reading siblings like read_page or extract_page even though those are not named.

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?

Gives clear operating context ('Reads HTML, headers, cookies and DNS from one page load') and an explicit exclusion ('cannot see what only a running browser reveals'), which steers an agent away from using it for JS-rendered content. It does not directly name an alternative tool such as read_page/extract_page for that case, so it stops short of a full when/when-not/alternative map.

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 cover read-only, idempotent, open-world, non-destructive behavior, so the bar is lower, and the description still adds meaningful context: the registration data source (the registry's RDAP server) and an explicit privacy limitation that no registrant names or contact details are returned. That limitation is real behavioral information an agent would otherwise only discover after calling.

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

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

Two sentences: a dense but front-loaded inventory of what is returned, followed by the scope limitation. Every clause earns its place, though the single long enumeration sentence is heavier than ideal.

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 carries the burden of describing return values and does so thoroughly, field by field, plus the source of the data and the explicit exclusion of registrant details. The single fully-documented parameter leaves no ambiguity about how to call it.

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

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

Schema coverage is 100% and the schema already explains that the parameter accepts a domain, URL, or email address and that the registered domain is used. The description only says 'for one domain,' adding no syntax or format meaning beyond the schema, so the baseline 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?

A specific verb ('look up') plus resource ('domain') with an explicit enumeration of the returned data: registration status, registrar, key dates, status codes, nameservers, A/AAAA/MX/NS/TXT records, email provider, SPF/DMARC. It is clearly distinguishable from siblings like validate_vat, check_email, or search_company_registry.

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 use case is implied clearly by the enumerated outputs, but there is no explicit when-to-use/when-not guidance and no mention of alternatives such as check_email for email-focused validation or search_company_registry for registrant-level data. An agent can infer the fit, but the routing is left to 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 cover safety (readOnly, idempotent, non-destructive, openWorld), yet the description adds genuinely new behavior: strict grounding ("only what the page states", missing values returned empty rather than guessed), an API-key requirement, a concrete cost of 5 calls, and refunds on failed extractions. That is exactly the cost/auth/failure context annotations cannot express.

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

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

Two dense sentences with no filler: the grounding rule and default output come first, then the calling modes, then auth/cost/refund. Every clause carries information an agent needs.

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

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

Covers purpose, output shape, default behavior, authentication, pricing, and failure handling for a 4-parameter tool with no output schema. An agent has everything needed to decide to call it and to predict the result.

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 baseline is 3, but the description adds the important semantic that fields, schema, and neither are alternative modes with a defined default (title, summary, key points). It does not clarify interaction between instructions and the other two modes, so it stops at 4.

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?

Specific verb (read a web page) plus a precise output contract (named fields as JSON), which implicitly separates it from the raw-page sibling read_page. However, it never names read_page or any sibling explicitly, so differentiation is left to inference.

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?

"Name fields, or pass a JSON Schema, or neither for a title, summary and key points" gives clear mode-selection guidance for the three ways to call it. It stops short of saying when to prefer this over read_page or the other extraction 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 readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds genuinely new behavioral context: result ordering per mode, the fields included in recompete output (incumbent, days until expiry), and that every record links to the official award page — valuable given no output schema exists.

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

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

Three sentences, front-loaded with the primary search behavior, then the alternate mode, then the output guarantee. No filler, and the ordering/scope facts are stated where they are most needed.

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 10-parameter tool with no output schema, the description covers both modes, ordering, key returned fields, and the official-link guarantee. Defaults and date formats live in the schema, so nothing critical is missing, though a note on how modes interact with date-bounded filters would close the last gap.

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 every parameter (including mode enum and expiring window bounds) is already documented in structured form. The description restates agency/keyword/dollar-amount filtering and the recompete window concept, adding little beyond the schema's own notes on min_amount and 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?

Names a specific verb and resource (searches awarded US federal contracts) plus the underlying source (USAspending.gov), and distinguishes its two modes explicitly: search ordered largest-first vs. recompete ordered soonest-expiring. An agent can tell exactly what each invocation returns and no sibling tool covers this domain, so ambiguity is low.

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?

Gives clear mode-selection guidance ('Recompete mode instead lists contracts expiring soonest within a window') and a narrowing hint ('set min_amount to keep the search narrow'). It lacks explicit when-not-to-use or exclusions, but the conditions that select each mode are stated.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: why the tool must exist (no vendor publishes a customer directory) and that downstream board APIs require the board name this tool resolves. It doesn't cover what happens on zero or multiple matches.

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?

Front-loaded with the core purpose, and the rationale sentences earn most of their place. The aside that no vendor knows about the others is slightly redundant with the preceding sentence but still supports the 'why' framing.

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 two-parameter resolver with no output schema, the description explains the purpose and the downstream dependency clearly. It leaves the return shape (a list of up to 'limit' matches, with board type and board name) implied rather than stated, which is the main remaining gap.

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 both parameters are already documented, including that 'company' accepts a company or board name with case/punctuation insensitivity. The description only reinforces that the input is a company name rather than a careers URL, adding little 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?

States a specific verb and resource: it resolves which applicant-tracking system a company's careers page runs on. It also implicitly separates itself from list_open_jobs by framing the task as finding the board rather than reading jobs from it.

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?

Gives an explicit routing rule: 'Use this first when you have a company name rather than a careers URL.' That clearly signals when to reach for this tool over URL-based alternatives, though it doesn't name list_open_jobs or other siblings directly.

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 substantial behavioral context beyond the annotations: it discloses the ranking criteria (returning paying wallets, 402 response, price, uptime), the result fields (price, networks, method, re-check links), and the cost behavior ('No match is never charged'). This is exactly the kind of detail an agent needs to understand the tool's 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, front-loaded paragraph that covers purpose, ranking, result contents, and cost. It is slightly dense but every sentence contributes useful information; no obvious waste.

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 read-only search tool with no output schema but rich annotations and full parameter descriptions, the description provides everything needed: what it returns, how it ranks, what each result contains, and the 'no match' cost caveat. An agent can call it correctly without further docs.

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 all parameters are already documented. The description does not add any parameter-specific meaning beyond what the schema provides (e.g., it doesn't explain 'sort' or 'include_down' further). With schema doing the heavy lifting, the 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 it returns x402 endpoints based on a plain-language need, with verb 'get' and resource 'x402 endpoints'. It does not explicitly differentiate from siblings, but none of the sibling tools are directly comparable, so the purpose is still 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 gives a clear usage context: 'Say what you need in plain words … and get the x402 endpoints that do it.' It implies when to use the tool, but it does not state any exclusions or point to alternatives, which prevents 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?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds real behavioral context beyond them: it reads the company's live board, salary data appears only where the board publishes pay, and change data comes from a daily record. It doesn't state rate limits or failure behavior for unknown companies, but the additions are substantive.

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?

Front-loaded with the core value (hiring at a glance) and then densifies the output list; every clause maps to a distinct returned metric. It is one long sentence but not padded, with only minor density cost.

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 carries the full burden of explaining return values and does so thoroughly: counts by department and location, remote share, per-currency salary ranges, and opened/closed roles over the window. Combined with source-board and input guidance, an agent has enough to call it 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 coverage is 100%, so both parameters are already documented, including the 7/30 enum-like constraint for days. The description restates the same facts (7 or 30 days, company name/board name/careers URL) without adding format details or defaults beyond the schema, so baseline 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?

States a specific verb+resource (aggregate hiring summary for one company) and enumerates the outputs: per-department/per-location counts, remote share, salary ranges, and 7/30-day change. This clearly distinguishes it from siblings like list_open_jobs and job_changes, which imply individual listings or deltas rather than a rolled-up profile.

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 for use (a company name, board name, or careers URL; reads live Greenhouse/Ashby/Lever/Workable boards) and implies the summary-oriented use case. It stops short of explicitly naming when to prefer compare_companies or job_changes instead, so an exclusion rule is missing.

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

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds useful context the annotations don't carry: coverage across every job board in the directory and the incremental daily-read pattern that makes the tool cheap. It says nothing about default limit, ordering, or what board_gone means, which are behavioral traits an agent would otherwise have to guess.

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

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

Three sentences, front-loaded with what the tool returns, then the polling instruction, then filtering. No filler and no repetition of schema or annotation content.

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 7-parameter, unrequired, read-only feed with no output schema, the description covers what is returned and how to schedule calls, which is what an agent most needs. Gaps remain around result ordering, the default limit, and the meaning of the board_gone change kind, but they are secondary rather than blocking.

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 baseline is 3. The description goes slightly beyond the schema by explaining since as 'the last day you saw' (stateful semantics, not just a format) and by clarifying that omitting companies means the whole market. It leaves kinds values and offset paging to the schema, which is the right division of labor.

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?

States a specific verb-and-resource: a day-by-day change feed of job postings (new, removed, reopened, edited) pulled from every board in the directory. That is far more than a restatement of the title. It does not name or contrast a sibling, so an agent must infer that list_open_jobs is the snapshot alternative rather than having that spelled out.

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?

Gives concrete usage guidance: call each day with since set to the last day seen instead of re-reading every board, a clear incremental-polling workflow. It also explains when to omit companies (whole market) versus filtering by kind and title words. It stops short of explicitly naming an alternative tool for the case where the agent needs the current open-jobs snapshot.

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 cover read-only, idempotent and non-destructive behavior, but the description adds real value beyond them: the exact return fields, the salary-parsing policy ('refused rather than guessed' with three named failure cases), the salary_text fallback, and that contact details are stripped. Pagination/limit behavior is not disclosed, keeping it below a 5.

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

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

Three sentences, front-loaded with the scope, then return fields, then the salary edge-case policy. Dense but every clause carries information; the salary policy is slightly over-weighted relative to the omitted limit behavior, but nothing is redundant.

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 correctly takes on the burden of describing the returned fields and the salary edge cases, which it does well. It omits how limit/pagination behaves and how to resolve an ambiguous company identifier (the find_company_board sibling), leaving a small but real gap.

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 three parameters including company's accepted formats are fully documented in the schema. The description reinforces the single-company scope and that descriptions are excluded by default, but adds no syntax or format detail beyond what the schema already states. Baseline 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?

States a specific verb and resource with scope: 'Every open job at one company, read from its own careers system.' An agent can immediately tell this is a per-company listing tool, implicitly distinct from compare_companies (multi-company). It never names a sibling explicitly, so it falls short of a 5.

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

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

Usage is only implied by the scope phrase 'at one company' — there is no explicit when-to-use, when-not, or pointer to find_company_board for resolving a board name or compare_companies for cross-company views. An agent must infer routing from the sibling names 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?

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds genuinely non-obvious behavior: the explicit exclusion of officers, directors, registered agents, emails, phones and street addresses, the provenance rule for the website field ('its own pages show the exact legal name and the same city or state'), and the partial-failure contract ('if one state fails the others still return and the failure is listed in missing'). Its limitation is that it doesn't say how records are ordered or paged across states beyond 'newest first'.

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 paragraph is dense but front-loaded: what it searches, then what each mode is for, then exclusions and caveats. Nearly every sentence carries operational information. Minor cost is the run-on packing of mode descriptions and caveats into one block, which makes scanning harder than a short structure would.

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 nine-parameter, five-source, no-output-schema tool, the description covers the things an agent cannot infer: data excluded from records, website field semantics, per-state publishing cadence and status coverage, and degraded-result behavior via 'missing'. Nothing needed to call it correctly or interpret partial results is missing.

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 baseline is 3, but the description adds interpretive value the schema doesn't: state-level publication limits mean a missing NY/OR/PA entity 'may be inactive or unregistered', which changes how an agent should read status filters and empty search results. The rest (mode roles, entity_numbers not unique across states) largely duplicates the schema text.

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 first sentence names the concrete resource (official Secretary of State business registers of NY, CO, OR, CT, PA) and the three modes and their distinct jobs are spelled out: 'new' as a formation-date feed, 'search' by legal name, 'lookup' by state entity number. That is enough to distinguish it from siblings like company_lookup, search_company_registry and validate_vat without opening the schema.

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 names both use cases and the mode that serves each: 'use it for new-business leads ... and prospecting' for mode new, and 'use them for KYB ... on a supplier or counterparty' for search and lookup. It also gives coverage caveats that steer choice (NY/OR/PA publish active entities only; PA is monthly, so its records lag).

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 readOnly/openWorld/idempotent/non-destructive, so the description's added value is elsewhere: robots.txt is honored, some sites refuse automated readers, and those failures return a reason and cost nothing (a billing/retry-relevant fact an agent cannot infer from structured fields). No return format or rate-limit detail beyond that, so not a 5.

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

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

Three short sentences, densely packed and front-loaded with what the agent gets back, followed by the scoping constraint and the failure mode. No filler.

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 carries the return-value burden and does so: markdown body, title, final post-redirect URL, optional schema.org data. Truncation is covered by the schema. Missing only marginal detail like rate limits or size limits beyond max_chars.

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 url and max_chars, including the default of 20000 and the truncated flag, are fully documented in the schema. The description adds no parameter-level meaning, so the baseline 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?

States a specific verb+resource: fetches any public web page or PDF and returns clean markdown, title, final URL after redirects, and schema.org data. That is concrete and distinguishes it from lookup-style siblings. It does not, however, differentiate from the sibling extract_page, which appears to overlap heavily.

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 only implied: read a page when you need its contents as markdown. There is no explicit when-to-use/when-not guidance and no mention of when to prefer extract_page or other siblings, which is the most likely agent confusion here.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the description is free to add scope detail — and it does: it defines exactly which registers are covered, specifies that US coverage requires an LEI, and states the exclusions ('Companies only, no directors or contact details'). Not disclosing pagination/no-match behavior keeps it from a 5.

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

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

Two sentences, front-loaded with the action and the returned fields, then the coverage list. The country enumeration is long but each element is decision-relevant; only minor trimming (e.g. the parenthetical about state filing numbers) is possible.

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 carries the return-value burden and does so by naming the fields returned and their consistent shape. The remaining gap is operational: no statement about what happens on zero results or how limit interacts with ranking, which for a 4-parameter search tool is a real but modest omission.

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 baseline is 3, but the description adds genuine meaning: it constrains the country parameter to the supported register set and explains the LEI condition that governs whether the state parameter applies to a US entity. That is useful context beyond the schema's own text.

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?

States a specific verb+resource ('Searches one country's official company register by name') and enumerates both the coverage (GB, NO, FR, FI, CZ, SK, IE, AU, LEI, US) and the returned shape. It is clear this is official-register data, but it never names siblings like company_search or company_lookup to draw the boundary explicitly.

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 by the coverage list and the 'official register' framing, so an agent can infer this is the authoritative-source option. However, there is no explicit when-to-use / when-not statement and no mention of company_search or company_lookup as alternatives, which matters given three similarly named 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 read-only, idempotent, open-world and non-destructive behavior, so the safety profile is covered. The description still adds value beyond them: it discloses rank ordering ('in rank order'), that the front page is live, that comment threads are returned whole, and that every item links back to news.ycombinator.com—a useful output-shape hint. Missing are rate-limit or pagination notes, but those are largely encoded in the schema's max_items 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 definition is two sentences with no filler, front-loading the primary verb and resource before enumerating modes. The first sentence is a long compound that packs in every mode, which taxes readability slightly, but nothing is redundant or padding.

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 13-parameter, multi-mode tool with no output schema, the description covers the three behavioral families, ordering, and a return-value hint (links back to news.ycombinator.com). Full parameter semantics are delegated to the exceptionally complete schema, and the safety profile is delegated to annotations. It stops short of describing result structure for story_comments output, but is otherwise sufficient to invoke correctly.

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

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

Schema coverage is 100%, with every one of the 13 parameters carrying a description that names its applicable mode and accepted values. The description restates the filter categories (date, points, comment count) but adds no syntax, defaults, or edge-case guidance beyond what the schema already says. Baseline 3 is correct when the schema 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 names specific verbs and resources: search stories and comments with date/points/comment filters, read the front page and top/best/new/ask/show lists in rank order, or read whole comment threads. This covers all modes of the tool and clearly distinguishes it from every sibling, none of which touch Hacker News. An agent can tell exactly what the tool does without opening the schema.

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 implicitly routes usage by enumerating behaviors—filters go with search, rank-ordered reading goes with the front-page/list modes, thread reading with comments—and the schema's mode description makes the mapping explicit. It doesn't state when NOT to use the tool or name a fallback (e.g., read_page for non-HN URLs), but with unrelated siblings there is little alternative confusion to resolve.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new context by enumerating the returned fields (title, authors, year, citation count, DOI, abstract, free full-text link) and noting the full-text link is conditional ('when one exists'), which matters because there is no output schema.

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

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

Two sentences, zero waste. The capability enumeration is front-loaded and the return-value summary is deferred to the second sentence, which is the right order for an agent deciding whether to call.

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 16 optional parameters, full schema coverage and no output schema, the description covers both what the tool does and what comes back. Minor gaps remain: no mention of ranking/sort behavior, result caps (max_results lives only in the schema) or the matched_entity echo, though these are low-risk for a read-only search.

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% across all 16 parameters, including mode defaults and value vocabularies, so the schema does the heavy lifting. The description only implies the mode grouping through its four clauses and touches loosely on include_abstract and open_access_only via 'abstract' and 'free full-text link'; it adds no syntax, limits or value details beyond the schema.

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

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

Names a specific verb and resource (search the OpenAlex catalogue of scholarly papers) and then enumerates the four distinct operations the single tool covers: keyword search, DOI lookup, citing-papers lookup, and institution/journal listing. None of the siblings (email, company registry, jobs, page extraction, SEC, VAT) overlap, so the boundary is 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 four clauses map cleanly onto the four modes, giving an agent a clear signal about which entry point to pick ('look papers up by DOI', 'list the papers that cite one work'). It stops short of explicit when-not guidance or naming a fallback tool, so it is context-rich rather than fully prescriptive.

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 establish that this is a read-only, idempotent, open-world operation. The description adds useful behavioral context: data comes from SEC EDGAR XBRL, every figure includes period_type and a filing link, and the tool reports figures rather than advice.

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

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

The description is front-loaded with the core action and source, then efficiently covers company mode, screen mode, output characteristics, and scope. Every sentence contributes useful information without 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?

For a nine-parameter tool with no output schema, the description covers the source, both modes, metric scope, and the key output trait that figures carry period_type and filing links. It omits some operational details such as rate limits or pagination behavior, but the schema covers parameter defaults and filters.

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 schema already explains all nine parameters, including mode, metric, period, company, and filters. The description reinforces the mode distinction and metric examples but adds little parameter detail beyond what the schema 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 gives a specific verb and resource: reads US public company financials from SEC EDGAR XBRL. It clearly distinguishes the two operational modes, company history versus cross-company screening, so an agent can identify the tool's function without opening the schema.

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 explains what each mode does and implies when to choose company mode versus screen mode. It does not explicitly name alternatives such as compare_companies or state when not to use this tool, which keeps it below 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?

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower; the description still adds substantive behavior: it discloses the partial-return rule (registered name only when the member state shares it) and the critical failure mode — a busy or down member state surfaces as an error, never as an invalid number. That error-vs-invalid distinction is exactly the kind of nuance an agent needs and cannot infer.

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

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

Three compact sentences: what it does, what it covers geographically, and the error-vs-invalid caveat last. Every sentence earns its place and the important scope constraint is 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?

With no output schema, the description still explains the return shape (live/invalid plus optional registered name) and the error case. For a single-parameter lookup tool, nothing an agent needs to call it correctly or interpret results is missing.

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 already documents the two-letter country-code prefix, ignored whitespace/dots/hyphens, and the GR→EL mapping. The description only reinforces that it takes 'one' number (no batch), adding marginal meaning beyond the schema, so the baseline 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?

States a specific verb (checks/validates), a specific resource (one VAT number) and the authoritative source (European Commission VIES). No sibling tool shares this domain, and the description makes the scope unambiguous without opening the schema.

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 applicability boundaries — the 27 EU states plus Northern Ireland (XI) — which tells the agent when the tool is and isn't valid (e.g. not for US EINs). It doesn't name alternatives, but no sibling overlaps this task, so there is little to route between.

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