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

The description adds meaningful behavioral detail: the rolling window semantics differ by metric type (30-year vs ~5-year), the response includes a served grid cell and coverage flag (useful confidence signal), and the place-name resolution rules (GeoNames cities500, exact match only, no fuzzy matching, ties broken by population) are disclosed. The location input's resolution behavior is transparent. With no annotations present, the description carries the behavioral burden well.

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 with the purpose and trigger scenarios. The pricing, trial, and docs URL are useful operational details. It's a single dense paragraph rather than scannable bullets, which slightly hurts readability, and the location details could arguably belong in the schema rather than the description. Still, every sentence earns its place with minimal 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?

The tool has 4 required params, no output schema, and no annotations, so the description must carry the burden. It explains location semantics (place name vs lat/lon, aliases, resolution rules), window behavior, output elements (grid cell, coverage flag, data.location echo), pricing, and docs link. It stops short of detailing the exact output structure or units for each metric, but the description is reasonably complete for an aggregation tool targeting selective decision use-cases.

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 50% (only `country` and `location` have descriptions). The description compensates substantially: it documents the date-range semantics (rolling aggregation windows), explains that location can be a place name OR lat/lon, and clarifies the alias `city` for location. The `from`/`to` parameters remain underexplained in the description but the window semantics partially cover them. Given the coverage gap, the description adds real value 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 opens with a specific verb+resource: 'climate summaries for any GPS point or city over a date range', followed by concrete metrics (mean/min/max temp, total precipitation, mean wind) and data source (Copernicus ERA5). It clearly distinguishes this aggregate tool from siblings like climate_point, climate_degree_days, and climate_indices by specifying it returns aggregated period stats with a served grid cell and coverage flag.

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 lists concrete trigger scenarios ('before a seasonal report, audits an ESG claim or reconciles a weather-linked contract') signaling appropriate contexts. It also specifies the rolling window behavior (30-year for temp/precip, ~5-year for wind), which helps an agent know what the aggregate actually represents. It doesn't explicitly enumerate sibling alternatives or say when NOT to use it, so not 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?

No annotations are provided, so the description carries the burden. It discloses practical behavioral details like the price per call, first-call-free trial, 'rolling 30 years for temperature/precipitation and ~5 years for wind' data window, and links to docs. However, it doesn't disclose what the response/return format looks like (units, anomaly direction conventions, error cases like unmapped city) — moderate value but gaps remain on output 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 core description is one dense, front-loaded sentence covering data dimensions and normal window, followed by practical pricing/doc info. Pricing and doc link are arguably outside the tool's semantic description but useful. Slightly dense but well organized; no wasted 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?

Given the tool's complexity (multi-variable anomalies, rolling windows, city-or-coordinate addressing) and low schema coverage with no output schema, the description explains the anomaly semantics, normal baselines, and addressing alternatives well. It could detail the return format and error/edge behavior, but the core usage is adequately covered.

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

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

Schema description coverage is only 25% — only 'lat' has a description. The description compensates substantially: it explains lat/lon can be replaced by city=<name> with aliases location=, country= ISO 3166 alpha-2, resolved via GeoNames with 'exact match, most populous wins' and echoed back as data.location. From/to necessity and the date range is implied. This adds meaningful semantics beyond the sparse 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 computes how observed temperature, precipitation, and wind departed from the WMO 1991-2020 climatological normal for any GPS point or city over a date range. It has a specific verb (get/compute anomalies), resource (climate anomalies), and distinguishes scope. Sibling tools like climate_point (single point data), climate_aggregate, and climate_indices are differentiated by phrasing focused on anomaly-normal comparison, though it doesn't explicitly name siblings.

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 states 'before your agent verifies a hotter than normal claim, reports climate exposure or settles an anomaly-based trigger' which gives clear when-to-use context. It does not explicitly name alternative tools for when NOT to use it, but the meteorological anomaly verification intent is clear and specific enough to guide selection among the climate_* 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?

No annotations are provided, so the description carries full behavioral burden. It discloses the computation methodology (ERA5 daily mean temp, 30-year rolling window, NWS/EIA/WMO method) and pricing, but does not describe what the response contains, whether it's a read-only operation, rate limits beyond first-call-free, or error behavior. The pricing disclosure is helpful but the safety/behavioral profile of a query tool is not explicitly stated.

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 reasonably concise with one purpose sentence followed by pricing and docs info. The opening line is front-loaded with the purpose and use cases. Pricing and docs are appropriately placed at the end. Slight bloat in listing all three degree-day types in prose, but this is informative rather than wasteful.

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 6 params, 17% schema coverage, no output schema, and no annotations, this description has significant gaps. It doesn't explain parameter semantics for kind/base/from/to, doesn't describe return format, and doesn't cover pagination, limits, or error cases. The computation methodology disclosure is a strength, but for a 6-param API point tool with no structured docs, the description should provide substantially more guidance to an agent.

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 only 17%, so the description must compensate significantly. The description adds the era5 rolling-window method context and pricing but does not explain the key parameters: what 'kind' values are acceptable (HDD/CDD/GDD are mentioned in prose but not mapped to the kind param), what format 'from'/'to' should take, or what 'base' means. The lat description in schema handles latitude/city aliasing well, but the other five params remain undocumented in both schema and description.

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

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

The description clearly states the verb+resource: 'Get degree-days for a location', and elaborates that HDD/CDD/GDD are computed from ERA5 data for any GPS point or city over a date range. It distinguishes from siblings like climate_indices, climate_anomaly, and weather_forecast by specifying degree-day computations specifically. It doesn't explicitly name alternatives, but the specific metric (degree-days) is clearly different from siblings.

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 on when to use it ('Before your agent sizes heating or cooling demand, settles an energy contract or models crop growth: heating, cooling and growing degree-days'). This frames the use case well. It doesn't explicitly state when NOT to use it or name alternative tools, but the open-hand context of use is well established.

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?

No annotations are provided, so the description carries the full burden. It discloses meaningful behavioral details: 30-year rolling window for precipitation indices vs ~5-year window for Tmin/Tmax and gust indices, true daily Tmin/Tmax from Copernicus ERA5, pricing per call, and the free daily trial. It doesn't describe output format or pagination, but given the richness of the disclosed behavior, this is strong. It does not contradict any annotations (none exist).

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 front-loads the use-case guidance and index list efficiently, then packs pricing, trial, and docs links into a compact footer. However, the primary description sentence is long and dense, with nested parentheticals listing many indices, and the rolling-window clarification is intricate. While there's no waste, the density slightly hurts scannability. The lat parameter description is verbose but necessary given the schema gap. Overall compact but heavy.

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 4-parameter read tool with no output schema and no annotations, the description is quite complete: it defines the resource, data source, standard (ETCCDI/Climdex), custom windows, pricing for cost-aware agents, and docs links. It omits output format/return structure, but with an output-like list of computed indices given, an agent can infer the result content. A small gap is lacking explicit date-format expectations for from/to. Strong overall for its complexity level.

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 only 25% (only 'lat' has a description), so the description must compensate heavily. The lat description's own content is excellent, explaining the alternative city=name alias, location=, optional country= ISO code, GeoNames resolution behavior (exact match, most populous wins), and the data.location echo. The main description's scope statement (GPS point or city over a date range) gives context for lat/lon/from/to. Minor gap: 'from' and 'to' date formats aren't specified beyond 'date range.' Given the low schema coverage and the strong compensation in both blobs, a 4 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 computes climate-event indices (explicitly naming frost days, summer days, tropical nights, dry spells, etc.) for any GPS point or city over a date range, grounded in ETCCDI/Climdex definitions from ERA5. It uses a specific verb ('gets') with a clear resource (climate-event indices) and strongly differentiates from siblings like climate_aggregate, climate_anomaly, climate_point, and climate_return_period.

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 opens by spelling out exact use contexts: pricing/settling parametric-insurance triggers, or screening weather risk for agriculture and construction. It names the data source and standard definitions, and distinguishes from sibling climate tools by the specific index types returned. Pricing and documentation links provide operational context for when the agent should (or can) call this tool.

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

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

No annotations are provided, so the description carries the full burden. It transparently discloses data coverage windows (30 years for temp/precip, ~5 years for wind), the served grid cell and coverage flag outputs, pricing, the daily free trial, and exact-vs-out-of-range error behaviors. Only minor gap: it doesn't detail request volume/rate limits, but it discloses the most operationally relevant traits.

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 use case in the first clauses and is well-structured. It's a bit dense with supporting facts (pricing, docs URL, grid cell, coverage flag), but every sentence carries value and the density reflects genuine behavioral richness rather than 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?

Given a 2-parameter tool with full schema coverage, this description is thorough: it covers the data source, coverage windows, output signals (grid cell, coverage flag), error behaviors, pricing, and even cross-references alternatives (lat+lon). No output schema exists, so the description's disclosure of returned data (covered families, coverage flag, resolved location) provides necessary completeness.

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?

While schema coverage is 100%, the description adds substantial meaning beyond the schema: it clarifies city resolution uses an embedded GeoNames cities500 gazetteer with exact (non-fuzzy) matching and population tie-breaking, mentions the location alias and country narrowing option, describes resolved-place echoing, and details date window/out-of-range error handling. This significantly enriches bare schema definitions.

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+resource ('Get historical weather for a location') and lists exact data (daily 2 m temperature, total precipitation, 10 m wind) and the source (Copernicus ERA5 reanalysis). It clearly distinguished from sibling tools like climate_point_batch (batch variant), weather_forecast (future), and climate_aggregate/anomaly which do different processing.

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 opening sentence explicitly states three usage contexts: verifying weather-dependent claims, backtesting parametric triggers, and checking site/shipment conditions. It also distinguishes the past-focused scope with a coverage window, and siblings like weather_forecast/weather_forecast_daily imply a future-oriented alternative, which the 'historical' framing implicitly excludes.

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?

With no annotations provided, the description carries the full burden and does well: discloses pricing formula ($0.005 base + $0.005×N), the 500 cap, per-item coverage flagging behavior, the rolling 30-year vs ~5-year window distinction by variable, city-name resolution rules (exact match, case/accent-insensitive, no fuzzy, population tie-break), and unknown-city degradation. It also notes a 400 for unknown variable families and over-500 batches. Rich behavioral disclosure given zero annotation support.

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 compact lead sentence with a clear skip-if not applicable preamble, followed by dense but organized technical details including pricing and documentation link. It front-loads the core purpose before diving into mechanics. Slightly dense with mixed concerns (pricing, coverage, windows, city rules) packed together, but each sentence earns its place 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?

For a tool with 1 parameter, 100% schema coverage, and no output schema, the description plus schema together are quite complete: date format (YYYY-MM-DD), point forms (lat+lon or city), variable families, coverage semantics, pricing, caps, and error handling are all covered. The absence of an output schema means the description doesn't detail the return-value shape beyond location echo and coverage.complete, which is a minor gap but acceptable given the schema's own descriptive richness.

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% because there's only one parameter (queries), and the schema provides detailed descriptions. The description adds meaningful value beyond the schema: pricing per unit, the 500-item cap, the rolling window semantics (30 years temp/precip, ~5 years wind), and the E5 dataset source. The variables field's 'coverage/price unaffected' semantics and the city resolution fallback are well documented in the schema and reinforced contextually.

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 provides daily 2m temperature, total precipitation and 10m wind from Copernicus ERA5 for up to 500 point/date queries in one call. The verb+resource is specific and it distinguishes from siblings like climate_point (single-point variant) and climate_aggregate (aggregation). The use-case preamble (backtesting parametric triggers, verifying claims across parcels, scoring weather exposure) further grounds the purpose.

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

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

The description explicitly frames when to use it: portfolio/parcel/fleet-scale batching scenarios, contrasting implicit with the single-point sibling. It states batch size cap, pricing structure, and error behavior (uncovered items degrade per-item rather than failing). It doesn't explicitly name which sibling tool to use instead for single-point queries, but the batch-vs-single distinction is strongly 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?

No annotations are provided, so the description must carry the burden. It does disclose useful facts: rolling 30-year window, temperature and precipitation coverage, sample_years and coverage reporting, per-call pricing. However, it doesn't disclose whether this is a read-only operation, pagination, or output format structure. For a query tool with no annotations, a modest 3 is fair.

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 efficiently structured across two tight paragraphs plus pricing/docs lines. The first sentence front-loads purpose and use-case. Some details (price, trial, docs URL) could arguably live elsewhere, but they're compact and useful. A couple of parentheticals are dense but not wasteful.

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 4-param query tool with no annotations and no output schema, the description covers the data scope (30-year window, temperature/precipitation, sample size reporting) and one parameter's alternative semantics well. But it leaves return-format specifics, error/edge cases (e.g., year outside the 30-year window), and behavioral details unexplored. Adequate but with clear gaps for a moderately complex financial-risk 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 only 25%, so the description must compensate substantially. It explains lat/lon vs the city/location/country alternative in detail (GeoNames gazetteer resolution, most populous wins), which is strong. However, it adds nothing about month, year, or lon beyond what the schema provides. The description covers about half of the parameters meaningfully, partially offsetting but not fully filling the coverage gap.

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

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

The description clearly states the verb+resource+scope: it ranks a target year's season against 30 years of a location's climate history, computing percentile, empirical return period and sample size. It explicitly names the data source (Copernicus ERA5) and the target use-case (underwriting, reinsurance, stress-testing). It distinguishes from siblings like climate_aggregate and climate_anomaly by focusing on return periods/percentiles.

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 when to use it (before underwriting, reinsuring, or stress-testing climate exposure) and specifies the 30-year rolling window and WMO-standard period. It does not explicitly name alternatives or when-not-to-use, but the strong use-case framing plus the sibling list (climate_anomaly, climate_aggregate) provides enough differentiation. It also documents the pricing and trial details.

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?

