toll402 – EU & Nordic Data (x402)

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

With no annotations the description carries the full burden and does substantial work: it discloses the third-party provider (Atlas Data), a 24 h cache, the 0.03 USD per-call price via x402, the underlying regulation/benchmark sources, and an estimate caveat for the unpublished 2026-Q4 price plus a 'not legal advice / not binding' disclaimer. It stops short of describing error behavior or the shape of the 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 core purpose is front-loaded in the opening clause before the regulatory citations and disclaimers, and every sentence carries real information (coverage limits, cost, caching, legal caveat). It is dense and long, but not padded.

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, the description covers data sources, coverage boundaries, pricing, caching, and an explicit estimate caveat, which is close to complete. The main gap is that it only gestures at return values ('certificates and cost per import line') without describing the per-line output fields an agent would receive.

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 9 parameters in detail, making 3 the baseline. The description adds only light context — that productionRoute normally comes from the default-value table and that the carbon price is a 'simplified Art. 9 deduction' — but does not explain the interrelationship of items vs lines vs the singular default fields.

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

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

States a specific resource (EU CBAM certificates and cost estimate) and the exact scope (up to 20 import lines of CN code/country/tonnes/date) plus the secondary mode ('or list the quarterly certificate prices'). This is unmistakably distinct from every sibling tool in the list (vat, sanctions, co2, etc.).

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 frames the calculation context and the two modes, and states a hard exclusion ('Electricity is not covered'), which is genuinely useful usage guidance. It does not name an alternative tool or spell out when a caller should prefer listPrices mode over calculate, so it stops short of explicit when/when-not routing.

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 present, the description must disclose behavior, and it does: an authoritative source (Klimadatastyrelsen/DAR), a license (CC BY 4.0), a per-call cost (0.005 USD via x402), and the shape of the returned data, including WGS84 and UTM32 coordinates. It omits failure behavior for unmatched addresses (error vs. partial result) and whether the call is strictly read-only, which keeps it from a 5.

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

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

The description is a single front-loaded sentence led by the action, followed by compact provenance and pricing clauses. The long output-field enumeration is dense but earns its place because no output schema exists.

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 one simple parameter and no output schema, the description carries the return-value explanation itself (normalised address, DAR ids, coordinates) plus cost and source, which is what an agent needs. Missing only edge-case behavior for invalid or ambiguous addresses.

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 and its schema description coverage is 100%, so the schema already documents the free-text address format. The description adds no format syntax, examples, or constraints beyond what the schema states; baseline 3 applies.

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

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

The description states a specific verb pair (validate and geocode) against a named authoritative resource (the Danish Address Register/DAR), and enumerates the outputs. No sibling tool in the provided list does address work, so an agent can identify this tool from its name and description alone.

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

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

Usage is implied by the phrase 'validate and geocode a Danish address,' but the description never states when to call this tool versus alternatives or what to do when it should not be called. Since none of the sibling tools are close substitutes, this implicit guidance is sufficient, but it is not explicit.

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

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

With no annotations at all, the description carries the full burden, and it does disclose the two things an agent most needs: this is a computation over Danish banking rules and each call is metered at 0.005 USD via x402. It is silent on whether the call has side effects, how the date is interpreted (timezone), and error behavior for malformed dates.

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?

A single dense sentence that front-loads the resource and then the four capabilities, followed by the price. Slightly comma-chained, but 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?

There is no output schema, so the description is the only signal about results — it implies the response covers banking-day status, closure reason, next day, and the shifted date. That is reasonably complete, but without field names or response shape an agent still cannot anticipate the return payload for the `add` path.

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% — both `date` (YYYY-MM-DD) and `add` (0-260 banking days) are documented in the schema. The description only restates the additive behavior as "date + N banking days" and adds the payment-deadline framing, which gives useful intent but no new mechanical detail such as what happens at the 0 and 260 boundaries.

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 resource (Danish banking days) and enumerates the concrete operations: is-it-a-banking-day, closure reason, next banking day, and date + N banking days. An agent knows exactly what it gets. It stops short of 5 because the obvious near-sibling eu_working_days is never referenced, and the tool bundles four outputs into one call without saying whether they are returned together or selected.

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?

"Payment deadlines" implies a use case, so usage is inferable. But there is no statement of when to prefer this over eu_working_days or a plain calendar calculation, and no exclusions or prerequisites are given.

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 discloses the data source (Energinet), the resolution of each returned value, and the notable payment requirement (0.005 USD per call via x402) — all information an agent cannot get from structured fields. It does not cover error behavior for an invalid area or any rate limits, so it falls short of full 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?

One dense, front-loaded sentence: resource and units first, then scope, then the three return components, then source and cost. No filler sentences.

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

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

There is no output schema, and the description compensates by enumerating what comes back (5-minute value, hourly average, forecast with greenest hour) plus units, source, and cost. That is enough for an agent to call it correctly and interpret the result.

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

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

The single parameter's schema description is just 'area' with no enum or type constraint, so the description carries real weight by naming DK1/DK2 as the valid areas. It does not spell out whether 'area' is a string value or how the zone is passed, which is a minor 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?

