toll402 – EU & Nordic Data (x402)

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 does well: it discloses the upstream data source (OpenStreetMap), the metered cost (0.005 USD per call via x402), and the shape of the result (normalised address, postcode, city, municipality, coordinates). It omits failure behavior for unparseable addresses and any rate/limit context, 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?

One front-loaded sentence that names the action, the output fields, and the cost, with zero filler. Nothing could be removed without losing 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?

No output schema exists, but the description effectively substitutes for it by listing the returned fields, and it also surfaces pricing and data provenance. What remains unstated is error behavior on invalid input, a minor gap for a single-input lookup tool.

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

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

Schema coverage is 100% and the single parameter documents itself as a free-text Danish address, so the description adds little beyond it. Its only marginal contribution is reinforcing the Danish domain constraint. Baseline 3 is appropriate for a one-param tool whose schema is complete.

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 two specific verbs (validate, geocode) against a specific resource (Danish address) and enumerates the returned fields, so it is unmistakably distinct from siblings like dk_company or dk_weather. An agent can route to 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 purpose makes the intended use reasonably self-evident, but there is no explicit when-to-use, no when-not, and no mention of alternatives or prerequisites. The Danish-only scope hint is only implicit in the name and the phrase 'Danish address'.

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 behavioral burden. It helpfully discloses the upstream source (CVR register via cvrapi.dk) and a concrete cost (0.01 USD per call via x402) — meaningful context an agent needs before spending money. However, it omits failure behavior (e.g., what happens when no match is found), whether both parameters are optional, and any rate/credential requirements.

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

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

Two compact sentences, front-loaded with purpose and returned fields, ending with provenance and pricing. 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?

No output schema exists, and the description compensates by listing the returned fields and the data source, plus a pricing detail. It falls short only on edge cases: no-match handling, parameter precedence, and whether a call is billed on failure.

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 schema descriptions are tautological ('cvr' for cvr), so the description does add some meaning by labeling them as CVR number and company name. It still doesn't clarify that the two are alternatives rather than combinable filters, nor what happens 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 ('Danish company lookup') and enumerates the returned attributes (legal name, address, status, industry, type, employees), which clearly separates it from the other dk_* utility siblings like dk_address. An agent knows exactly what this tool fetches.

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 'by CVR number or name' phrasing implies two lookup modes, but there is no explicit guidance on precedence (e.g., prefer CVR when available), no statement of when not to use it, and no alternatives named. Usage must be inferred from the sibling list, which contains no competing company-lookup tool.

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

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

With no annotations, the description carries the full burden; it does earn credit for disclosing a real behavioral trait absent from structured fields — a 0.005 USD/call x402 charge. However, it is silent on defaults (is `date` optional? does it default to today?), timezone/day-boundary handling, whether a window may span midnight, and whether prices include tariffs or VAT. For a paid tool with zero annotation coverage, these omissions are meaningful.

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

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

Two sentences, front-loaded with the capability and followed by the cost disclosure. Nothing is padded or 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?

The purpose is complete, but for a tool with no output schema the description never hints at the return shape (window start/end, average price, savings) or what happens on an invalid window. An agent knows what to ask for but not what it will get back.

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 description supplies the area domain (DK1/DK2) that the placeholder schema ('description: area') entirely lacks. But for the other two params it mostly restates the schema, and the accepted `date` format (ISO vs. other, plus default behavior) is left undefined despite the schema allowing string/number/boolean unions. Marginal added value over the nominal 100% coverage.

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

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

States a specific operation (find the cheapest contiguous N-hour window), the resource (day-ahead spot prices in DK1/DK2), and the intended consumer (a shiftable load). A reader can immediately separate it from the sibling dk_power_price, which returns raw prices rather than an optimized window. It loses a point only because it never names that sibling explicitly.

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

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

The parenthetical examples (EV charging, heat pump, batch job) give concrete, recognizable when-to-use context, and the 'N hours / given day' framing tells the agent what inputs drive selection. There are no stated exclusions or named alternatives for the case where the agent wants the raw price curve instead of an optimum.

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 behavioral burden. It usefully discloses the data source (Energinet) and per-call cost via x402, but does not cover rate limits, freshness, or error behavior.

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

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

The description is a single, front-loaded sentence with no wasted words. It covers purpose, area options, date, units, return aggregates, source, and cost efficiently.

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 two-parameter data retrieval tool with no output schema, the description is largely complete. It describes the returned values and metadata such as source and cost. Minor gaps remain around payment mechanics and output structure, but nothing critical prevents correct invocation.

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%, but the schema's description for 'area' is merely 'area'. The tool description adds real meaning by clarifying that area means DK1 (West) or DK2 (East). The date format and default are covered by the schema.

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

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

The description states a specific verb and resource: Danish day-ahead electricity spot prices per 15 minutes for DK1 or DK2 on a date. It also specifies currencies, units, and aggregate values. It does not explicitly distinguish this tool from the sibling dk_power_cheapest_window, despite mentioning cheapest quarter.

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

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

The description explains what the tool returns but gives no explicit guidance on when to use it versus alternatives such as dk_power_cheapest_window. The existence of a closely related sibling tool makes this omission more significant.

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 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 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 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 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?

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.