With no annotations provided, the description carries the full burden. It discloses pricing ($0.01/call, first free), billing semantics (empty timeline is billed, 404 is unbilled), error behavior (malformed input=400, Luhn failure=400, unknown-to-register=404), and distinguishes 'unknown to register' from 'known, no announcement.' It could add return-format details (structure of the timeline/flags objects) but the core behavioral traits are well 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 front-loaded with the purpose and use case, then pricing, then docs link. It's efficient and each sentence carries meaning. However, it packs multiple concerns (pricing, billing semantics, error codes) into somewhat dense prose that isn't strictly about usage — slightly longer than ideal but each clause earns its place. A single trimmed sentence could tighten it.

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 2-param tool with no output schema, the description covers what it checks, when to use it, how billing works, error semantics, and the family filter's behavior. The main gap is the return payload structure (what an 'event timeline' and 'factual flags' object looks like), but the description is rich enough for an agent to select and invoke correctly with confidence.

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?

While schema coverage is 100%, the description adds significant meaning beyond it: it explains the SIREN validation chain (malformed=400, Luhn=400, unknown register=404 vs empty=200 billed), which is crucial for correct invocations. For family, it enumerates the exact values ('insolvency', 'deregistration', 'sale') with definitions and clarifies the subtle behavior that family filters events[] but never the flags. This materially enhances 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 states a specific verb+resource+outcome: 'Check a French company for official insolvency, deregistration and business-sale announcements...dated event timeline and factual flags from the official BODACC gazette, by SIREN.' It clearly distinguishes the tool by its data source (BODACC), use case (before invoicing/crediting), and output type (timeline + flags). The sibling tools like company_report, company_vat, company_ownership are all distinct in purpose, so there's no confusion.

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 an explicit when-to-use: 'before you invoice or extend credit.' It also clarifies when the empty result is meaningful ('An empty list is a paid answer: no known announcement over the covered window'), and contrasts a 404 vs empty-list outcome to avoid misinterpretation. It explains the 'No account, no key' access model and pricing context. This is strong usage 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?

There are no annotations, so the description carries full responsibility. It discloses key behaviors: homonyms are returned as candidates and never silently resolved, check digits are verified, invalid keys return 400 codes, and well-formed but absent entries return 404 unbilled. It also names the returned identity fields (legal name, jurisdiction, status, addresses, national registration number, BICs, ISINs). This is thorough behavioral disclosure.

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 primary purpose, followed by concise lookup modes, homonym policy, and pricing. Every sentence carries information, and the pricing/docs lines are compact and useful. 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?

Despite having only one parameter and no output schema, the description is complete: it enumerates all valid inputs, explains the exact-match behavior, describes the output contents, and notes billing and error semantics. The agent can confidently invoke this tool without additional external context.

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

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

The input schema description already provides 100% coverage with detailed semantics for the 'lei' parameter (accepted key types, formats, and error conditions). The main description redundantly lists the lookup options but adds the homonym candidate behavior and 'no fuzzy search' constraint, which are not in the schema. This adds meaning beyond the structured schema, earning a 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?

The description opens with a specific verb and resource: 'Identify the company behind a bank identifier, a French SIREN, an ISIN or an exact name' and states the scope 'worldwide (LEI)'. It clearly distinguishes this tool from siblings like company_vat or company_resolve by naming the specific identifier types and the official GLEIF LEI identity output.

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 strong context: 'before you onboard, pay or invoice it' and explicitly states that name lookup is exact and normalized, with no fuzzy search. It does not name alternative sibling tools or state when not to use this tool, but the use case is clear enough 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?

Rich behavioral disclosure beyond what annotations (none provided) offer: a declared absence of parent returns with an official reason, never an empty block; 'chain_truncated' flag signals hard depth bound; 'null' vs '[]' distinction for unasked vs asked-but-empty blocks; out-of-range produces 400 never silent trim; well-formed LEI absent from reference is a 404 unbilled. With no annotations, the description fully carries the behavioral transparency burden and does so excellently.

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 purpose in the first sentence, followed by return details, disambiguation, then pricing. While dense and information-rich with no waste, it packs a lot into long, somewhat run-on sentences that require careful reading. The commercial/pricing detail is useful but partially extraneous to tool selection.

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 moderately complex lookup tool with 3 parameters, no output schema, and no annotations, the description is remarkably complete: it explains return semantics, error behaviors (404 unbilled, 400 on range, chain_truncated), the null/[] distinction, the 100-cap on down-walks, the distinction from beneficial ownership, and points to docs. Nothing critical is missing for correct invocation and interpretation.

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

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

Schema coverage is 100%, but the description adds substantial meaning beyond the schema: depth explains it's a HARD bound with 400 behavior and 'chain_truncated' semantics; direction clarifies the down-walk returns only DIRECT subsidiaries capped at 100, and disambiguates null vs [] semantics. The lei param is cross-referenced to the companion /company/lei tool. This is textbook parameter enrichment.

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+resource: 'Find out who controls a counterparty' using the GLEIF Level 2 reference by LEI. It distinguishes its scope (declared control chain vs beneficial ownership) and enumerates exactly what it returns (direct parent, ultimate parent, dated chain, direct subsidiaries), clearly separating it from sibling tools like company_events, company_report, and company_vat.

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

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

Explicit when-to-use guidance: 'before you onboard, pay or invoice it.' It names the data source (GLEIF Level 2), clarifies this is accounting consolidation parent not beneficial ownership (avoiding misuse), and references companion tool /company/lei for deriving an LEI from other identifiers. The billing note and docs link add practical usage context.

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

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

With no annotations provided, the description carries the full burden and does an excellent job. It discloses billing behavior ($0.01, first call free), the nuanced status semantics (absent from directory is a successful 200, not a 404; only non-existent Sirene identifiers are 404 and not billed), error codes (400 INVALID_INPUT, INVALID_CHECKSUM), and Luhn checksum validation. This is exceptional depth for a description.

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 dense but well-organized. The first sentence front-loads the core purpose, followed by pricing and docs link. The parameter detail lives in the schema where it belongs. It's lengthy but every clause carries meaning; the behavioral details earn their place given the complexity of the paid/404 nuances.

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 single-parameter tool with a 100% schema-covered parameter and no output schema, the description fully covers what's needed: the check itself, the billing model, error cases, and identifier variants. There's no output schema, but the description mentions what's returned (participant identifiers, accepted document types, reachable flag) adequately. Very complete for its complexity.

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

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

The schema has 100% coverage with a single detailed parameter description. The description reinforces format requirements (9-digit SIREN, 14-digit SIRET, ICD:value participant format) and error semantics. It primarily defers to the schema for parameter detail, which is appropriate given full coverage, but the description itself doesn't add much beyond the schema's rich parameter 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 description clearly states what the tool does: check whether a company can receive e-invoices on the Peppol network, specifying the data source (official Peppol Directory export) and the output (participant identifiers and accepted document types). The title 'Check Peppol e-invoicing reachability' reinforces the purpose precisely.

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 before sending an e-invoice, and specifies the identifier types accepted (SIREN, SIRET, participant ID). It explains the 'Not registered' paid answer versus free/404 scenarios. However, it doesn't explicitly contrast with sibling tools like invoice_validate or preflight_supplier, though the paid-vs-not-paid distinction provides useful 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?

No annotations are provided, so the description carries full burden. It discloses the paid nature, unbilled behavior on unknown SIREN (404, no empty report billed), the Luhn check (400 on typo), offline mode when 'vat' is dropped, and per-block provenance. This is rich behavioral detail, though it doesn't describe output format or whether the report is synchronous.

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 dense and front-loaded with the core value proposition, then pricing and docs. Every sentence earns its place covering purpose, scope details, use case, and commercial terms. Slightly more verbose than strictly needed but each clause adds useful information.

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

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

For a single-param tool with 100% schema coverage and no output schema, the description is quite complete. It covers what data is returned, error behavior, pricing, and use-case guidance. Could add output format/timing, but the tool is sufficiently scoped that the description is nearly complete.

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

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

Schema coverage is 100% and the single parameter (siren) is well-documented in the schema itself with Luhn-check, error codes, and optional include flags. The description doesn't add meaning beyond what's already in the schema, meeting the baseline 3 for full 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 states a specific verb+resource: 'Full counterparty due-diligence on a French company... by SIREN' and enumerates the exact data blocks (Sirene, BODACC, VIES, Peppol). It clearly distinguishes itself from sibling tools like company_vat, company_events, company_peppol which each cover single data sources.

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

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

The description explicitly states when to use it: 'The pre-action check before you invoice, pay or onboard.' It provides pricing, free trial, documentation link, and the alternative to use individual company_* tools implicitly by covering a superset. It also notes there's no account/key needed as an onboarding guide.

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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: data source freshness (monthly snapshot), no authentication required, and pay-per-call pricing with a free daily trial. It also implies a read-only verification operation. It does not explicitly state that it is non-destructive, but the 'verify' verb and the listing of returned fields make this clear.

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-organized paragraph that leads with the core purpose, then lists data fields, source, lookup method, and finally pricing/docs. Every sentence adds some value, though the pricing and docs link could be considered tangential for an AI agent. It is appropriately sized and front-loaded with the most critical info.

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

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

The description covers the business context, source, and expected outputs, and the schema provides error handling information. However, the unresolved SIREN/SIRET ambiguity is a significant gap: an agent cannot confidently construct the correct request. Additionally, with no output schema, the description lists returned fields but does not describe the response structure or format. This is a simple tool, so it does not require extensive documentation, but the contradiction prevents full completeness.

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 schema already provides a detailed description for the single parameter 'siren' (including error codes for malformed input, Luhn checksum, and 404 handling), so baseline coverage is high. However, the description's claim 'Lookup by SIREN or SIRET' actively contradicts the schema, which only defines 'siren' as the sole required parameter and does not include a 'siret' property. This misleading statement could cause an agent to attempt invoking a non-existent 'siret' parameter or to pass a SIRET in the 'siren' field, undermining correct invocation.

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 with a specific verb ('Verify') and resource ('a French company'), enumerates the returned data fields (legal name, status, legal form, NAF, workforce, creation date, address), and identifies the authoritative source (INSEE Sirene register). It distinguishes itself from sibling tools like company_vat or company_report by focusing on official register verification for pre-invoice/pay/onboarding use cases.

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: 'before you invoice, pay or onboard it', which tells the agent when this tool is appropriate. It also specifies the lookup method (by SIREN or SIRET) and the official register. However, it does not explicitly mention alternative tools or when not to use this one, so it falls short of the highest bar.

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?

No annotations are provided, so the description carries the full burden. It discloses honest 'unverifiable' result handling when the member state is down, syntax check always included, no account/key needed, and importantly documents that there is no 404 response. The pricing and trial info is bonus transparency.

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?

Well organized with the main capability in the lead sentence, then return behavior, then pricing, then docs link. The pricing and docs URL are arguably peripheral to tool selection but useful metadata. No redundancy or 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?

This is a single-parameter validation tool with no output schema and no annotations. The description covers purpose, return semantics (valid/invalid/unverifiable), error behavior (400 codes, no 404), authentication needs (none), and the dual-input model. Exceptionally complete for a simple 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 coverage is 100%, but the description adds substantial meaning: explains 'vat' vs 'siren' exclusivity, both accepted formats (XI, EL), the derived_from_siren tracing, and specific 400 error codes (INVALID_INPUT, INVALID_CHECKSUM) with likely-typo interpretation. This goes well beyond schema descriptions.

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

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