States a specific resource (CO2 intensity of Danish electricity in g CO2/kWh), the exact scope (DK1/DK2), and the three returned measures (latest 5-minute value, last-hour average, forecast with greenest hour). This clearly separates it from price siblings like dk_power_price and dk_power_cheapest_window.

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

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

Usage is implied: an agent would reach for this for carbon-intensity questions rather than price questions. However, the description never explicitly says when to choose it over dk_power_price/dk_power_cheapest_window, nor any prerequisites or 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, the description carries the full burden and does disclose two non-obvious behaviors: the upstream data source/license (Energinet, CC BY 4.0) and a per-call cost of 0.005 USD via x402. What it omits is the response shape (does it return a start time, the average price, savings vs. baseline?) and behavior on invalid areas or out-of-range hours.

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 capability is front-loaded in a single dense sentence, with source and cost appended as compact metadata. Nothing is wasted, though the source attribution is slightly redundant with the URL and could be trimmed.

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

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

There is no output schema, so the description must explain the return value, and it does not — an agent cannot tell whether it receives a time range, a price, or a comparison to a flat-rate baseline. Source and pricing context are covered, but the missing return contract is a real gap for a decision-support 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 area, date and hours are already documented in the schema, including the 1-12 range. The description reinforces that the window is contiguous and that pricing is day-ahead, but adds no format or edge-case detail (e.g., timezone of 'date', behavior when hours exceeds the day's remaining slots). Baseline 3 applies.

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

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

The description states a specific operation: finding the cheapest contiguous N-hour window based on day-ahead spot prices, scoped to named bidding zones. It is clearly distinct from a raw price lookup like dk_power_price, though it never names that sibling explicitly. Verb + resource + scope are all present.

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?

Concrete load examples (EV charging, heat pump, batch job) imply when the tool is appropriate, which is better than nothing. However, there is no explicit guidance on when to use dk_power_price instead, no mention of the same-day/next-day availability window for day-ahead prices, and no stated exclusions or prerequisites.

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

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

No annotations exist, so the description carries the full burden, and it does well: it discloses the upstream source (Energinet, CC BY 4.0), the granularity, the currency units, and notably the per-call cost of 0.005 USD via x402 — a billing constraint the agent would otherwise not know. It stops short of describing response shape, failure modes, or historical date 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 sentences: the capability first, provenance and pricing second. Every clause carries information — zones, granularity, aggregates, currencies, source, license, cost — 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?

With no output schema, the description still conveys what comes back (15-minute prices plus cheapest/average/most expensive quarter) and in what units, which is most of what an agent needs. Gaps are minor: response format, historical range, and payment/auth mechanics for the x402 fee are mentioned but not explained.

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

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

Schema coverage is 100%, so both parameters are already documented with the zone list and the YYYY-MM-DD/CET default. The description restates the zone codes and adds the DKK/EUR per MWh unit context, but adds no syntax or constraint detail beyond the schema. Baseline 3 applies.

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

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

A specific verb-and-resource statement: day-ahead 15-minute spot prices for DK1/DK2 plus named neighbouring zones, with the derived aggregates (average, cheapest, most expensive quarter) spelled out. An agent can immediately tell this is a price-data retrieval tool, distinct from the sibling dk_power_cheapest_window which finds a window rather than a day's curve.

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 makes the use case obvious (fetch day-ahead prices for a zone and date) but never states when to prefer it over dk_power_cheapest_window, which overlaps on the 'cheapest quarter' output, nor any prerequisites such as x402 payment setup. Usage is implied rather than routed.

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 present, the description carries the burden well: it discloses the data source (DMI), the cost and payment mechanism (0.005 USD per call via x402), the measurement datum (cm relative to DVR90), and that the data is 'latest'/real-time. It does not cover failure modes, e.g. what happens when a port name matches multiple stations or no station.

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

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

Three short sentences: what it returns, when it's useful, then provenance/price. The returned quantities and units are front-loaded 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?

Absent an output schema, the description must convey return contents, and it does: sea level in cm relative to DVR90 plus water temperature, from DMI. It omits the temperature unit and whether other fields (e.g. station metadata, timestamp) come back, which leaves a small gap for a single-parameter data 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% (baseline 3), and the description adds real value on top by supplying concrete port-name examples that clarify what a valid value looks like. Partial-match behavior is documented in the schema rather than the description, so no further credit is warranted.

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 resource and verb: 'Latest sea level ... and water temperature at Danish ports/tide gauges by port name', with concrete examples (Esbjerg, Aarhus, Skagen). An agent can immediately distinguish this from the generic dk_weather sibling and knows exactly what it retrieves.

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 gives explicit usage contexts — port calls, draught and storm surge checks — which tells the agent when this is the right tool. It doesn't name an alternative (e.g. dk_weather) or state when not to use it, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full burden and does disclose high-value operational facts: the data source (DMI Open Data) and the paid, metered nature (0.005 USD per call via x402). It omits failure behavior (no nearby station), units, and observation staleness, which matter 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?

A single dense sentence leads with what the tool returns and how it is located, then tacks source and pricing on the end. No filler or repetition of the tool name.

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

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

No output schema exists, and the description compensates by listing the returned measures (temperature, wind, gusts, pressure, precipitation, visibility). Cost is covered. The remaining gaps are unit conventions and the fact that all three parameters are optional, leaving the agent unsure whether an empty call is valid.

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 lat/lon descriptions are just 'lat'/'lon', so the description adds real meaning by explaining they resolve to the *nearest* DMI station, and that station id is an alternative rather than a third filter. It does not say whether lat and lon must be supplied together.

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

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

States a specific verb and resource ('Latest observed weather in Denmark') plus the retrieval mechanism (nearest DMI station to lat/lon or a station id), and enumerates the returned measures. No sibling in the list offers weather, so the boundary is unambiguous.

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

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

The 'latest observed' framing plus 'nearest DMI station to a lat/lon (or a station id)' implicitly tells the agent which input mode to use and that this is current conditions, not a forecast. It stops short of any explicit when-not-to-use guidance or note about what happens when no station is near the coordinates.

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 behavioral burden and adds useful context: third-party provider (Atlas Data), caching up to 24 hours, x402 pricing at 0.02 USD per call, and legal disclaimers that it is not legal advice or legally binding. It does not describe authentication or error behavior, but the disclosed cost, cache, and disclaimer are meaningful operational 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 core purpose and then adds mode, provider, cache, legal, and pricing context. It is dense but every sentence contributes useful information; the citations and disclaimers add trust for a regulatory tool rather than wasting space.

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

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

For an 11-parameter regulatory lookup tool with no output schema and no annotations, the description covers what the tool checks, what it returns conceptually (Annex I status, commodity, country risk, due-diligence regime, obligation dates), its listing modes, limits, cache behavior, pricing, and legal caveats. An agent has enough context to invoke it correctly.

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

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

Schema description coverage is 100%, so the input schema already documents all 11 parameters, including mode, codes, items, companySize, and referenceDate. The description reinforces the high-level behavior (up to 25 codes, role and company size affecting obligations) but does not add syntax or format details beyond the schema.

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

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

The description states a precise regulatory check: EUDR scope and country-risk classification for up to 25 HS/CN codes, including Annex I commodity determination, country risk under Implementing Reg. (EU) 2025/1093, due-diligence regime, and obligation timing. It also explicitly says it can list Annex I products or country risk levels, making the tool's scope unambiguous against unrelated sibling tools.

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 the tool: checking whether a product falls within EUDR scope and what obligations apply. It does not explicitly state when not to use it or name alternatives, but the regulatory specificity makes its intended use evident.

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, and it does disclose a genuinely important trait: a 0.005 USD per-call x402 payment requirement, plus the split data sourcing (local for DK, Nager.Date otherwise). It omits return shape, year-range limits, and behavior when a country is unsupported.

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

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

Three tight sentences with the scope and the cost up front; every clause carries information. The sourcing sentence is secondary but still earns its place as reliability context.

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

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

For a two-parameter lookup with no output schema, coverage is nearly adequate: scope, cost, and source are all stated. Missing only a note on what a result looks like and any year bounds, which is a modest gap given the tool's simplicity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does add scope to the 'country' parameter by enumerating the accepted region, but says nothing about the 'year' parameter's valid range or default.

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

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

States the resource precisely (national public holidays, yearly) and the exact geographic scope (EU/EEA/Nordic plus CH, GB), which lets an agent distinguish it from dk_bank_days or eu_working_days on content grounds. There is no explicit sibling differentiation, so it falls short of a 5.

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

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

The description never says when to pick this over eu_working_days or dk_bank_days, nor does it state prerequisites or exclusions. Only the coverage list implies usage, leaving routing between overlapping calendar siblings to inference.

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 behavioral burden and does well: it discloses the return structure (exact/partial matches with programme, EU reference, and regulation link), the cost per call, and the human-review caveat. It does not cover rate limits or error behavior, but the key operational traits are present.

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 four tight sentences with the core action and scope front-loaded. Every sentence adds either purpose, return information, or usage caveat, with no wasted text.

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

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

For a two-parameter screening tool with no output schema and no annotations, the description provides enough context to call it: it explains what is screened, what is returned, and the human-review limitation. The remaining gap is the unexplained `type` parameter.

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 nominally 100%, but the `type` parameter's schema description is only "type" and is not clarified in the tool description. The description does add meaning for `name` by specifying a person or company and alias screening, but the second parameter remains semantically opaque.

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 and resource: screening a person or company name against the EU consolidated financial sanctions list, including aliases. It clearly identifies the tool's purpose and scope without needing a sibling comparison.

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 notes the tool is a screening aid and requires human review, which gives useful usage context. However, it does not explicitly state when to use this tool versus alternatives or when not to rely on 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, the description carries the full burden and does well: it discloses the 25-notice cap and newest-first ordering, that results come from a third-party seller (Atlas Data), that responses are cached up to 1 h, and that each call costs 0.03 USD via x402. It does not describe failure modes (e.g., what happens when the budget/payment fails) or a rate limit, which keeps it short of a 5.

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

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

Front-loads the verb and resource, then packs filters, return fields, ordering, caching, provenance and price into tightly written sentences with no repetition. The copyright/price tail is short and operationally relevant rather than 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 10-parameter, no-output-schema, paid third-party search tool, the description covers query semantics, result shape, result cap/ordering, caching, cost and licensing — everything an agent needs to decide to call it and interpret the response.

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, but the description adds real value where the schema is thin — it clarifies noticeType with examples ("calls for tenders, awards, planning…") where the schema only says "Default any", and restates onlyOpen as "only tenders still open". That compensates for the one weak parameter definition.

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

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

States a specific verb and resource ("Search EU public procurement notices on TED") and then enumerates the filterable dimensions (keyword, buyer country, CPV, notice type, publication date, open-only) plus the fields returned. No sibling tool covers tenders, so it is trivially distinguishable from the dk_/eu_ utility tools, and an agent can tell exactly what domain it queries.

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

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

Gives clear context for use: filter by keyword/country/CPV/notice type/date, and "optionally only tenders still open". Defaults are implied for dates (schema says 30 days) and result count. It does not state when NOT to use it or any prerequisite/failure conditions, but there is no competing sibling to route against.

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 and does well: it discloses that validation is a live external call to VIES, that results may be partial (name/address only 'where the member state discloses them'), and that each call costs 0.01 USD via x402. It stops short of describing VIES downtime/timeout behavior or error returns.

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?

A single dense sentence, front-loaded with the verb and resource, then the return contract, then the pricing. 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 one-parameter tool with no output schema, the description covers purpose, data source, partial return values, and cost. The only real gap is failure behavior when VIES is unavailable or the number is malformed.

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 documents the format including the 2-letter prefix and the Greece = EL quirk. The description adds no syntax or constraint details beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Validate an EU VAT number live against the European Commission VIES service'), which cleanly separates it from the adjacent eu_vat_rates tool that deals with rates rather than validation.

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

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

Usage is implied by the verb 'Validate' but the description never states when to use this versus alternatives (e.g. eu_vat_rates) or any prerequisites. No exclusion or alternative routing is given.

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 must carry the behavioral burden. It usefully discloses that calls cost 0.005 USD via x402 and that the rates are current, but it does not describe return format, pagination, rate limits, or whether there are any access constraints for the x402 payment flow.

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

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

The description is two sentences and front-loads the core value: current EU VAT rates by category. The scope and pricing details follow without waste, and every sentence contributes necessary 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 simple one-parameter lookup tool with no output schema, the description is largely complete: it names the rate categories, notes category notes are included, and explains the country/all scope. The main remaining gap is the absence of any return-value structure, though this is less critical for a straightforward 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 description coverage is 100%, and the single parameter is already documented as 'ISO alpha-2, omit for all EU'. The description reinforces this with 'One country or all' but adds no additional parameter semantics beyond the schema.

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

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

The description clearly identifies the resource and content: current VAT rates for EU member states, including standard, reduced, super-reduced, and parking rates with category notes. It does not explicitly distinguish itself from the sibling eu_vat_check, so the differentiation is implied by 'rates' versus 'check' rather than 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?

The phrase 'One country or all' gives basic usage scope, indicating the tool can be called for a single country or across the EU. However, it does not state when to use this tool versus alternatives such as eu_vat_check, nor does it mention exclusions or prerequisites beyond the pricing note.

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 and does disclose meaningful behavior: weekends and national holidays are excluded, the range is inclusive, and each call costs 0.005 USD via x402. It omits return shape, country coverage semantics, date format expectations, and what happens on invalid input or out-of-range 'add' values, leaving significant gaps for a mutation-free but non-trivial computation 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?

Two tight sentences: the capability statement comes first, followed by the billing note. Nothing is repeated and no sentence is 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?

Covers the two computation modes and the pricing model, which is the core of the tool. But with no annotations, no output schema, and ambiguous date input formats (the schema types allow string/number/boolean), the description leaves an agent guessing about accepted date formats, return value structure, and per-country holiday data coverage.

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 reported at 100%, so the baseline is 3; the schema itself carries the parameter definitions (including the 0-260 range for 'add'). The description adds only the inclusive-range semantics and the from/add relationship, which is modest value beyond the structured fields.

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

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

States a specific verb and resource: counting working days between two dates and/or computing date + N working days across EU/EEA/Nordic countries. This is clearly distinguishable from siblings like eu_holidays (holiday listing) and dk_bank_days (single-country variant), so an agent can select it without opening the schema.

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

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

The 'and/or' phrasing implies the two operating modes (range count vs. add-N offset), which gives implied usage guidance. However, it never says when to prefer this over eu_holidays or dk_bank_days, nor any exclusion or prerequisite beyond the pricing note.

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, and it does add real value beyond the schema: the upstream source/API (PRH open data v3), the CC BY 4.0 license, and a per-call price of 0.01 USD via x402. However, it omits failure/empty-result behavior, whether name matching is fuzzy or exact, and any rate limit or retry characteristics.

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

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

A single front-loaded sentence that leads with the resource and lookup keys before listing return fields and licensing/price. Dense but every clause carries information; a slight readability cost from cramming attribution and pricing into the same sentence.

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 annotations and no output schema, the description usefully enumerates the returned fields and the pricing/licensing context, which is what an agent needs before spending money. The remaining gap is the zero-required-parameter situation: it implies one identifier must be supplied but never states that explicitly or what happens if neither is given.

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 including the example ID format. The description only restates that lookup can happen by Business ID or name and adds no precedence rule, no guidance on combining the two, and no detail on what the up-to-5 name candidates look like.

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

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

Names a specific verb (lookup) and a precise resource (Finnish company in the official YTJ/PRH register), enumerates the lookup keys (Business ID or name) and the returned data categories (names, legal form, address, industry, registration date, liquidation/bankruptcy). The contrast with the sibling no_company (Norwegian) is implicit but obvious from 'Finnish'.

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

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

Usage is only implied: an agent can infer this is the tool for Finnish company data, and the schema hints that name search returns up to 5 candidates while businessId is exact. There is no explicit when-to-use, no routing guidance versus no_company or lei_lookup, and no statement about which key to prefer or whether both may be supplied.

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 does disclose two genuinely useful behaviors: the price (0.005 USD per call) and the x402 payment mechanism, which tells the agent a paid/wallet flow is involved. It omits rate freshness/cadence, error behavior, and any statement of what the response contains, so the burden is only partly carried. Note a minor internal inconsistency: it advertises conversion 'to/from DKK' while the schema only supports conversion to DKK.

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

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

Two dense sentences with the core resource and units front-loaded, and pricing placed last where it belongs. Little waste; slight compression comes at the cost of the ambiguous 'to/from' phrasing.

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

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

For a two-optional-parameter tool with no annotations and no output schema, the description should say what comes back (a rate table for all currencies vs. a single converted figure) and clarify that currencies quote against DKK. Without that, the agent cannot fully predict behaviour, especially in the mixed conversion mode.

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

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

Schema coverage is 100%, so both parameters are documented in the schema itself; the description adds the rate-unit convention (per 100 units) which aids interpretation of the currency-only mode. It adds little else about the amount parameter beyond 'convert an amount'.

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

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

Names the resource precisely (Danmarks Nationalbank official DKK exchange rates), states the quotation convention (DKK per 100 units) and coverage (~30 currencies), plus an optional conversion mode. It stops short of explicitly differentiating from the sibling fx_ecb, so an agent must infer the source distinction.

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 optional conversion mode is signalled, but there is no statement of when to choose this over fx_ecb (ECB rates) or which currency universe applies. Usage is only implied, leaving the agent to infer routing between the two FX 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, the description carries the behavioral burden well by disclosing the official ECB rate source, the 90-day date window, the business-day fallback rule, and a per-call price via x402. It omits details such as payment/auth mechanics, rounding behavior, and error cases, which keeps it from a 5.

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

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

The description is compact and front-loaded: conversion purpose, rate source, supported date range, fallback behavior, and pricing. Each clause adds useful information, with no redundant or filler sentences.

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 annotations and no output schema, the description gives enough context to select and broadly invoke it: rate source, currency universe, date constraints, fallback, and pricing. It is not fully complete because it does not enumerate or define accepted currency codes, date input format, or the conversion result format.

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

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

Schema description coverage is reported at 100%, but the schema descriptions are placeholders like 'from', 'to', and 'amount'. The tool description adds meaning for the currency pair and especially the date parameter, including the 90-day window and fallback behavior, but it does not specify currency code format, date format, amount precision, or same-currency behavior.

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 and resource: convert an amount between two currencies. It also identifies the rate source (official ECB euro reference rates) and the supported scope (~30 currencies), which distinguishes it from narrower siblings like fx_dkk.

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 gives clear usage context: conversion can be for today or any date in the last 90 days, with fallback to the previous ECB business day. It does not explicitly name alternatives such as fx_dkk or state when not to use this tool, so it falls short of full routing guidance.

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

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

With no annotations, the description carries the burden and does well: it discloses third-party provenance (Atlas Data scraper), a 6-hour cache, per-call pricing via x402, and the crucial semantic caveat that values are relative interest rather than absolute volume. It stops short of error behavior, rate limits, or truncation handling, keeping it below a 5.

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

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

A single dense paragraph that front-loads the capability before provenance, caching, caveats, and price. Nearly every clause earns its place; the provenance and pricing clause is slightly compressed but still informative 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?

For a 7-parameter tool with no output schema, the description does the necessary work of describing the return shape (time series plus regional and related-query lists) and the semantic caveat on the metric. Only the exact response envelope and failure modes are left implicit, which is a minor gap.

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

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

Schema coverage is 100%, so the schema already documents all 7 parameters including geo formats and maxItems clamping, establishing a baseline of 3. The description only restates the 1-5 keyword limit and adds output-side meaning (0-100 scale, Breakout inclusion) rather than illuminating parameter behavior beyond the schema.

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

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

States a specific verb+resource ('Google Trends for 1-5 keywords') and enumerates the three result families: interest over time (0-100), interest by region, and top/rising related queries. An agent knows exactly what it gets back without opening the schema, and no sibling tool overlaps.

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

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

Usage is implied by the description ('relative interest, not absolute search volume' tells the agent this is not a volume-estimation tool), but there is no explicit when-to-use / when-not statement and no alternative named. The cost note (0.03 USD per call) gives a de facto usage consideration but isn't framed as 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 present, the description carries the full disclosure burden and does well: it reveals a third-party scraper source, up to 1 h caching, a hard cap of 50 results, and a per-call price of 0.02 USD via x402. It stops short of covering failure modes or what happens when a paid call returns nothing, which matters for a metered 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?

Four dense sentences, front-loaded with scope and return fields, followed by operational facts (limit, provider, caching, price). No filler, though the provider and price facts could be merged for tighter structure.

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

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

There is no output schema, so the description correctly compensates by naming the returned fields. The commercial framing (paid per call, third-party seller) is present, which an agent needs before invoking. Missing only error/empty-result behavior for a metered third-party endpoint with 11 optional parameters.

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

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

Schema description coverage is 100%, so every one of the 11 parameters is already documented in the schema. The description adds only marginal semantics ('salary (where shown)', 'up to 50 jobs per call' reinforcing the maxItems clamp) and does not explain sort, jobType, or datePosted behavior beyond the schema.

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

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

States a specific verb and resource ('Live Indeed job listings') and enumerates both geographic scope (Denmark, Sweden, Norway + 57 other country sites) and the exact fields returned. No sibling tool in the list does anything similar, so there is no ambiguity to resolve.

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 establishes clear usage context: keyword or location driven search, up to 50 jobs per call, and cached results. It doesn't state any when-not-to-use condition, but with an unrelated sibling set (dk_address, fx_dkk, mica_casp, etc.) there is no competing tool to steer away from.

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

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

With no annotations, the description carries the full burden, and it does disclose two valuable traits: the CC0 licensing of the data and a paid x402 model at 0.01 USD per call. It does not say what happens on zero arguments, on a name search with no matches, or whether failed calls are still billed.

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?

A single front-loaded sentence with the resource and access modes first, followed by the returned field list, then license and price. Every clause carries information; nothing is 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 two-parameter read tool with no output schema and no annotations, the description supplies the data source, the returned fields, the license, and the cost – enough to call it correctly. The remaining gap is the zero-argument case and empty-result behavior for name searches.

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 and the 'up to 5 candidates' behavior for name search. The description only restates the two lookup modes without adding format, precedence, or combination rules (e.g., which parameter wins if both are supplied).

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

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

States a specific verb+resource: LEI lookup in the GLEIF Global LEI Index, with both access modes (by LEI or by legal name) and the fields returned. It does not differentiate itself from company-registry siblings such as fi_company, no_company, or dk_address, which an agent might reasonably consider for an entity 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?

'by LEI or legal name' implies the two entry modes, but there is no explicit when-to-use, no exclusion of the company-registry siblings, and no statement about what happens when neither parameter is supplied (required parameters = 0). Usage is inferable but not guided.

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 and does so: 503 failure mode within ~40s, no charge on failure, 6h caching, third-party seller, and 0.02 USD per call via x402. These are exactly the operational traits an agent needs before invoking a paid, flaky endpoint.

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-loads the action and scope in the first sentence, then layers operability facts in subsequent clauses. Dense and largely waste-free, though the middle sentence is a long run-on that packs several distinct facts together.

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 paid third-party scraping tool with 8 optional params and no output schema, the description covers pricing, caching, failure behavior, return volume, and a fallback source — nothing an agent needs to decide or call correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description earns extra by explaining the cost profile of includeDetails (slower, more failure-prone, keep maxItems small) and the 20-ads-per-call cap. It doesn't elaborate on keyword/advertiser interaction beyond what the schema states, so not a 5.

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

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

States a specific verb and resource ('Search the LinkedIn Ad Library... by advertiser name or keyword') and enumerates the returned fields. It also names the alternative ad source '/v1/ads/meta' relative to the meta_ads sibling, so an agent can route correctly.

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 frames when this is the right choice (advertiser/keyword search with optional country and date filters), when it is risky ('LinkedIn sometimes blocks automated access'), and which tool to prefer for reliability ('/v1/ads/meta is the more reliable ad source'). The includeDetails caveat tells the agent to keep maxItems small.

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 present, the description carries the burden well: it discloses that results are cached up to 15 min (staleness), that data is third-party via Atlas Data with CC BY 4.0 licensing, and critically that each call costs 0.02 USD via x402. That cost signal is behaviorally important and absent from any structured field. It stops short of stating whether the operation is strictly read-only or what happens on payment failure.

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?

A single dense paragraph that front-loads scope and content before the operational metadata (source, license, cache, price). Every clause carries information, though the vendor/pricing tail could be trimmed if the surrounding tool listing already surfaces cost metadata.

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 8 optional parameters, no annotations and no output schema, the description does what it must: enumerates returned fields (ETA/ETD/ATA/ATD, berth, vessel identity, previous/next port), states the row cap, and covers freshness and cost. The only residual gap is not describing error or truncation behavior when the 15-row clamp is hit.

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 every parameter already has its format, defaults and clamping documented in the schema itself. The description only restates the filter categories and adds a UN/LOCODE example (FIHEL) plus the 15-item cap, which is marginal value over structured data. Baseline 3 applies.

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

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

Names the specific resource (port calls), constrains the geography explicitly ('Finnish ports only'), identifies the upstream source (Portnet via Fintraffic Digitraffic), and enumerates the returned fields. An agent can distinguish this from the vessel-registry-style sibling maritime_vessels without opening a schema.

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

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

Tells the agent what can be filtered by (port UN/LOCODE, vessel, time window, status) and that results are capped at 15, which implies the intended query pattern. However, it never states when to choose this over maritime_vessels or what to do when the cap truncates results, so usage is implied rather than guided.

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 well: it discloses coverage bounds, a 30-vessel cap per call, a 3-minute cache, third-party provenance (Atlas Data / Fintraffic Digitraffic, CC BY 4.0), a cost of 0.02 USD per call via x402, and a 'not for navigation' fitness caveat. These are exactly the operational facts an agent needs before calling.

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

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

Front-loaded with the geographic limitation, which is the single most important constraint, then the query modes, then provenance/cost. It is a long run-on sentence rather than a structured block, but essentially every clause (coverage, modes, limits, cache, license, price, disclaimer) 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 10-parameter tool with no annotations and no output schema, the description covers returned fields (name, IMO, type, speed, course, nav status, destination, ETA, size), result limits, freshness, licensing, pricing, and the safety caveat. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds value beyond the schema by stating the maximum radius (1000 km) and that results are sorted by distance, plus the up-to-30 clamp on maxItems — constraints the schema does not state.

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

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

States a specific verb+resource — live AIS vessel positions — and immediately bounds it geographically (Finnish AIS coverage, ~57–66°N, 17–35°E, not global). The two query modes (proximity vs. identifier/category) make it self-differentiating from maritime_port_calls, which clearly covers port calls rather than live positions.

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

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

Gives clear context for how to use it: proximity search near a point with radius and distance sorting, or lookup by MMSI/IMO/name/category. It does not explicitly name maritime_port_calls as the alternative when historical port-call data is wanted, so there is no stated when-not.

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 a good job: it discloses the 20-ads-per-call cap, that results are third-party sourced from Atlas Data, a 6-hour cache staleness window, and a 0.02 USD per-call x402 payment requirement — a real precondition for invocation. It stops short of stating failure modes or 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?

Purpose and query modes are front-loaded in the first clause, followed by the field list and then operational facts (cap, provider, cache, price) in short compact sentences. The opening sentence is long but dense with no filler; only the field enumeration runs slightly long.

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

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

For a 13-parameter tool with no annotations and no output schema, the description covers the important gaps: it describes what comes back, the result cap, the data source's trust level, freshness, and cost. The residual gap is guidance on the ambiguous filter parameters (sort, adType, mediaType) that the schema leaves as bare names.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the two principal query modes (keyword vs. pageIds) and the 20-item output cap, but adds nothing about the opaque parameters whose schema descriptions are just the field name itself ('sort', 'mediaType'), leaving the agent without interpretive help there.

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

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

The description gives a specific verb and resource ('Search the Meta (Facebook/Instagram) Ad Library'), names the underlying archive, and enumerates the returned fields (advertiser, ad text, creative format, landing page, platforms, dates, status, spend/impression ranges). That enumeration plus the platform qualifier separates it cleanly from the only adjacent sibling, linkedin_ads.

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?

'By keyword or advertiser page ID and country' tells the agent how to drive the tool, and the phrase 'public ad-transparency archive' implies the legitimate use case. But there is no explicit when-not guidance and the sibling linkedin_ads is never named as an alternative for LinkedIn ad data, so routing is left to inference.

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, and it does disclose the substantive behavioral facts: the fields returned (home state, regulator, services, passporting, warning-list flag) and the paid x402 access model at 0.01 USD per call, which is auth/cost context an agent needs. It stops short of stating what happens when no company matches (error vs empty result) or whether matching is fuzzy.

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?

Purpose and return scope are front-loaded in the opening clause, and the single trailing sentence about pricing is short and independently useful. No filler or repetition of the tool name.

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

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

For a one-parameter lookup with no output schema, the description covers purpose, returned fields and access cost, which is nearly everything an agent needs. The remaining gap is the negative-result behavior — how a company with no MiCA authorisation is reported versus one that cannot be found at all.

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 documents the single 'name' parameter with a 3-character minimum, so the baseline is high. The description adds modest semantic value by scoping the parameter to crypto firms of three specific types (exchange, broker, custodian), which the schema does not say.

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 concrete verb (check) and resource (MiCA CASP authorisation for a crypto company) and enumerates what is reported: home state, regulator, services, passporting and ESMA warning-list status. The entity-type parenthetical (exchange, broker, custodian) makes it easy to separate from a sibling like mica_token_status, which covers tokens rather than firms.

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

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

Usage is only implied by the phrase 'Check whether a crypto company... holds a MiCA CASP authorisation'. No alternatives are named and no when-not-to-use condition is given — e.g. it never says to prefer mica_token_status for token questions or what to do for non-EU entities. The 0.01 USD x402 note does at least flag that calls are paid, which is a real usage consideration.

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 must carry the full behavioral burden. It usefully discloses the payment model and cost ('Price 0.01 USD per call via x402') and the fields returned, but says nothing about what happens for an unrecognized or non-notified token, whether tickers are case-sensitive, or any error/rate-limit 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 capability and returned fields are front-loaded in the first clause, with context and pricing after. The regulator-deadline sentence earns its place as usage context, though the pricing note is somewhat appended rather than integrated.

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 one-parameter lookup with no output schema and no annotations, the description covers what is checked, what is returned, and the commercial terms. Only the negative-result behavior (token exists but has no notified white paper) is left unaddressed.

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 'token' parameter is fully described with examples, so the schema does the heavy lifting. The description echoes the same examples (USDC, EURC, RLUSD, USDT) without adding format or matching semantics, so it neither compensates nor detracts — baseline 3.

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

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

Names a concrete verb-and-resource pair: checks whether a stablecoin/e-money token has a MiCA white paper notified in ESMA's register, and enumerates the returned facts (issuer, home state, regulator). The scope is clearly token-level, which distinguishes it from sibling mica_casp (CASPs rather than tokens).

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

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

Gives an explicit business context — 'Key for EU CASPs ahead of the ESMA remediation deadline (8 Jan 2027)' — so an agent knows the situation that triggers this call. It stops short of naming an alternative or stating when not to use it (e.g. versus mica_casp or stablecoin_receipt), so no exclusions are offered.

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 exist, so the description carries the full burden, and it does well: it names the authoritative data source, discloses licensing (NLOD 2.0), and states a per-call cost of 0.01 USD via x402, which is critical pre-invocation context. It also lists the returned data categories (legal form, address, NACE, employees, VAT/register status, bankruptcy flags). It stops short of stating rate limits or failure behavior for a miss.

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

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

Two sentences, front-loaded with what the tool does and its data source, followed by pricing/licence. The long enumeration of returned fields is dense but each item is informative; little 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?

With no output schema, the description usefully enumerates the returned attributes, and adds pricing and licensing that no structured field supplies. For a two-parameter read tool this is close to complete; only miss/failure behavior and rate limits are absent.

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 both parameters (name, orgnr) are already fully documented, including the 'up to 5 candidates' behavior for name search. The description's phrase 'by organisation number or name' restates the schema without adding format or precedence guidance. Baseline 3 applies.

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

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

States a specific verb and resource – 'Norwegian company lookup in the official Brønnøysund Register Centre (Enhetsregisteret)' – with the lookup key (orgnr or name) and the field set returned. The country/register specificity implicitly separates it from dk_* and fi_company siblings, though no sibling is named outright.

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?

There is no statement of when to use this versus alternatives such as fi_company or lei_lookup, nor any prerequisites or exclusions. An agent must infer from the country qualifier that this is the Norwegian option, which is a reasonable inference but not explicit 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, the description carries the full burden and does reasonably well: it discloses the return fields (list, programme, reference, match_score, matched_alias), the pricing/access model (0.03 USD per call via x402), and an explicit accuracy disclaimer. It omits what happens with no matches (empty result vs error) and any rate limits, hence not a 5.

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

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

Three dense sentences, front-loaded with the capability and list coverage, then return shape, then the disclaimer and price. Nothing is redundant with the title or padding.

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

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

For a 3-parameter read tool with no output schema, the description covers scope, return fields, pricing and a disclaimer well. The remaining gap is the unexplained `type` parameter and the lack of routing against the eu_sanctions sibling.

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

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

Schema description coverage is 100%, so the schema already documents the required `name` and the `lists` subset codes (eu, ofac, uk, un), which the description merely echoes. The description adds no clarification for the opaque `type` parameter, whose schema description is literally 'type', leaving a real gap that baseline-3 scoring reflects.

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

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

States the specific verb 'Screen' plus the resources covered (person, company, vessel name) and enumerates all four sanctions lists screened simultaneously. An agent can distinguish it from the sibling eu_sanctions tool because the description makes clear this is a multi-list aggregation rather than an EU-only 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 carries a caveat ('Screening aid only; human review required') that implies a compliance-adjacent use case, but it never states when to call this versus the sibling eu_sanctions tool or when not to (e.g. name already screened). Usage is inferable from the list enumeration rather than explicitly guided.

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 behavioral burden. It usefully discloses the output contents, the 1:1 peg assumption, the pricing via x402, and a legal disclaimer, but it does not clarify read-only/idempotent behavior, x402 payment mechanics, rate limits, or error handling.

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 and contains no filler: purpose, rate assumption, output fields, disclaimer, and price are all stated efficiently. The first sentence is slightly dense, but the overall structure is appropriate.

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?

Because there is no output schema, the description should summarize return values, and it does: DKK/EUR values, ECB rates, tx reference, and booking note. It remains somewhat incomplete on input parameter specifics and x402 payment flow, but the core context 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 description coverage is 100%, so the baseline is 3. The description adds meaning for the receipt date, tx reference, and stablecoin amount/token, but it does not explain the network parameter or provide format details for any input.

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 resource: accounting voucher data for a stablecoin payment received by an EU/Danish business. It is specific enough to distinguish this tool from the Danish/EU data siblings, though it phrases the action as a noun phrase rather than an explicit verb.

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 gives a clear use context: a stablecoin payment received by an EU/Danish business, and adds a scope limitation with 'Not tax advice.' There are no close sibling alternatives to name, but it does not explicitly say when not to use the tool beyond the tax disclaimer.

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