Description states a specific verb+resource: 'Validate any EU VAT number live against the official European Commission VIES service' — very specific about what it checks and the live/official nature. It also mentions the secondary SIREN-to-FR-VAT derivation capability, distinguishing its unique value from siblings like invoice_vat_treatment.

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 says 'before you invoice cross-border' giving clear business context for when to use it. However, it doesn't explicitly name alternative tools (e.g., invoice_vat_treatment) or state when NOT to use it, only implying the cross-border invoicing trigger.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that this is a paid tool ($0.01 per call) and mentions first-call-free trial and documentation. However, it doesn't disclose what happens on failure (e.g., if check digits can't be recomputed), the format of the returned candidates, or any rate limits. The pricing disclosure is useful transparency beyond what annotations would provide, but the description is silent on failure modes and return structure.

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 efficient, front-loading the core use case ('Before your agent pays an IBAN... fix a broken or garbled IBAN') then detailing capabilities. The pricing and doc lines are useful but arguably squeezed into the same description field rather than being cleanly separated. For a single-paragraph description it's well organized with a natural flow from use case to capabilities to logistics.

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 single-parameter, no-output-schema tool, the description covers the input use case well. However, the tool has meaningful complexity (check digit recomputation, candidate ranking by bank registry) that begs for some disclosure of expected output format or failure behavior. With no output schema and 0% schema coverage, the description should compensate more. The what-it-does is well specified, but the what-happens-next (return format, error semantics) 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?

There is only 1 parameter (iban) with 0% schema description coverage. The description implies the 'iban' parameter can contain unreadable characters (?), which adds semantic meaning beyond the bare string type in the schema. However, it doesn't specify the expected format of the input beyond implication (OCR-derived), nor whether the ? character has a special meaning that must be preserved exactly in the input. The description adds a bit of value but doesn't fully compensate for the 0% schema coverage gap.

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

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

The description clearly states the verb (fix/repair), the resource (IBAN), and the specific context (broken or garbled IBAN from OCR or invoice ingestion). It details what the tool does: recompute check digits, recover unreadable characters, and rank candidates by known bank. The purpose is specific and distinguishes itself from siblings like iban_screen (screening) and iban_resolve (resolving).

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 when-to-use context: 'Before your agent pays an IBAN taken from OCR or invoice ingestion.' This establishes the use case clearly. It doesn't explicitly name when NOT to use it or name alternative sibling tools, but the context signal is strong enough that an agent could infer when iban_screen (vetting) or iban_resolve would be the alternative. The OCR/ingestion pointing is specific and actionable.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It covers the 'never charged' on rejection, the repair-effort budget constraint, and the pricing model ($0.005 base + $0.005 × N). It explains the recovery capabilities (check digit recomputation, unreadable character recovery, bank ranking from registries). It doesn't describe the return format, but the main behavioral traits are 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 a reasonably compact paragraph with useful front-loaded usage context and a separate pricing/docs line. It's slightly dense with multiple clauses in one long sentence, but the key behavioral and cost information is conveyed efficiently. The '?' quotes insertion mid-sentence is a minor structural hiccup.

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 batch mutation tool with no annotations and no output schema, the description provides good coverage: the error/handling behavior (400 on budget exceed), the max batch size (500), the pricing model, and the recovery capabilities. Gaps include the return format/structure (no output schema exists) and what happens to successfully repaired vs unrecoverable items, but the essential context for correct invocation is present.

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

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

Schema coverage is 0% (the 'ibans' parameter has no schema description), so the description must compensate. The description does provide context about the ibans field (up to 500 items, '?' as unreadable character marker, budget implications tied to the number of items). However, it doesn't explicitly describe the format expected for each IBAN string beyond the '?' marker, and the details are somewhat spread throughout the prose rather than being param-focused. Given the 0% schema coverage and single simple param, this is reasonably good compensation.

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 fixing broken/garbled IBANs in batch, with a specific scope (up to 500 items before a payment run over OCR/invoice data). The verb 'fix' + resource 'IBAN batch' distinguishes it from siblings like iban_repair (singular), iban_screen (validation/checking), and iban_resolve (resolving).

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

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

Explicitly states when to use: 'Before a payment run over OCR or invoice data'. It also provides concrete guidance on recovery behavior: if the batch budget is exceeded it returns 400 BATCH_BUDGET_EXCEEDED and is not charged, advising to send fewer IBANs or fewer '?' per IBAN. This gives clear operational guidance on how to use the tool correctly.

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?

No annotations are provided, so the description carries the full burden. It does disclose geographic coverage (all countries, SEPA and non-SEPA), reference registries used (national bank registries, EPC register), and scheme checks (SCT, SCT Inst, SDD Core/B2B). However, it omits return format, error behavior (e.g., for invalid IBANs), and any rate-limit constraints beyond the flat pricing note. Useful but incomplete behavioral detail.

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

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

The core functional description is a single dense sentence that packs the full scope. The pricing, trial, and docs-link lines are somewhat off-topic for behavioral guidance but are compact and easily skippable, so they don't significantly harm conciseness.

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 should note what is returned — it mentions what is resolved (bank, BIC, SEPA scheme reachability) which implies the output. For a single-parameter tool with full schema coverage, the description covers the functional scope well. It could state response shape/error handling, but the listed registries and scheme checks sufficiently frame expected results for an agent.

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% for the single 'iban' parameter, and the description adds meaningful context that the IBAN can be from 'any SEPA or non-SEPA country' and that spaces are tolerated. The description reinforces the parameter scope even though the schema already documents the tolerance for spaces.

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 clear verb+action ('validate the IBAN'), resource (all countries), and specific multi-step outcome (resolve bank/BIC, check SEPA reachability per scheme). It clearly distinguishes from siblings like iban_screen and iban_repair by naming the resolution and reachability aspects.

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 concrete use-case trigger ('Before your agent pays a new bank account'), which effectively tells when to use this tool. It doesn't explicitly name alternatives/exclusions, but the 'before paying' context clearly scopes it as a pre-payment validation step rather than repair or screening.

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?

No annotations are provided, so the description carries the burden. It discloses the maximum batch size (500), pricing structure ($0.005 base + $0.005 × N), and the field name ('ibans'). It does not disclose what happens on mixed valid/invalid input, error behavior for the max limit, or response format, which would be valuable for a validation tool. However, the core behavioral facts (limits, cost) are 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 compact and front-loaded with the core purpose in the first sentence, followed by pricing and docs in two additional lines. Every sentence adds value. The pricing and docs info could arguably be moved out of the description proper, but it's still efficiently presented.

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's no output schema, the description doesn't explain what results look like or how to interpret failure states, and it doesn't address batch error handling for a tool that validates up to 500 items. It covers purpose, limits, and cost well, but the absence of mention of return format or per-item vs batch-level failures is a gap for a tool that could produce partial 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?

With 0% schema description coverage and only one parameter (ibans), the description partially compensates by naming the field and stating the max 500 items. The description adds the count/limit context that the schema alone doesn't provide. However, it doesn't explain the expected format of array items (raw IBAN strings, format variations) or batch splitting strategy.

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

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

The description clearly states the verb+resource: 'validate up to 500 IBANs', resolving bank/BIC, and checking SEPA reachability. It distinguishes from sibling iban_resolve (singular/batch distinction) and iban_screen (screening vs resolution) by specifying the batch context ('Before a payment run') and the SEPA scheme checks.

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

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

The description gives a clear usage context ('Before a payment run') and specifies capabilities (validate, resolve bank/BIC, check SEPA reachability) that distinguish it from iban_screen and iban_repair siblings. It doesn't explicitly state when NOT to use it (e.g., use iban_resolve for single items), though the batch naming makes that reasonably inferable.

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 tool's screening behavior (checks BIC and jurisdictions against official lists) and its purpose. It omits operational specifics such as whether the results include a pass/fail status, risk scores, or recommendation output — with no output schema and no annotations, the agent is blind to the response format. However, the core behavioral contract (screening against sanctions lists) is stated clearly.

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 reasonably concise: a single framing sentence covering purpose and compliance context, plus pricing and docs links. The price and trial info add practical value for cost-sensitive agents. It's front-loaded with the when-to-use framing. Slightly more verbose than necessary with the pricing block, but each part serves a purpose for an agent deciding whether to invoke this 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?

For a simple single-parameter screening tool, the description is mostly complete. It establishes the compliance context, what's screened, and against which lists. However, with no output schema and no annotations, the agent has no idea what the response looks like — does it return a boolean, a risk score, a list of matches? This gap matters for an agent that must interpret results. It also doesn't mention edge cases like non-European IBANs or invalid IBAN format handling.

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?

With only 1 parameter (iban) and 0% schema description coverage, the single parameter is entirely undocumented. However, the parameter name 'iban' is semantically self-evident — an IBAN string — and the description already indicates it's a bank account being screened. The description adds context about what the screening covers (BIC, jurisdiction), which enriches the meaning of the input. For a single self-explanatory parameter, the description compensates adequately.

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 screens an IBAN for sanctions, flagging sanctioned banks and high-risk jurisdictions against OFAC/EU/UN/FATF lists. It's a specific verb+resource with concrete scope. While it doesn't explicitly differentiate from siblings like iban_resolve or iban_repair, the purpose is clearly distinct given the sanctions focus and the 'screen' verb distinguishes it from 'repair'/'resolve' siblings.

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 it: 'Before your agent onboards or pays a counterparty.' It's framed for KYB/AML compliance scenarios. It doesn't explicitly mention when NOT to use it or name alternative tools, but the compliance context is well-established and distinct from sibling tools like iban_resolve (which likely resolves IBAN details).

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?

No annotations are provided, so the description carries the burden. It discloses pricing, the 500-item maximum, and the field name ('ibans'), which is genuinely useful operational context. However, it doesn't disclose what the response shape looks like, failure modes for invalid IBANs, or compliance context beyond naming lists. For an unannotated tool, moderate disclosure 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?

Three compact sentences with high information density: purpose, databases, pricing, max items, field name, docs link. Front-loads the purpose. The pricing formula and docs URL add real value without bloat. Could be trimmed slightly but 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?

Single-parameter tool with no output schema and no annotations, so the description must carry a lot. It covers purpose, compliance scope, limits, pricing, and a docs reference. It doesn't describe the output format (matches, risk flags, result structure), which is a notable gap for an unannotated tool with zero output schema, but for a relatively simple batch screening description the coverage is solid.

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

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

Schema coverage is 0% and there is only one parameter ('ibans'). The description compensates by naming the field, specifying the 500-item max, the array-of-strings nature implicitly, and providing a pricing formula tied to N items. This adds meaning (limits, cost) well beyond the bare schema. Slight credit held for not stating that each array element should be a standard IBAN string.

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

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

Clear verb+resource+scope: 'Screen a list of IBANs' for sanctioned banks/high-risk jurisdictions against named official lists (OFAC, EU, UN, FATF). Distinguishes from sibling 'iban_screen' by the batch nature and explicit 500-item cap in one call. Title adds context (sanctions).

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?

States the use case ('Before onboarding or a payment run') and explicit list sources/databases. It doesn't explicitly contrast with the sibling 'iban_screen' single tool, but the use-case framing plus the 500-item batch distinctiveness provides clear context. Slight gap: no explicit 'when not to use / use iban_screen instead' 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?

No annotations are provided, so the description carries the full disclosure burden. It does disclose key behaviors: outputs auto-computed totals, rejects inconsistent inputs with field-level errors, never silently repairs totals (code inconsistent_totals), enforces implausible identifiers via Luhn checks, and re-validates the document before serving. It also reveals pricing, rate limits, and that no account/key is required. This is thorough, though it could disclose the exact response structure.

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 dense and information-rich but quite long and sprawling, with configuration details (syntax, ruleset, electronic_address constraints) packed into what is effectively one long paragraph under invoice_number. It front-loads the core purpose well, but the structure becomes hard to scan—some critical behavior (re-validation, BR enforcement) is buried mid-sentence. A more structured breakdown of options would improve scannability without losing substance.

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

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

For a complex tool with 8 required params, nested buyer/seller/line/payment objects, and no output schema, the description adds rich detail about validation behavior, EN 16931 BR rule enforcement, rounding, identification checks, pricing, and ruleset options. It covers most semantic gaps. It doesn't describe the XML response structure (which, absent an output schema, would be helpful), but overall it is remarkably complete for such a complicated tool with zero annotations.

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 50%, and the description meaningfully compensates for the gaps. It explains semantic details the schema doesn't: that qty x unit_price computes net per line with EN 16931 rounding, that document totals and VAT breakdown are auto-computed, the optional totals object verification behavior, the IBAN Mod-97 checksum, the VAT category codes (BT-151, S/Z/E/AE) with BR rule enforcement, EAS scheme requirements for peppol, and the implausible_currency restriction on XXX/XTS beyond what BR rules state. This adds substantial value beyond the raw 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 generates a conformant EN 16931 e-invoice in CII XML (or UBL), and it names the concrete output formats, profiles (Factur-X, Peppol BIS), and legal mandates. It distinguishes itself from siblings like invoice_validate and invoice_generate_pdf by its conversion/generation role producing a conformant XML document.

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 lists when to use this tool (generating conformant XML), what inputs it takes (simple business JSON), configuration alternatives (syntax=cii vs ubl, ruleset=peppol), and even cross-references the sibling tool /company/resolve for party verification. It explains output format selection and the Belgium/French mandates that trigger usage, giving clear when-to-use guidance relative to 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does this well: states totals are computed for you, inconsistent inputs rejected with actionable field-level errors, optional vat_treatment writes compulsory legal mention, embedded XML re-read byte-for-byte, pricing ($0.01/call, first free). It does not explicitly state the operation is non-destructive, but as a generator returning a document the safety profile is reasonably clear. Could add what the response structure is, but 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?

The description is moderately long but front-loaded with the core purpose in the first sentence, then compliance credibility, then behavior/pricing links. Every sentence adds value (regulatory context, reliability claims, error behavior, pricing). Slightly dense with jargon (EN 16931, BT-151, BR-S/E/AE/Z, PDF/A-3B) but that's appropriate for the audience. Could be trimmed slightly but no wasted prose.

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 high complexity (8 required params, nested objects, no output schema, no annotations, French regulatory mandate), the description is remarkably complete: it covers input validation specifics, error codes, rounding behavior, VAT treatment, pricing, and links to docs. It addresses most operational concerns an agent would have. Minor gap: no declaration of what the response/return value looks like, and the tax-timing/legal caveats are only lightly touched, but for a document-generator the coverage is strong.

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 only 50%, so the description must compensate. It does substantially: currency explains implausible_currency restrictions beyond BR-CL, issue_date explains invalid_date on real-calendar checks, invoice_number covers INVALID_INVOICE_INPUT/typo refusal and 10MB limit, lines explains EN 16931 rounding and inconsistent_totals rejection, iban explains Mod-97 and BG-16 mapping, seller legal_id explains Luhn and implausible_identifier. The remaining ~50% of params (buyer, payment base, due_date base fields) are adequately covered by schema structure. Strong compensation for the coverage gap.

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+resource ('Generate a complete Factur-X hybrid invoice: post simple business JSON... get a PDF/A-3B document with the EN 16931 CII XML embedded'). It clearly distinguishes from the sibling invoice_generate tool (identical business JSON) by highlighting the PDF/XML hybrid output, regulatory mandate, and official rule-set compliance. The purpose is unambiguous and differentiated.

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 states when to use it: to get a PDF that IS the structured e-invoice mandated by the French 2026-2027 reform, for the French compliance context. It references alternatives implicitly (invoice_generate for the JSON form, invoice_validate for validation, invoice_read for reading) and explains the no-account/no-key low friction. However, it doesn't explicitly say when NOT to use this vs those siblings, so exclusions are missing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so richly. It reveals period-by-period tranche computation ('the reference rate changes every 1 January and 1 July'), national margin details (FR 10, DE 9), currency handling (NO conversion, total_due null outside euro), country coverage (FR/DE/ES/IT/NL/BE/PT/PL plus explicit EU-minimum fallback), refusal behavior (third country refused), date bounds (date_out_of_range), and pricing ($0.01/call, free daily trial). It even discloses that a term beyond the 60-day cap is computed as supplied rather than refused—substantial transparency.

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 dense and front-loaded with the core value proposition, then layers in edge cases and disclaimers. Every sentence adds operational information—the only minor deduction is that the pricing and docs block, while useful, couples business pricing with tool semantics, and a couple of behavioral details (NBP for Poland, half-point Belgian rounding) could arguably belong in schema or docs rather than the headline description. Still, it's tightly written with zero 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?

Despite having no output schema and a moderately complex parameter space (5 required params), the description fully specifies inputs, outputs (total_due, flat_fee, day_late, rule_source), behavior under every edge case (on-time, out-of-range dates, term beyond cap, third-country, non-euro), and fallback logic. The legal citation (art. 3(1), art. 6, art. 7) and country rules are all disclosed. Nothing essential is left underspecified for a computation of this complexity.

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

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

Schema coverage is 80%, with 4 of 5 parameters carrying rich descriptions. The description adds meaning beyond the schema by explaining the due_date alternatives (invoice_date + payment_terms_days), the statutory default behavior, the date_out_of_range bounds, the paid_date 'on-time is valid' semantics, and the optional contractual_rate override logic. currency's XTS/XXX refusal and total_due-null behavior are explained. Only plain 'currency' and the un-parameterized extras are not enumerated as separate fields, but the description covers them inline.

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+resource ('Compute late-payment interest and recovery compensation') and scopes it precisely to EU Directive 2011/7 for unpaid B2B invoices. It distinguishes itself clearly from sibling tools ('Before your agent sends a dunning letter or books a receivable: what is legally due on an unpaid B2B invoice') and is distinct from the invoice_* family which handles validation/generation/reading per the sibling list.

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

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

The description explicitly states when to use the tool ('Before your agent sends a dunning letter or books a receivable'), what inputs to provide, and clarifies edge cases like 'Paying on time is a valid answer, not an error' and 'a national rule is never guessed.' It distinguishes from the broader invoice_* and legal_* tools by positioning it specifically as the late-payment computation endpoint.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose key behaviors: rejection of scanned PDFs (400), max body size of 10 MB (413 error), no OCR, and no account needed. However, it omits details like whether pricing limits apply per-response, error codes beyond HTTP status, and any rate limits or authentication behavior beyond billing.

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 with the core value proposition in the first sentence. Format coverage and data returns are listed efficiently. The trailing pricing/docs lines are necessary commercial context. Minor room for improvement: the pricing and trial details could be separated from the behavioral 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?

Despite missing an output schema, the description explicitly enumerates the returned data fields (parties with identifiers, line items, VAT breakdown, totals, IBAN, due dates), which is genuinely rare and useful. Combined with the schema documenting the single input and error behaviors, this is reasonably complete for a single-parameter read endpoint. Slight gap: no explicitly stated response format (JSON shape) or pagination, but acceptable for this tool type.

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% for the single document_base64 parameter, and the description adds meaningful format details (Factur-X/ZUGFeRD PDF, CII D16B, UBL 2.1) and the raw-bytes alternative transport method. However, since there's only one parameter and the schema already documents it thoroughly, the description adds value but the schema does most of the work — 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 uses a specific verb+resource combination ('Read any EU structured e-invoice') and explicitly lists the covered formats (Factur-X PDF, CII, UBL XML) and the data types returned (parties, line items, VAT breakdown, IBAN, due dates). It clearly distinguishes from siblings like invoice_validate, invoice_generate, and invoice_vat_treatment, and names the regulatory context (French 2026-2027 reform, EN 16931).

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 on when to use the tool (posting structured e-invoices) and what is NOT supported (scanned/image PDFs rejected with 400), preempting misuse. It doesn't explicitly name alternative sibling tools for comparison, but the rejection of non-XML PDFs and OCR-less framing implicitly scopes its usage clearly.

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?

No annotations were provided, so the description carries the full burden. It discloses several behavioral traits: deterministic verdicts (no LLM guesswork), paid (non-conformant invoices are paid, documented answers), pricing ($0.01/call), and error conditions (400 for unknown ruleset, 413 for body over 10MB, 200 with invalid verdict for CII+peppol). It's reasonably transparent but doesn't disclose behaviors like rate limits, authentication requirements, or latency expectations.

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 dense and information-rich but quite long, spanning the main description plus the single-paragraph parameter description. While every sentence carries meaningful content (formats, rulesets, side effects, pricing, limits), the density makes it harder to skim. The front-loaded content is good (purpose stated first), and there's no waste, but the length is substantial for a single-parameter tool.

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

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

Given the complexity of the tool (multiple formats, ruleset layers, profile options, error semantics), the description is thorough. No output schema exists, so it partially compensates by describing return content (verdicts, BR rule violations with observed/expected values, VAT checks separated from normative ids). It covers the key user decisions (which ruleset, which profile, JSON vs raw POST) and error states. It's substantively complete for an agent to invoke this tool correctly.

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

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

Schema coverage is 100% for the single parameter, so baseline is 3. The description adds substantial meaning beyond the schema: how to encode the document (base64 standard alphabet, whitespace tolerated), alternative POST raw-bytes approach with specific content-types, accepted formats (PDF/A-3, CII D16B, UBL 2.1), body size limit (10MB, 413 beyond). The query parameters (profile, ruleset) and their values and semantics are also richly documented, going well beyond what the schema alone 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 clearly states the verb ('Validate an e-invoice against EN 16931') and resource, plus the expected input formats (Factur-X PDF, CII, UBL XML) and core outputs (XSD conformance, BR rule violations, profile consistency, syntax checks). It distinguishes from many siblings in context (invoice_generate, invoice_read, invoice_late_payment, etc.), though it doesn't explicitly name an alternative for sibling differentiation.

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 substantial context on when to use this tool: to accept or reject an invoice, mandated by French 2026-2027 reform. It also explains query parameters for rulesets (xrechnung/peppol) and profile (strict/declared). However, it doesn't explicitly state 'when NOT to use' or contrast with sibling tools like invoice_read or invoice_generate, though it does note it rejects scanned/image PDFs (no OCR).

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?

With no annotations provided, the description carries the full burden, and it does substantial work: it discloses that the customer VAT number is taken AS DECLARED (zero network), that early dates return 400 (never extrapolated), that overflowing amounts are 400 (never 5xx), that undefined supply kinds are refused rather than defaulted, and that uncovered regimes return as motivated undetermined never a plausible default. It also states error-shape behavior in several places. The only gap is no explicit statement about read-only/non-mutating behavior or output structure, though those are partly implied.

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 dense and packs a lot of genuinely useful information into a compact space: use context, coverage limits, error behavior, cross-tool links, and pricing. Every sentence carries operational content. However, some redundancy exists with the schema (e.g., date explanation partly repeats the schema's description), and the content is front-loaded well with the strongest guidance first. A slight trim on points already covered by the schema would earn a 5.

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 9-parameter tool with no output schema and no annotations, the description is remarkably thorough: it covers when to use, what inputs mean, edge cases (third territories, Monaco), error behavior, uncovered regimes, and where to get live verification. It compensates well for the missing output schema by describing the return contents (place of supply, person liable, rate, invoice mentions). The only notable omission is explicit mention of reading/mutation implications and the exact output response structure, but coverage is otherwise strong.

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 67%, leaving three parameters (currency, customer_type, customer_country) without schema descriptions. The description compensates for some: supplier_country gets rich detail on formats (EL for GR, Monaco=FR, overseas territories). However, customer_type's values (business|consumer) are only explained in the transaction_type description, and currency's ISO 4217 constraint appears only in the amount text rather than its own parameter. Good compensation overall but slightly fragmented across parameter cross-references.

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 very specific verb+resource: it determines the VAT treatment of a cross-border transaction, naming who charges VAT, under which mechanism, place of supply, and invoice wording. It distinguishes itself clearly from siblings like invoice_validate, invoice_generate, and company_vat by referencing the reverse-charge mention gap and the live verification option. The opening line sets scope precisely (EU, Directive 2006/112).

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 explicit when-to-use guidance ('Before your agent issues or books a cross-border invoice') and links to sibling tools for what this tool cannot do: live VAT verification is delegated to /company/vat, invoice-schema validation to /invoice/validate. It also explicitly names uncovered regimes (OSS/IOSS, import VAT, margin schemes, triangulars) that come back as undetermined, so the agent knows when this tool is NOT the answer. This is exemplary alternative/context 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?

No annotations are provided, so the description carries full burden. It discloses several important behaviors: malformed items are reported at position instead of failing the batch, empty/oversized batches return 400, prices are pegged to item count, and unfamiliar regimes return as 'motivated undetermined, never a plausible default'. This is substantial behavioral disclosure beyond 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?

The description is information-dense and mostly well-organized, front-loading the core purpose and mechanisms, then caveats and pricing. It's a longer paragraph but every sentence adds unique value. Minor redundancy with the schema on pricing/cap details, but the structure is effective for a batch tool with many caveats.

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

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

The tool is complex (nested items, 1 param with 100% schema coverage, no output schema). The description compensates well: it details verdict types, error behavior, pricing, verification caveats, and uncovered regimes. Could add what the summary response contains in more concrete terms, but for a no-output-schema batch tool it is reasonably complete.

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

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

Schema description coverage is 100%, with the items parameter itself having a rich description covering semantics of each nested field, enums for transaction_type/supply_kind, pricing, and size cap. The description adds the verdicts and mechanism counts as extra context, but parameter meaning is largely already carried by 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 judges up to 200 transactions for VAT treatment in one call, enumerating the specific determinations (place of supply, person liable, standard VAT, reverse charge, etc.). It explicitly distinguishes from the sibling invoice_vat_treatment by framing this as a batch version with shared settlement, and mentions the five mechanism counts and per-line rate in force.

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 conveys when to use this (batch of up to 200 transactions) and notes key behaviors: customer VAT numbers are taken as declared and should be verified with /company/vat, uncovered regimes return as 'motivated undetermined'. It does not explicitly name exclusions versus the sibling single-call tool beyond the batch context, but the usage context is clear.

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?

With no annotations, the description carries the full burden. It discloses pricing, a free trial, ATP versioning behavior, the inclusion of upcoming changes, and the explicit self-classification verdict for substances absent from Annex VI. It does not mention authentication or rate limits, but the provided behavioral details are substantial and useful.

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 use case and packs many specific details into a moderate paragraph. The price and docs link add extra, but arguably useful, context. It is not overly verbose, though it could be restructured slightly for scanning.

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

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

Without an output schema, the description adequately summarizes the return content (hazard classes, H statements, pictograms, signal word, concentration limits, ATP versions, upcoming change) and the absence verdict. It also covers pricing and trial behavior. The main missing piece is a clear statement of output format, but the listed data fields provide enough for 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?

The input schema covers CAS and date, but the tool description introduces EC number and exact name as alternative identifiers that are not present in the schema. Additionally, the schema marks 'at' as required while its description calls it optional, and the CAS description says to provide exactly one key among cas/ec/name even though ec and name are not defined. This ambiguity undermines correct invocation.

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 gets a substance's harmonised CLP classification and enumerates specific data elements (hazard classes, H statements, GHS pictograms, signal word, concentration limits, ATP versions). It also specifies the regulatory scope (Annex VI, CLP, ECHA), distinguishing it from sibling tools like label_chem_svhc and batch variants.

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 frames when to use the tool: 'Before your agent approves a substance for an EU label or safety data sheet.' This is clear contextual guidance, though it does not explicitly mention when not to use it or point to label_chem_classify_batch for multiple substances.

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?

No annotations are provided, so the description carries full burden. It discloses key behaviors: partial-failure handling (malformed item flagged at position instead of failing the batch), pricing model, max batch size, and the date-evaluation semantics. The only minor gap is not describing exact return/response format, but with no output schema the coverage is otherwise strong and accurate.

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 moderately sized but every sentence earns its place. It front-loads the core purpose, then adds pricing, docs link, and error semantics. The pricing line and docs URL are useful but could arguably be trimmed; however they're relevant for a paid tool. Reads efficiently without 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 2-parameter tool with 100% schema coverage and no output schema, the description is quite complete. It covers acceptance criteria, error handling, navigation keys, and pricing. The only shortfall is not detailing the response structure (returned verdict fields), but since the description already enumerates the intended output fields (H statements, GHS pictograms, signal word, ATP), this is adequately covered.

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

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

Schema coverage is 100%, so both parameters (at, items) are documented in the schema. The description adds meaning beyond the schema: it explains the 'at' single-date evaluation semantics ('a BOM is assessed at a single date') and clarifies the items pricing/error behavior. Slight duplication exists (schema already explains the 400 error, item key constraint), but the description does add the pricing-per-unit and batch-capping context.

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 a specific verb+resource: 'screen up to 200 substances in one call against Annex VI of the CLP regulation (ECHA)', with clear deliverable detail (verdict per item with H statements, GHS pictograms, signal word, ATP version). It clearly differentiates from sibling label_chem tools (svhc, claims_check, food_additive) by specifying the CLP Annex VI classification 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?

Opens with explicit when-to-use guidance: 'Before your agent clears a BOM or a formulation for the EU market'. Also specifies the query keys (CAS, EC number or exact name), error handling semantics (malformed item flagged at position, unlisted substance gets explicit self-classification), and the single-date evaluation constraint via the 'at' parameter. This is genuinely useful operational 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?

No annotations are provided, so the description carries the full burden. It discloses the pricing behavior ($0.01/call, first call free), the billing-on-not-listed behavior, that results are dated to the served list, and the semantic caution that absence doesn't mean no concern. It doesn't discuss auth/rate limits but covers the meaningful behavioral nuances for this paid-check tool.

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 information-dense but front-loaded with the purpose statement, then delivers usage context and return-value specifics efficiently. The pricing/docs lines are slightly tangential for agent tool selection but earn their place given they're compliance-relevant billing signals. Structure flows purpose → usage → behavior → caveats.

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 single-parameter lookup tool with 100% schema coverage, the description is thorough. It explains return semantics, obligations triggered, and caveats on the not-listed verdict. The absence of an output schema is compensated by the description's explanation of what's returned. Minor gap: no mention of response speed or failure/network behavior, but this is a well-covered single-query registry lookup.

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 substantial value beyond the schema: it explains the mutual-exclusivity rule (exactly one key), the checksum validation, the 400 vs 200 response semantics, billing implications, and the UVCB special case where only name works. This meaningfully enriches the single-parameter 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 is specific: 'Check a substance against the SVHC Candidate List (EU)' with clear verb+resource+scope. It specifies the query keys (CAS, EC number, exact name), what's returned (Article 57 inclusion reasons, inclusion date, EC decisions, triggered obligations), and distinguishes a 'not-listed' verdict from an all-clear. This clearly differentiates from sibling tools like label_chem_classify_batch and label_claims_check.

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

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

The description explicitly states when to use this tool ('Before your agent clears a substance, an article or a supply-chain declaration for the EU market'), naming the concrete workflow trigger. It frames the purpose against the ECHA/REACH compliance context, and the parameter guidance specifies exactly one key among cas/ec/name with error semantics, distinguishing from batch 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?

No annotations are provided, so the description carries full burden of behavioral disclosure. It does disclose the per-item error handling (malformed items flagged not batch-failing), the pricing model, the max batch size of 200, and the verdict contents (Article 57 reasons, inclusion date, triggered obligations). However, it doesn't disclose details about authentication requirements, rate limits, or the exact response structure beyond listing the verdict 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 rich but front-loaded with the core value proposition and usage scenario. The pricing and docs URL details are useful but somewhat verbose; the pricing formula could arguably be considered secondary to the core tool behavior. Still, each sentence earns its place, covering purpose, usage, pricing, error handling and documentation.

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 batch tool with 100% schema coverage and no output schema, the description is fairly complete: it covers verdict structure, pricing, limits, error behavior, and regulatory context. It could add what the exact output fields look like beyond 'Article 57 reasons, inclusion date, triggered obligations', but for a screening tool this is reasonable. The batch nature reduces per-item complexity.

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

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

Schema description coverage is 100%, so the schema already documents the items array well. The description adds meaningful context: each item takes exactly ONE key among cas/ec/name with checksum validation, the pricing per item, the 200 cap, and empty/oversized batch behavior (400 error). This adds real value beyond the schema's basic array description.

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 very specific verb+resource: 'screen up to 200 substances in one call against the ECHA Candidate List of SVHC (REACH)' with one verdict per item by CAS, EC number or exact name. It clearly distinguishes itself from its sibling 'label_chem_svhc' (singular) by being the batch variant, and provides specific regulatory context (REACH Article 33, SCIP).

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

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

The description explicitly states when to use it: 'Before your agent clears a BOM, a formulation or a supplier declaration for the EU market', and clarifies the batch use-case (up to 200 items in one call) which differentiates from the singular label_chem_svhc sibling. It also explains malformed items are flagged at position rather than failing the whole batch, and not-listed substances get explicit verdicts—useful guidance for expected behavior.

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?

No annotations are provided, so the description carries the full burden. It transparently discloses matching behavior (strict-normalised, never fuzzy, zero false positives), the 400 status for empty/punctuation-only wording, the absence limit note, and the 'on hold' botanicals caveat. It additionally discloses pricing ($0.01/call, first free) and links to docs. Only minor omissions: no stated auth requirements or rate limits explicitly.

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 opens with the purpose in the first sentence and is dense but well-organized. It front-loads the core decision and packs substantial information efficiently. It is slightly long with pricing/docs details, but those are arguably useful context for a paid tool; no wasted prose.

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

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

The tool is conceptually complex (three-way outcome classification, strict matching rules, absence semantics) with no output schema and two params. The description covers the key behavioral aspects thoroughly: matching algorithm, rejection/approval/absence outcomes, errors, nutrient-bound behavior, and absence caveat. Given there's no output schema and no annotations, it does a strong job educating the agent on expected behavior and edge cases.

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 50% (the 'nutrient' param has no schema description). The description compensates well for the 'wording' param by detailing normalisation behavior and the empty-input 400. For 'nutrient', the description clarifies that providing a nutrient bounds the search, an empty nutrient returns 400, and omitting it scans the whole Register-adding value beyond the bare 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 uses a specific verb-checking a claim-with a clear resource (EU nutrition/health claim wording) and explicitly distinguishes three outcomes: authorised, non-authorised (with rejection reason + EFSA opinion), or absent from the EU Register. It clearly differentiates from sibling 'label_claims_permitted' and 'label_chem_classify' tools by naming the regulatory framework (Regulation (EC) 1924/2006).

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

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

Explicitly states when to use: before putting a nutrition/health claim on an EU food label. It also gives strong context on matching semantics (strict-normalised, exact or containment, never fuzzy, zero false positives) and warns about a common pitfall-the Register carries REJECTED claims that plain LLMs wrongly validate. It clarifies absence semantics ('on hold' botanicals are not in the Register).

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?

No annotations are provided, so the description carries the full burden. It discloses several important behaviors: exact legal wording returned, conditions of use, EFSA opinion and legislation output, explicit empty-list handling for rejected claims, the 'on hold' botanical exclusion, and the pricing ($0.01/call, first free). It does not describe auth requirements or rate limits, but covers the key result semantics thoroughly.

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?

Well-structured with a clear opening sentence, then edge-case behavior, then counterpart differentiation, then pricing. It is informative but somewhat long, with the pricing/docs details arguably better placed in structured metadata. Still, every sentence earns its place and it follows a logical flow from purpose to edge cases to differentiation.

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 single-parameter read-only tool with rich edge-case documentation, the description is complete. It covers what the tool returns (exact wording, conditions, EFSA opinion, legislation), how it behaves for rejected vs absent nutrients, what's excluded (botanicals), and how it differs from its counterpart. No output schema exists, so the return-value documentation in the description compensates fully.

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 sole parameter 'nutrient' is well-documented in the schema ('required, absent or empty = 400, strict normalisation, echoes normalised key, no fuzzy search'). The description adds the semantic context that this is the entry key for a claims lookup, reinforcing the schema's 'no fuzzy search' warning. With 100% coverage and a single parameter, the baseline is 3 but the description adds meaningful usage nuance.

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

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

Description uses specific verb+resource: 'List the authorised EU nutrition and health claims for a given nutrient or substance (Regulation (EC) 1924/2006): what your agent may legally write on a food label.' It clearly states what the tool does, identifies the regulatory basis, and distinguishes itself from the sibling tool label_claims_check by stating 'permitted starts from the nutrient' vs 'check starts from a wording.'

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?

Clearly states when to use: pass the nutrient, get every authorised claim. Explicitly differentiates from the counterpart tool label_claims_check ('check starts from a wording, permitted starts from the nutrient'). Also explains edge-case behavior (rejected claims return empty list with count, absent nutrient returns limit note) so the agent knows how to interpret results across situations.

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?

No annotations are provided, so the description carries the full burden. It extensively discloses behavior: returns concentration, conditions, mandatory label wording, versioning by amending regulation, the consolidated version at a queried date, upcoming changes, and the legally non-binding nature of CosIng. It also states that divergence is reported and absence from Annexes is not authorization, plus pricing and docs.

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 long but information-dense. Every clause adds value: use case, legal scope, lookup identifiers, output contents, versioning, legal caveats, pricing, docs. The first sentence effectively front-loads the primary use context, and the structure flows from purpose to behavior to practical details.

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

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

Given the tool's complexity and lack of an output schema, the description provides a solid mental model of the response: every published entry with maximum concentration, conditions of use, mandatory label wording, and version information. It also covers important caveats (absence not authorization, non-binding CosIng, billing). It doesn't enumerate exact JSON fields, but it is sufficiently complete for an agent to know what to expect.

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 descriptions are already rich: CAS/EC/INCI/name resolution, checksum validation, 400/404 behavior, date defaults, and product_type filtering. The tool description adds little parameter-specific detail beyond what the schema already provides, so 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 title and description clearly state the tool looks up an EU cosmetic ingredient's regulatory verdict under Regulation 1223/2009, specifying prohibited/restricted/authorised categories (Annexes II–VI). This distinguishes it from sibling tools like label_food_additive or label_chem_svhc by naming the exact domain and legal framework.

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 opens with the exact use case: 'Before your agent clears an ingredient for an EU cosmetic label.' This gives clear context for when to invoke the tool. It does not explicitly name alternatives or exclusions, but the context is specific enough to avoid misselection among the sibling tools.

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?

No annotations are present, so the description carries the full burden. It discloses error handling (malformed items flagged at position), order preservation, de-duplication behavior, pricing, maximum batch size, and the fact that concentration is not computed. This goes well beyond typical descriptions.

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 long but dense with useful information. It front-loads the primary purpose and then covers limitations, output, and pricing. Each sentence adds value, though it could be slightly more streamlined. The structure with price and docs at the end is logical.

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

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

Given no output schema, the description adequately explains the return format (verdict per item with entries, concentrations, conditions, label wording, and summary count). It covers batch error behavior and limitations. It does not specify exact JSON field names, but that is acceptable for an API 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 coverage is 100%, so baseline is 3. The description adds pricing details and clarifies that 'items' is an INCI list with max 200 and that each item takes one key. It also explains the date evaluates the whole batch, which augments the schema without redundancy.

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

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

The description uses the specific verb 'screen' with a clear resource: a whole INCI list against EU Annexes II-VI. It differentiates from sibling tools by emphasizing batch capability (up to 200 ingredients in one call) and explicitly states it is not a formulation compliance verdict.

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 clearly states when to use: 'Before your agent clears a cosmetic formulation for the EU market' and sets limits (up to 200 ingredients). It implicitly contrasts with the singular tool by highlighting batch processing, and notes when not to use it (no concentration computation). It does not explicitly name alternative tools but provides sufficient context.

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

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

No annotations are provided, so the description carries full disclosure burden. It richly discloses exact behaviors: 'quantum satis' served word-for-word never converted, via_group for grouped authorisations, dated verdicts, in_force_at_date on lines within a Period of application with expired lines flagged never dropped. Slightly minor gap: doesn't explicitly state it's read-only or safe, but the 400/404/not-billed semantics imply safe query behavior. Very strong transparency overall.

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 dense but front-loaded with the core purpose and use case. The first sentence establishes context and the key question; supporting detail layers in error handling, billing, and edge behaviors. Somewhat long but every clause earns its place given the complexity of the EU additive rules. Could be slightly tighter but justified by the domain complexity.

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 3-param tool with no output schema and no annotations, the description is thorough. It covers input constraints, the two distinct output shapes, error codes and billing semantics, date-bound interpretation, and the positive-list framing. The only completeness pinch: it's a dense read, but it does address the pragmatic questions an agent would have (cost, errors, edge cases, 'quantum satis'). No output schema means description carries return-format explanation, which it does well.

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 bar for adding value is high. The description genuinely supplements the schema: it clarifies the exact e_number template with example 'E 160a(i)', explains the one-key-only constraint and off-template 400, elaborates the food_category AS PUBLISHED format with Annex III mapping, and details the shape shift (verdict+authorisations[] vs authorised_in inventory capped at 100). Adds meaningful meaning beyond parameter names and descriptions.

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+resource: 'Check' a food additive in an EU food category, grounded in the Union list (Regulation 1333/2008). Clearly distinguishes from the label_chem_* siblings by focusing on additive authorisation verdicts rather than chemical classification or claims. The scope (Annexes II and III) and what you get back (verdict, maximum level, restrictions, footnotes) are explicitly stated.

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?

Excellent when/when-not guidance: explicitly explains behavior WITH a food category vs WITHOUT one, states the 'provide exactly ONE key' rule, lists error conditions (400 for zero/both/off-template, 404 for unknown E number), and covers billing ($0.01, first call free). Alternative is implicitly different from label_chem_classify_batch by domain focus. Very strong context for agent decision-making.

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

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

No annotations are provided, so the description carries the full burden. It discloses it returns consolidated text, status, and validity dates, and notes pricing ($0.01/call, first call free) and a docs link. It doesn't describe pagination, rate limits, or the output format structure, but for a data-query tool the core behavioral traits are covered. A small deduction for not explicitly stating it's a read-only operation.

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 main description is a focused two-sentence block that front-loads the core function and then adds pricing and documentation. The pricing/docs/URLs are useful operational context that earns their place. No wasted sentences, though the pricing details could arguably be in structured metadata rather than prose.

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 no output schema, the description explains input parameters well (code sliding, date format) and describes the return values at a high level (consolidated text, status, validity dates). The undocumented 'article' parameter is the main gap, and the description doesn't detail the output schema structure. Given no output schema exists and the context signals indicate moderate complexity, the description is reasonably complete but could specify article format expectations.

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 67% (code and date documented, article with only a label). The description adds value by explaining the code parameter resolves against the Légifrance corpus with examples and the full covered list, and clarifies the date format (ISO YYYY-MM-DD, zero-padded). The article parameter remains undocumented in both schema and description — a gap. Since two of three parameters are well explained and the description enriches the coverage, this is above 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 is specific and action-oriented: 'check the article is in force at a given date' with clear scope including 'consolidated text, status (in force / repealed / deferred) and validity dates, from the official Légifrance LEGI dataset.' It clearly distinguishes from siblings (legal_deadline, legal_diff, legal_eu_act, legal_history, legal_transposition) by specifying this is the in-force status check tool.

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 guidance on when to use it — 'Before your agent cites, advises on or drafts against a French law.' It names alternatives among siblings implicitly (the dated status check) and defines the corpus coverage (12 codes). It doesn't explicitly state when NOT to use it versus sibling legal tools, but the purpose is clear enough to guide selection.

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

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

No annotations are provided, so the description carries the full burden. It discloses the pricing model, the max of 50 items, the data sources (LEGI and EUR-Lex), and the consolidation behavior. However, it doesn't state whether the tool is read-only/safe, what happens on errors (e.g., invalid citation format), rate limits, or whether coverage gaps return errors vs empty results. For a commercial data tool this is partial transparency but doesn't cover failure modes or auth requirements.

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 with the use-case ('Before your agent signs off...'), then pricing and docs link. The corpus enumeration is necessary detail given the schema's large coverage list. One minor note is the nested code/date/article structure in refs could benefit from clearer per-field guidance, but the overall structure is efficient and each 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?

No output schema exists, so the description must explain return value expectations — it does so moderately by noting 'consolidated text, status and validity dates per reference'. The parameter format is well-specified with concrete EU URI examples. However, for a paid batch verification tool supporting mixed French/EU formats, it doesn't detail per-item error handling, partial-success behavior, or how date absence is interpreted (current date vs required date). Slightly more completeness would be warranted.

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%, which sets baseline at 3. The description adds value by explaining the mixed French/EU reference format with concrete celex/eli examples (eli=reg/2016/679/oj or the full URI) and explicitly enumerating the covered codes and EU acts, which greatly aids correct parameter construction beyond the bare schema. Pricing formula using 'field refs' reinforces parameter meaning.

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

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

The description clearly states the verb ('check'), the resource ('up to 50 legal citations... in force'), the scope (French LEGI and EU EUR-Lex), and the consolidated output (status, validity dates, consolidated text). It clearly differentiates from siblings like legal_article (single) and legal_eu_act by emphasizing batch processing of up to 50 references in one call.

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 strong context ('Before your agent signs off a contract review or a due-diligence memo') establishing when to use this tool. It names the covered corpus (12 French codes + key EU acts) which helps an agent decide if a citation falls within scope. It doesn't explicitly say when to use legal_article (single) vs this batch version, though the 'up to 50 in one call' phrasing implies volume-based selection. The pricing model provides practical decision context.

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

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

No annotations are provided, so the description carries the full burden. It discloses significant behavioral traits: each weekend/holiday skipped is named, end-of-month and next-working-day rules applied, step-by-step reasoning returned, holiday calendar authority disclosed (official State dataset vs community reference). Pricing and free-first-call are also disclosed. It could add more on exact return format/error behavior, but coverage is strong.

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

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

The description is comprehensive and front-loaded with the core purpose, but it is lengthy. However, nearly every sentence carries real information (regimes, examples, country coverage, pricing, authority sourcing). The examples embedded in the parameter descriptions are valuable. Slight redundancy exists (regime examples repeat the schema's own examples), but it's justified for agent 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?

This is a complex tool with 4 params, no output schema, and no annotations, yet the description handles the full burden: regime semantics with examples, country coverage with refusal behavior, subdivision support, duration bounds, and holiday-calendar authority disclosure. Nothing critical is missing for a well-functioning pricing/legal deadline 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%, so the schema already documents all four parameters in detail. The description adds value beyond the schema by providing worked examples for each regime (2026-05-06 + 5 = 2026-05-11; 2026-01-31 + 1 month = 2026-02-28 rolled to 2026-03-02), concrete zero-padding format guidance for start, and duration unit-bounding rules not explicit in the schema. Baseline 3 is exceeded by these concrete examples.

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+resource (compute a legal deadline/due date) and clearly distinguishes this from siblings like legal_article, legal_diff, legal_history by stating its exact function: computing due dates under explicitly chosen computation regimes. It enumerates all seven regimes unambiguously.

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

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

The description explicitly states when to use it ('Before your agent commits to a filing date, a notice period or a contractual term') and key constraints (regime is required and never inferred from the legal matter). It also documents the country coverage and refusal behavior (400 COUNTRY_NOT_COVERED) rather than computing on a guessed calendar, and notes the pricing/free trial.

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?

No annotations are provided, so the description carries the burden. It discloses the data sources (LEGI and EUR-Lex), the coverage corpus, and pricing behavior. However, it doesn't describe what happens on failure (e.g., article-not-found, no diff, version resolution errors) or response format details beyond 'word-level diff plus unified patch.' The pricing/error-rejection detail for INVALID_RANGE appears in the schema rather than the description, which helps but partially.

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 primary purpose and use case, which is good. However, it packs a large amount of corpus enumeration and pricing details into a dense paragraph without structural breaks, making it harder to scan. The corpus list is thorough but arguably belongs more in docs than the tool 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?

For a tool with 4 params, 75% schema coverage, no output schema, and no annotations, the description does substantial work but has gaps. It covers corpus scope, output type, and pricing, but lacks detail on error/empty-result behaviors, ordering of the returned diff, or what metadata accompanies each version. The legal domain is complex enough that more precision on return semantics would help.

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 75%, so the schema largely documents parameters. The description adds meaningful detail for the 'code' parameter (explaining the EU celex=/eli= alternative syntax and covered corpus), and for 'from' it adds the INVALID_RANGE rejection semantics. However, 'article' has no description and no added semantic context, and 'to' adds little beyond schema. The description adds some value, justifying slightly above 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?

Clear verb+resource: 'see exactly what changed in a French or EU article between two dates' with specific output (word-level diff plus git-style unified patch). Distinctly differentiated from sibling tools like legal_article, legal_history, and legal_deadline by its focus on temporal diffing of legal texts.

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 frames the use case ('Before your agent updates a contract clause or a compliance rule that depends on a law'), giving clear context for when to invoke. It does not explicitly name alternative tools to use instead, though the sibling set makes the distinction reasonably clear. Lacks explicit when-not-to-use 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?

With no annotations provided, the description carries the full burden and does disclose useful behavioral details: the pricing formula ($0.005 base + $0.005 x N), the max-50 limit, date format requirements (strict ISO YYYY-MM-DD zero-padded), the 400 INVALID_RANGE rejection behavior with index quoting and non-billing, and the explicit covered corpus of laws. This is substantial beyond what the schema alone provides.

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 dense but front-loaded with the core purpose, and the schema's refs parameter description carries the detailed reference-format and covered-corpus info. The main description is efficient, though the pricing and docs URL add minor clutter. Well-organized overall.

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 single-parameter tool with 100% schema coverage and no annotations, the description is thorough: it explains the batch capability, both reference formats with examples, date constraints, failure behavior, covered corpus, and pricing. Given no output schema, some return-format detail (beyond mentioning 'word-level segments plus a git-style unified patch') would add completeness, but the core is well covered.

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

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

Schema coverage is 100% so baseline is 3. The description adds meaningful semantics: it explains the two reference formats (French {code, article, from, to?} vs EU {celex or eli, article?, from, to?}), gives a concrete eli example URI, clarifies date requirements, and documents the rejection case. It covers the 'code' field's allowed values by listing the 12 French codes and EU acts, adding real value beyond the plain 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 'a structured diff of the consolidated text — word-level segments plus a git-style unified patch — for up to 50 French or EU article references' with a specific verb (diff), resource (legal articles), and scope (batch, up to 50 items, each between its own two dates). It distinguishes itself from the sibling legal_diff tool by explicitly covering the batch capacity and the 'one call' for multiple references.

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 'before' context ('Before your agent re-runs a contract review or due diligence after time has passed'), which strongly implies the re-review scenario. It doesn't explicitly exclude alternatives or name the single-item legal_diff sibling, but the batch vs. singular distinction is implicit in the 'up to 50... in one call' framing. A clear context without formal 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses pricing ($0.01/call, first free daily), coverage limitations with historical-depth caveats, the applicability vs in-force distinction, and the fact that coverage_window is reported per response. However, it doesn't disclose rate limits, authentication needs, or failure behavior for unsupported acts.

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 somewhat dense but information-dense rather than wasted. It front-loads the primary purpose and usage guidance, then tucks pricing/docs at the end. The celex inline parenthetical is long but technically necessary; it could arguably be trimmed. Overall efficient, though the coverage list repeats within both the description and the schema.

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 no output schema and no annotations, the description is remarkably complete: it covers purpose, when to use, the key conceptual distinction (in-force vs applicable), pricing, coverage, and historical-depth variance reporting. Gaps are minor: no explicit statement about how dates are validated, what happens for non-covered acts, or whether the response includes structured status fields.

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 67% and the description adds meaning beyond it. The celex parameter gets rich context: the ELI fallback syntax, which parts are optional, and which acts are covered. The date parameter's strict format is reinforced in the description context. The article param remains minimally documented in both schema and description, though its meaning is fairly self-evident given the title and force/application focus.

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+resource scope: 'check an act or article is in force at a given date, by CELEX or ELI identifier.' It clearly differentiates from siblings by focusing on force/applicability verification via EUR-Lex, with concrete examples (GDPR, DSA, AI Act, MiCA). The in-force vs applicable distinction adds precision beyond a generic 'legal 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?

Explicitly states when to use: 'Before your agent advises on EU compliance or cites EU law: check an act or article is in force.' It distinguishes the tool's value by explaining 'in force is not the same thing' as applicable, with the AI Act Article 50 concrete example. It also covers which acts are queryable (key EU digital/financial acts) and notes coverage limitations (e-Commerce Directive only from 2024-02-17).

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?

No annotations are provided, so the description carries the behavioral burden. It discloses that statuses (in force, repealed, superseded, deferred) and validity dates come from LEGI and EUR-Lex, and notes pricing ($0.01 per call, first daily free). However, it doesn't disclose output structure, pagination behavior, rate limits beyond pricing, or whether it combines multiple datasets under one response.

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 purpose and use-case, followed by corpus coverage and pricing. It is somewhat long but every sentence earns its place (usage trigger, data source, corpus, pricing, docs link). The corpus enumeration is lengthy but valuable given the code parameter semantics. Slight redundancy between title and description 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?

Given 2 params (one richly documented), no output schema, and no annotations, the description covers the purpose, when to use, data sources, corpus scope, pricing, and the code/eu reference syntax thoroughly. The article parameter ambiguity is the main gap, but the EU reference handling is detailed. Pricing note adds practical value without bloating. Complete for its complexity level.

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 50% (article has no description). The code parameter description is exceptionally rich, adding the corpus coverage list, alternate EU reference syntax (celex=, eli=), and acceptable URL flexibility. However, the article parameter lacks any description beyond its name, so meaning must be inferred. The description compensates reasonably but leaves article underspecified.

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

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

The description clearly states the verb ('detect exactly when it changed' / 'List the version history') and the resource (French/EU legal article version timeline), distinguishing it from siblings like legal_diff (comparing versions) and legal_article (reading a single version). The scope (12 French codes + EU acts) is specific and well-boundaried.

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 opening 'Before your agent relies on a stored legal citation or watches a provision for change' gives explicit when-to-use context, implying use before relying on citations or monitoring for changes. It distinguishes against legal_article/legal_diff siblings by framing this as the timeline/detection tool. Clear stated use case.

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?

No annotations are provided, so the description carries the burden for behavioral disclosure. It does include pricing info and a docs link, and states the data source coverage. However, it doesn't disclose output format, pagination for results, error behaviors for invalid refs, or rate limits. For a read-only listing tool the gaps are moderate, making this adequate 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?

The description is information-dense and front-loaded with the warning about re-certification and portfolio monitoring. The pricing and docs lines are useful. It's slightly long but packed with distinct value pieces (usage context, corpus, format examples, pricing), so no sentence is 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?

Given 100% schema coverage for the single parameter, no output schema, and no annotations, the description compensates well by documenting the corpus, pricing, format examples, and usage context. It doesn't document output shape, but for a listing tool with a well-scoped parameter this is a reasonable level of completeness.

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%, giving a baseline of 3. The description meaningfully adds value by explaining exactly how to format French refs ({ code, article }), EU refs ({ celex or eli, article? }), and example ELI URI formats (reg/2016/679/oj), and enumerates the full covered corpus. This goes beyond the schema and earns a point above 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 verb (list version history), the resource (up to 100 French or EU article references), and the scope (status and validity dates from LEGI and EUR-Lex to detect changed references). It distinguishes the batch version from the single-item sibling legal_history by explicitly noting 'up to 100 ... in one call'.

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 names specific use cases (re-certifying a legal knowledge base, monitoring a portfolio of citations) and specifies the corpus covered (12 French codes, plus GDPR, DSA, AI Act etc.). It doesn't explicitly mention when not to use it versus legal_history, but the batch-vs-single distinction is reasonably implicit from 'up to 100 in one call'. It clearly exceeds the 3 baseline with the explicit use-case 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?

With no annotations provided, the description carries the full burden and handles it excellently. It discloses what is served (a register of notifications, not conformity assessment), states the pricing and free-trial terms, explains the 404-vs-400 billable distinction ('Any other CELEX returns 404 (not billed)'), and covers the non-EEA country handling ('out_of_scope' 200 vs refusal 400). It even explains the deliberate inclusion of UK measures — silencing them 'would make the total lie'. This is rich, honest behavioral disclosure.

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 substantial and information-dense, but it's a single long paragraph that packs in behavioral caveats, pricing, trial terms, and a docs URL alongside the core functionality. While every sentence earns its place, it could benefit from structural separation (e.g., separating the core behavior from pricing/edge-case handling). It's front-loaded with the most important usage guidance, which is good, but the density makes it harder to parse at a glance.

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 2-parameter tool with 100% schema coverage and no output schema, the description is richly complete. It explains both parameters' full semantics, all edge cases (404, 400, out_of_scope, non-EEA), the exact return contents (measure metadata, deadline, lateness gap), the one-line verdict format for omitted country, and even the public-policy rationale for including UK notifications. Nothing material is left unexplained.

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 parameters thoroughly. The celex parameter lists the full covered corpus with specific CELEX numbers and the 404 behavior, and the country parameter explains alpha-2 codes, the omitted-case summary, and out_of_scope semantics. The description adds no additional parameter meaning beyond the schema, but at 100% coverage the baseline of 3 applies; the description's extra context (pricing, 404-vs-400) adds nominal value but not parameter-specific semantics.

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

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

The description clearly states the tool returns national implementing measures a Member State notified to the European Commission for an EU act, listing each measure's act type, title, reference, and dates, plus the transposition deadline and lateness gap. This clearly distinguishes it from siblings like legal_article, legal_deadline, legal_eu_act, and legal_history. The verb 'returns' plus specific resource and scope make the 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 opening sentence gives explicit guidance on when to use this tool: 'Before your agent relies on an EU directive producing effects in a Member State' — and distinguishes in force, applicable, and transposed as three different things. It explicitly covers the omit-country case versus specifying one country, addresses edge cases (non-EEA codes, UK measures), and clarifies what the tool does NOT do ('never an assessment of conformity'). This is exemplary usage 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?

With no annotations provided, the description carries full behavioral burden and delivers richly: 'Honest by design: ANSM only records reported shortages, so the absence of a report is never a stock guarantee' is an essential behavioral caveat. It also discloses billing behavior (absence-of-report responses are billed), market scope limitations, and the no-account/no-key access pattern. No contradiction with annotations since none exist.

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 substantial but front-loads the core purpose in the first sentence, then layers scope, honesty caveat, and pricing. Some redundancy exists between the schema's CIS description and the tool description (both discuss NDC and 400 codes), but each serves a slightly different discoverability purpose. Overall efficient given the complexity.

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 single-parameter tool with 100% schema coverage, the description fully compensates: it covers purpose, market scope, input alternatives, error behavior, billing semantics, honesty caveat, and provides documentation link. No output schema exists, but the description enumerates all possible status values, making the return shape predictable without one.

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

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

Schema coverage is 100% but the description adds substantial value: it explains the exact input formats for cis, the synonym relationship (dci= substance), the NDC behavior (returns an honest FR-only coverage note), and the error semantics (zero/several keys = 400, malformed = 400, well-formed no report = 200). This significantly exceeds what the bare 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 uses a specific verb+resource combination ('Check a medication's availability') with an explicit scope (French ANSM data) and lists the exact status values returned. It clearly distinguishes this from sibling medication tools (medication_generics, medication_report) by focusing on shortage/availability status reports.

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

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

Explicitly states when to use ('before your agent orders or substitutes it'), what inputs are accepted (CIS code or INN/DCI substance or NDC), and clarifies the French-only market scope with the US NDC caveat. Also mentions price and free trial tier, giving complete usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that NDC returns an honest FR-only coverage note, that zero/multiple keys yield 400, malformed keys yield 400, and that well-formed-but-not-genericized returns found:false and is still billed. It also discloses pricing ($0.01/call, first daily call free) and no-account/no-key requirements, which are unusual behavioral traits an agent needs to 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?

The description is front-loaded with the core purpose in the first phrase, then flows through scope, coverage constraints, and pricing. It is two substantial sentences plus a docs link, all useful. Minor redundancy exists between the description and the input schema (both discuss the cis/name/dci/ndc keys and edge cases), making it slightly longer than strictly necessary, but 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?

Given no output schema, no annotations, and a single parameter, the description compensates well by specifying return fields (princeps, role, name, pack price, reimbursement rate), error codes (400 vs 200), billing behavior, coverage scope, and pricing. The main gap is that it doesn't describe the exact JSON response shape or pagination, but for a single-input lookup tool this is adequately complete.

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

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

Schema coverage is 100% (1 parameter, fully described). The description adds significant meaning beyond the schema by explaining the four mutually-exclusive keys (cis, name, dci, ndc), the exactness of each, the French BDPM scope for names, and error/edge-case behavior (zero or several keys = 400, malformed = 400, well-formed not genericized = 200 found:false). This substantially enriches agent decision-making about parameter selection.

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+resource+scope: 'Find the French BDPM generic group of a medication before your agent substitutes or sources it.' It explicitly distinguishes from sibling medication tools (medication_availability, medication_report) by focusing on the generic group, princeps, role, price, and reimbursement rate, and by scoping to French BDPM.

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 signals when to use it ('before your agent substitutes or sources it') and defines the French BDPM scope, explicitly stating a US NDC returns an FR-only coverage note. It does not explicitly name alternatives like medication_availability or medication_report, but the use-case framing ('before substituting or sourcing') provides clear context and exclusions (no US data).

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?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses billing ($0.01/call, first free), no account/key required, the INN bridge for US drugs, the constraint levels returned, and even the 200/400 response semantics. The phrase 'honest coverage of anything that could not be compared' indicates it reports uncompared items, a notable behavioral trait.

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 multi-sentence but dense, leading with the core purpose and then covering input, output, pricing, and a docs link. Each sentence adds key information; minor redundancy with the schema (e.g., '2+ medications' vs '2 to 50 items') is acceptable 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?

Given the tool's complexity (billing, pair evaluation, error cases, no output schema), the description covers the essential behavior: return values, cost model, error behavior, and the US bridge. It also links to full docs, making it comprehensive for a drug-interaction API.

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 describes the items array, key types (cis, ndc, dci, class), and validation rules with 100% coverage. The description adds little new about parameters beyond restating that 2+ medications can be posted; its extra value lies in output semantics and pricing, not parameter semantics. Baseline 3 applies per the high schema coverage.

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

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

The description clearly states the tool checks drug-drug interactions against the authoritative French ANSM thesaurus, with a specific use case ('before your agent acts on a prescription or an order'). It lists input types (CIS, NDC, DCI, class) and output details (constraint levels, management advice, mechanism), distinguishing it from sibling medication tools focused on availability, generics, or reports.

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

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

It explicitly frames when to use the tool: 'before your agent acts on a prescription or an order'. It does not name alternatives, but the sibling tools (medication_availability, medication_report, medication_generics, medication_resolve) are clearly for other medication tasks, so the usage context is clear. No explicit when-not-to-use is given, which would warrant 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?

No annotations were provided, so the description carries the full burden of behavioral disclosure. It does well: discloses billing behavior (pay per call, first call free), notes that unknown codes return 200 with honest empty sections rather than errors, explains that FR-only sections get flagged in coverage for NDC subjects, and states every section carries its own source and date. It stops short of describing exact response structure, but given the richness provided, this is strong disclosure.

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 primary purpose in the first sentence and packs substantial operational detail into the schema parameter descriptions. The main body is telegraphic yet comprehensive. It could be slightly tighter — the inline Notes/style asides and pricing line are useful but could be formatted as separate structured lines. Still, every sentence earns its place with 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?

For a tool with 2 parameters, 100% schema coverage, and no output schema, the description is quite complete: it covers the when-to-use, identifier formats, co-medication rules, billing, error semantics, and honest coverage guarantees. There's no output schema to describe, and the tool returns consolidated structured data whose sections are enumerated in the description. Slightly more detail on the response format would push it to 5, but it's not necessary given the section enumeration.

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 significant value beyond the schema: it explains the one-key exclusivity between cis and ndc (including the 400 case for zero/both), the 'with' parameter's auto-typing rules (8-digit=CIS, digits+dash=NDC, else INN/DCI), the 50-element limit, the pass-once requirement (with=a&with=b is a 400), malformed=400 behavior, and the subject-centered pairing rule. This substantially compensates beyond the schema definitions.

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+resource: 'Get a consolidated medication report' before acting on a prescription or order. It enumerates the exact content (BDPM identity, price, reimbursement, INN substances, generic group, shortage status, DDI) and distinguishes from siblings like medication_availability and medication_generics by specifying the consolidated scope and identifiers used (CIS/NDC).

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

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

The description explicitly states when to use it ('before your agent acts on a prescription or an order'), specifies the identifier formats (French CIS or US NDC), and gives a detailed co-medication note pointing to /medication/interactions for pairs within the with list — an explicit alternative. It also discloses error-handling expectations (400 vs 200 with honest empty sections) and pricing/pay-per-call context.

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

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

With no annotations, the description carries the full burden. It discloses behavior well: pricing per call, free trial, no account/key required, and the specific data returned (INN normalization, price/reimbursement, generic group). It stops short of describing error response structure, but the schema covers malformed-key behavior. Overall, it provides substantial 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 information-dense but remains focused. It leads with the primary purpose, then specifies supported inputs and outputs, and ends with pricing and a docs link. Every sentence adds value, though the pricing/trial lines could be seen as slightly tangential to invocation correctness. Overall, well-structured and not bloated.

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 single-parameter tool with no output schema, the description is comprehensive: it states what the tool returns (authorization status, INN, price, generic group), how it handles FR/US identifiers, and adds billing and trial details. It covers the key facts an agent needs to decide to call the tool and interpret the result, making it complete in context.

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

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

Schema description coverage is 100% for the single parameter 'cis'. The property description already explains the allowed keys (cis/ndc/dci/name) and error handling. The tool description adds only a high-level mention of 'by CIS code, exact name or DCI substance', which does not exceed what the schema already states. 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 uses a specific verb ('Resolve') with a clear resource ('a medication') and details the scope (FR and US registries). It enumerates concrete outputs (authorization status, INN normalization, pricing, generic group) and distinguishes itself from sibling medication tools like medication_availability and medication_interactions.

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 recommends using it 'before your agent acts on a prescription or an order', providing a clear contextual trigger. It also notes that the same endpoint resolves both FR and US drugs, implying dual-usage. However, it does not explicitly mention when to use alternative medication tools or provide 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?

No annotations are provided, so the description carries the full burden. It discloses that validation happens offline (no network call), which is useful behavioral context. However, it doesn't state what happens on invalid numbers (response shape, error behavior), whether normalized output replaces the input, or specifics about the return format beyond listing fields. The pricing/cost info is helpful but doesn't cover behavioral edge cases.

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 efficient and front-loaded with the primary purpose and use case. The pricing and docs info is useful supporting detail. It's a single focused paragraph without redundancy. Slightly could be tightened by removing the pricing block from the description proper, but it's not excessive.

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 2 parameters and no output schema, the description covers the core function reasonably well. However, the 0% schema coverage means the description should more explicitly document parameter formats (what 'country' means, what phone number format is expected on input). The absence of any parameter-format guidance is the main gap preventing completeness.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters (number, country). The description mentions 'country' implicitly via region detection and 'number' via phone number context, but it doesn't explicitly define what formats each parameter should take (e.g., ISO country code vs country name, whether number needs country code or just digits). This is a partial but not complete compensation.

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

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

The description clearly states what the tool does: validates and normalizes a phone number offline. It specifies the verb (validate/normalize), the resource (phone number), and the concrete outputs (E.164 formatting, region, national format, line type) based on libphonenumber metadata. The purpose is specific and distinguishable from siblings.

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 explicit usage guidance: 'Before your agent stores or messages a phone number: validate and normalize it.' This tells the agent exactly when to use the tool. It also notes there's no network call, implying it's appropriate for offline/quick validation scenarios. While it doesn't name specific alternative tools, its context is clear and actionable.

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?

No annotations provided, so the description carries full behavioral burden. It discloses that the tool is free (no cost), is a read-only diagnostic, reports configuration plus discovery health, and surfaces lastError on failure. It accurately conveys the tool is safe, non-destructive, and what failure reporting looks like. The claim that it diagnoses empty tool lists adds valuable behavioral context beyond the name/title.

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?

Single, information-dense sentence with a clear leading signal ('Free tool:') and a trailing diagnostic use case. Compact and front-loaded with the most salient facts. Slightly verbose with the parenthetical example, but it materially aids usage, so not wasted 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?

Given this is a diagnostic tool with zero parameters and no output schema, the description is appropriately complete. It explains what the agent will receive and how to interpret it (empty tool list diagnosis). It doesn't enumerate exact response field names, but that specificity is not required for a zero-param diagnostic 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?

Tool has zero parameters, which per the rubric earns a baseline of 4. No parameter documentation is needed since the input schema is empty and coverage is complete. The description's mention of reported fields (gateway origin, endpoint count, snapshot freshness, last refresh) effectively documents the tool's informative output despite the empty input schema.

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

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

Description clearly states the tool reports gateway origin, endpoint count, snapshot freshness, and last-refresh success. Specific verb 'report' plus explicit list of four pieces of diagnostic info. It differentiates itself as a diagnostic/status tool distinct from discovery tools like search_endpoints.

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

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

Explicitly says to use it to diagnose an empty tool list, with a concrete example (failed discovery reports lastError). Clear context for when to invoke. Doesn't mention explicit when-not cases or alternatives, but the 'Free tool' prefix and diagnostic framing provide adequate usage context.

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

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses that an invalid IBAN returns a 'stop' verdict with HTTP 200 (not an error), that weak matches are returned regardless of verdict setting, that designated vessels/aircraft sharing a name are reported but never trigger a 'stop', and that omitting beneficiary_name makes 'ok' impossible. It also discloses pricing ($0.05) and the daily free trial. This is rich behavioral transparency.

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 detailed but patchy in structure: two dense sentences covering the core functionality are followed by pricing, docs link, and then a third long sentence on beneficiary_name semantics. The beneficiary_name nuance could be tighter, though it's all valuable information. The pricing and docs lines are useful but break the flow slightly.

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?

Despite having no output schema and no annotations, the description is comprehensive: it defines the full verdict set (stop, review, insufficient_coverage, ok), explains the output structure (reasons attached to blocks with dated sources), handles edge cases (invalid IBAN, weak matches, designated vessels), discloses pricing, and links to docs. For a 3-param no-schema tool, this is remarkably complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description meaningfully adds beyond the schema: it explains that a structurally invalid IBAN is a useful answer rather than an error, and clarifies the nuanced rationale for beneficiary_name being optional-but-affecting-verdict. It also explains the include_weak semantics link to /screen/entity. This earns a 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?

The description specifies a concrete verb ('run every check') on a specific resource (bank transfer) and enumerates the exact checks performed (IBAN validity, BIC, SEPA reachability, sanctions, beneficiary screening). It clearly distinguishes from siblings like iban_screen or screen_entity by describing the comprehensive pre-flight aggregation 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 states it is a pre-flight before executing a transfer, giving clear context for when to use it. It references how beneficiary_name semantics align with /screen/entity, and notes the verdict matrix. However, it doesn't explicitly state when NOT to use this vs alternatives like iban_screen or screen_entity, relying on the scope difference to imply 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?

With no annotations provided, the description carries full burden. It discloses the return structure (verdict with every reason attached to its block/source), the verdict vocabulary (stop, review, insufficient_coverage, ok), pricing ($0.05/call, first daily free), billing behavior (no charge on 404 for malformed/unknown keys), and the 'no empty pre-flight is billed' guarantee. The schema adds behavioral nuance about parent-screening skip semantics. This is a rich behavioral disclosure, though it doesn't spell out throttling or auth requirements.

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 well-structured single paragraph followed by clear pricing and docs lines. It front-loads the purpose and check list, then the verdict output, then pricing. Every sentence earns its place and the schema carries the detailed parameter nuance. It is dense but efficient; slightly long, yet justified given the breadth of checks and output semantics it must convey.

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?

This is a complex aggregation tool (8 check categories, multi-source) with a two-parameter schema and no output schema. The description adequately covers what checks run, the verdict output structure, pricing, and billing edge cases. The schema compensates for parameter-level detail. Given no output schema exists, the description's note that reasons attach to blocks/sources is reasonably complete, though it could say a bit more about the output format of each block.

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 carries very detailed parameter descriptions. The description adds value by stating the verdict vocabulary and the overall flow, and by tying the verdict semantics to the parameter behavior described in the schema. The schema itself contains the entity-key exclusivity rules, resolved_siren reopening behavior, not_applicable handling, and the parent-screening warning—all highly informative. Given the schema already documents params thoroughly, the description's marginal addition is modest but not nil.

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+resource ('pre-flight a supplier before you onboard, pay or invoice it') and enumerates the full scope of checks in one call (INSEE/GLEIF identity, BODACC insolvency, VIES VAT, Peppol, control chain, sanctions). It distinguishes itself from sibling tools like company_events, company_peppol, company_vat, and screen_entity by framing itself as the aggregate 'run every check in one call' orchestration tool.

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 is explicit about the temporal trigger ('before you onboard, pay or invoice it'). The input schema adds usage context about exactly-one entity key (siren or lei), and the 'well-formed key unknown to register = 404, unbilled' detail guides error handling. However, it doesn't explicitly name alternatives for when the user wants a single check rather than the full suite, though the sibling list implies per-check tools exist.

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?

No annotations are provided, so the description carries full burden. It discloses billing behavior (unbilled on 400), shape-law refusal, normalization rules (EVM lowercased, base58 case-preserved, bech32 lowercased), whitespace collapsing, chain inference behavior with chain_family_source, and the 12-char limit. This is substantial behavioral detail. Loses a point for not disclosing the response format/fields beyond entity/programmes/date, though it does name those.

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 critical usage trigger ('Before your agent sends funds'), then capabilities, then exclusions, then pricing. The parameter descriptions are dense but every sentence earns its place - the whitespace collapse, normalization rule, and unbilled-400 semantics all justify their length. 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?

For a 2-param tool with 100% schema coverage and no output schema, the description is quite complete: covers when to use, safety semantics, normalization, billing, list sources, and returned fields. It doesn't describe the output schema structure in detail, but with no output schema available and the returned data (entity/programmes/date) named in the description, this is well-covered for its complexity.

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

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

Schema description coverage is 100%, which sets the baseline at 3. But the description adds substantial value beyond the schema: the 'Given, it is LAW' contract, the chain_family_source output reference, the unbilled-400 behavior, and the price. The address parameter is further enriched with normalization specifics and whitespace-collapse. This exceeds baseline meaningfully, though the schema alone was already strong.

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') + resource (crypto address) + clear scope (sanctions lists from OFAC SDN/Consolidated AND EU). It explicitly distinguishes from sibling tools like iban_screen, screen_entity, and various climate tools. The 'No transaction analysis, no clustering, no derived addresses, no risk score' line clearly delimits what the tool does NOT do.

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 explicit 'when to use': 'Before your agent sends funds to a crypto address: check it against the sanctioned addresses'. It lists exclusions (no analysis/clustering/risk score) and names the alternative distinction (free feeds OFAC-only vs multi-list). 'other is never inferred' and 'a password or a misplaced IBAN must not be billed' gives precise boundary behavior.

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?

With no annotations, the description fully discloses key behaviors: multi-list coverage, malformed address handling at item level, pricing formula, max 500 limit, and non-included features. This goes beyond a minimalist description and gives the agent operational expectations.

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 dense but well-structured, leading with use case then details. Every sentence adds operational or pricing detail; the docs link is a bonus. Slightly long but not wasteful.

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

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

Given no output schema, the description covers what a hit contains (entity, programmes, designation date), error behavior, pricing, and list sources. It is sufficient for an agent to select and invoke the tool correctly, including handling edge cases.

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 value by explaining batch pricing per item, the 500 cap, and the optional 'chain' field per item (not shown in schema). It also describes error codes for malformed items, enriching parameter understanding.

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 ('screen') and resource ('crypto addresses'), with clear scope: batch up to 500 addresses against OFAC and EU sanctions lists. It distinguishes from single-address sibling by highlighting batch size and multi-list coverage.

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

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

Provides explicit context ('Before a payout run or a sweep') and exclusions ('No transaction analysis, no clustering, no risk score'), which implies when not to use. Does not explicitly name alternatives like screen_address, but the batch context and exclusions sufficiently guide 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that matching is deterministic (no edit distance, no phonetics), that weak matches are always returned in hits[], and that the 'kind' filter only removes candidates on comparable data. It also explains pricing ($0.01/call) and that the first call daily is free, plus links to docs. This is substantial behavioral context; it loses a point only for not describing the output/response structure since there's 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?

The description is front-loaded with the when-to-use guidance in the first sentence, followed by scope, then limitations, then pricing. The kind-parameter note is detailed but rambles slightly ('a false negative costs more than one candidate too many' is a somewhat discursive justification). Overall efficient, but the kind explanation could be tightened; the pricing and docs info add real value.

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

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

For a 4-parameter tool with no output schema and no annotations, the description is rich: it covers scope, exclusions, matching semantics, parameter behaviors, pricing, and docs. The one gap is that it doesn't describe the response/return format (though there's no output schema to rely on), and it could clarify the verdict logic more. Given the complexity of sanctions screening, this is near-complete but not fully comprehensive.

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

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

Schema coverage is 100%, so the schema already documents all 4 parameters. The description does add meaningful value beyond the schema: it explains the default screening behavior (vessels/aircraft screened by default), the false-negative-cost tradeoff of the kind filter, name character limits, and the include_weak verdict-only effect. However, since schema coverage is complete, the baseline of 3 applies, and while the added detail is genuinely useful, it doesn't push to a 4 because the description's param explanations largely complement rather than transform 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 uses a specific verb+resource ('screen a company or person name against the official designation lists') and clearly states the tool's scope: OFAC SDN/Consolidated, EU financial sanctions, UN Security Council - 26,666 entities. It explicitly notes what it does NOT cover (PEP screening, adverse media, transaction analysis), which distinguishes it from siblings like screen_address and iban_screen.

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 opening sentence gives explicit when-to-use guidance: 'Before your agent onboards a counterparty, signs a contract or releases a payment.' It also explicitly names what's NOT covered (PEP screening, adverse media, transaction analysis), which signals when to avoid the tool. The kind parameter guidance explains when filtering by kind is appropriate and warns about its limitations.

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?

With no annotations provided, the description carries the full burden and does an excellent job. It discloses error handling ('A malformed item is flagged at its position instead of failing the batch'), output details ('one sourced verdict per name, with aliases, programmes and designation dates'), limitations (exclusions listed), and even pricing and maximum batch size. This is comprehensive for a screening tool.

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

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

The description is well-structured and front-loaded with a concrete use case ('Before onboarding a supplier book or running a payout list'). Every sentence adds value: purpose, list coverage, error behavior, exclusions, pricing, and docs link. It is concise for a tool with batch complexity, with 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?

Despite having no output schema, the description clearly explains what is returned (verdicts with aliases, programmes, designation dates) and covers error handling, batch limits, pricing, and exclusions. It also provides a documentation link for further details. Given the tool's complexity, this description is complete and self-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 covers 100% of parameter descriptions, including pricing, validation, and optional filters for both 'items' and 'include_weak'. The description adds no new parameter-specific meaning beyond what the schema 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 states a specific verb ('screen') and resource ('names against sanctions lists'), with explicit scope ('up to 200 company or person names in one call') and details about the specific lists (OFAC, EU, UN). It clearly distinguishes itself from the sibling tool 'screen_entity' by emphasizing the batch capability and the one-call aspect.

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

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

The description provides explicit usage context ('Before onboarding a supplier book or running a payout list') and clearly states exclusions ('PEP screening, adverse media and transaction analysis are not covered'), guiding the agent on when not to use this tool. It also implies the alternative to single-name screening by highlighting the batch nature.

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?

No annotations are provided, so the description carries the full disclosure burden. It explicitly states no payment and no network call (important behavioral facts for a meta-tool searching a paid catalog), and discloses returns (tool names, price, free-trial flag, docs link). It doesn't mention pagination or result limits, but covers key operational traits well for an unannotated tool.

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 tightly-written sentences: what it does, what it returns, and its free/no-network nature. Zero filler words, each sentence earns its place. Excellent front-loading of 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?

For a simple single-parameter query tool with no output schema, the description covers what it returns, its free nature, and its query matching semantics. It could note return format details or result ordering, but for a catalog search tool this is reasonably complete. Simple tool, proportionate documentation.

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 description reinforces the query parameter semantics (free-text, case-insensitive, all-terms match, empty-to-list). While the description confirms the query behavior isn't just elided by the schema, it adds minimal extra value beyond what the schema already documents. 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 this is a full-text search tool over the Invoket catalog, returning MCP tool names with price, free-trial flag, and docs link. It uses a specific verb (search) and resource (Invoket catalog), and distinguishes itself from sibling tools by its meta-search role over the catalog itself.

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 explains its purpose as going 'from an intent to the right paid tool' and explicitly discloses it's free with no payment/no network call, which helps an agent understand its low-risk nature. However, it doesn't explicitly name alternative search/comparison tools or provide when-not-to-use guidance against specific 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?

No annotations are provided, so the description carries the full burden. It discloses that it's free, requires no auth, returns an acknowledgement id, and never charges — good transparency about cost side effects. However, it does not describe what happens after submission (e.g., persistence, review process, response format details beyond the id) or any rate limits.

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

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

Two compact sentences, fully front-loaded with purpose and cost/safety disclosure. Zero wasted words; every clause (free, no auth, returns id, never charges) 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?

For a 4-param feedback tool with 100% schema coverage and a nested context object, the description plus schema adequately cover purpose, categories, and return. The main gap is no explanation of what the acknowledgement id means or broader submission behavior, but this is minor for a simple feedback tool.

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