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

No annotations are provided, so the description carries the full burden. 'Return ... metadata' implies a non-mutating, argument-free read, but it does not explicitly confirm read-only semantics, idempotency, or whether any network/auth prerequisites apply. For a trivial no-arg metadata tool this is a modest gap rather than a serious one.

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 sentence with no filler, front-loading the action and the data source. Nothing could be removed without losing identifying 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?

With no output schema and no annotations, the description is the only source of information about the return value, and it does not indicate what fields the licence/attribution payload contains (licence name, URL, attribution string). Adequate to select the tool, but thin for correct downstream use of 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no inputs are needed to obtain the licence metadata.

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 (Return) and a specific resource (Fintraffic Digitraffic CC BY 4.0 licence and attribution metadata), which distinguishes it from the many sibling *_licence_info tools by naming the exact data source and licence. It is only short of a 5 because 'attribution metadata' remains abstract about what is actually returned.

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 can infer this is the tool to call when it needs licensing/attribution terms for Digitraffic data. However, there is no explicit guidance on when to call it (e.g. before redistributing Digitraffic data) and no mention of the related digitraffic_port_calls tools it complements.

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 add real context: the upstream source (Fintraffic Digitraffic Marine API) and its CC BY 4.0 licensing, plus the fact that both live and scheduled calls are included. It is silent on operational behavior an agent needs — pagination/truncation via maxResults (max 200), behavior on empty port lists, refresh cadence, and whether the feed is open-access or keyed.

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 sentence, front-loaded with the verb and resource, with the field list and attribution packed efficiently into parentheticals. Nothing is redundant and nothing could be cut 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?

Four undocumented parameters, no annotations, and no output schema mean the description is the only source of semantics — yet it explains none of the parameter behaviors and nothing about result size or truncation. For a filtering tool with a defaulted array of port codes, that leaves the agent guessing at invocation correctness.

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

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

Schema description coverage is 0%, so the description must carry the burden for all four parameters and does not. It never explains that 'ports' expects UN/LOCODE codes like the FIHEL default, what cargoOnly filters on, what maxResults caps (200), or what vesselQuery matches against (name vs IMO). Only a loose hint is available via the 'cargo status' and 'IMO' mentions in the field list.

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 (fetch) and resource (live and scheduled Baltic & Finnish vessel port calls) and enumerates the returned fields (ETA, ETD, ATA, ATD, berth, IMO, cargo status, agents), which is far more informative than the bare name. It does not, however, distinguish itself from the sibling digitraffic_port_congestion_summary, which covers overlapping port data.

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

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

The description never says when to choose this tool over digitraffic_port_congestion_summary, nor does it state any preconditions or exclusions. Usage must be inferred entirely from the resource name and the field list.

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 leaves major traits undisclosed: the aggregation time window is never stated (over what period are calls counted or turnaround averaged?), it doesn't confirm this is a read-only summary, and it says nothing about result shape or cardinality. The CC BY 4.0 attribution note is genuinely useful extra context, which keeps this above a 1.

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 sentence, front-loaded with the verb and the aggregated metrics, with no filler. It is efficient but borders on under-specification rather than excess.

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?

An aggregation tool with no output schema and no annotations needs the description to define the aggregation window, the granularity of results, and the safety profile. None of these are present, so an agent cannot confidently predict what comes back or how to scope the query.

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

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

Schema description coverage is 0%, so the two parameters are undocumented anywhere. The description gestures at them obliquely ('across Finnish ports' for the ports array, 'cargo share' for cargoOnly) but never clarifies the expected port identifier format or whether an empty ports array means all ports.

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 ('Aggregate') plus concrete metrics (port call traffic, cargo share, active berths, average turnaround) scoped to Finnish ports. It implicitly contrasts with the raw sibling digitraffic_port_calls, but never names it, so differentiation requires inference.

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

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

No statement of when to use this aggregation rather than digitraffic_port_calls, and no mention of whether both should be combined. The only situational hint is 'across Finnish ports', which is scope, not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses official ECB EUR reference rates and prior-business-day fallback, but it does not clarify side effects, unsupported-currency behavior, output shape, or other operational constraints.

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

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

The description is a single front-loaded sentence with no wasted language. It immediately communicates the core action, rate source, and fallback behavior.

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 are no annotations and no output schema, while the input schema has nested fields and batch constraints. The description gives the core purpose and fallback rule but is not complete enough about input fields, limits, or return values for an agent to call it confidently.

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

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

Schema description coverage is 0%, and the single top-level parameter contains a nested invoice object with several fields. The description only vaguely references invoice amounts and currencies, leaving date, invoiceId, toCurrency default, and batch limits undocumented.

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 B2B invoice amounts across currencies. It also names the rate source and fallback behavior, making it clearly distinguishable from a generic FX-rate retrieval sibling such as ecb_fx_rates.

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

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

The description implies the tool is for B2B invoice currency conversion, which gives some usage context. However, it does not explicitly say when to use this versus ecb_fx_rates, nor does it state any exclusions or preconditions.

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 must carry the full behavioral burden. It signals a read-only public official source and the SDMX 2.1 protocol, but omits critical behavior: the lastNObservations default of 5 means a bare call silently returns only five observations per currency, and nothing is said about how that interacts with startPeriod/endPeriod, rate limits, or response shape.

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 no filler, naming the source and protocol up front. It is efficient, though its brevity comes at the cost of the missing operational detail noted elsewhere.

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 four optional parameters, no annotations, and no output schema, the description should explain default behavior and output structure. Instead it leaves the agent guessing about what a default call returns and how the period and observation-count parameters combine.

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

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

Schema description coverage is 0% for all four parameters, and the description adds almost nothing: it does not explain the date format for startPeriod/endPeriod, the ISO currency-code expectation, or the precedence between lastNObservations and the period range. The 'SDMX 2.1' mention is only a weak hint at period formatting.

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: fetching official ECB daily and historical EUR reference exchange rates. This clearly separates it from ecb_convert_invoices (invoice conversion) and ecb_policy_rates_and_inflation (policy rates), though it never names those siblings 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?

There is no guidance on when to choose this tool over ecb_convert_invoices or ecb_policy_rates_and_inflation, and no stated preconditions. Usage is only inferable from the resource name.

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; it does signal that this is a read-only metadata lookup rather than a data query, which is useful. It says nothing about whether the call is cached, whether it requires no auth, or what form the policy text takes, leaving behavioral traits thin for a no-annotation 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 front-loaded sentence with the resource stated first and a qualifier ('ESCB statistics') that scopes it. No filler or redundancy to trim.

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 parameters and no annotations, this is a simple static-metadata endpoint, and the description covers what it retrieves (reuse policy plus attribution metadata). The absence of an output schema means it could say more about the shape of the returned policy/attribution content, but for a tool this simple it is nearly sufficient.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description adds no misleading parameter expectations either.

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 ('Return') and a specific resource ('European Central Bank (ESCB) statistics reuse policy and attribution metadata'), which is enough to distinguish it from data-returning siblings like ecb_fx_rates. It does not explicitly contrast with the many other *_licence_info siblings, but the 'ECB/ESCB' qualifier makes the scope 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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of when this must be consulted relative to using ECB statistics. The usage is only implied by the word 'policy' and 'attribution metadata' — an agent can infer this answers licensing/compliance questions, but must supply that context itself.

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 implies a read-only fetch by using "Fetch", but does not disclose authentication needs, rate limits, data freshness, return format, or how defaults affect results.

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 filler. Every phrase identifies a concrete data resource, and nothing 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?

The tool has two schema parameters with 0% description coverage, no annotations, and no output schema. The description identifies the datasets but leaves out parameter usage, defaults, return shape, and operational behavior, which is insufficient for confident 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 0%, and the description does not mention either parameter by name. "Euro Area / EU country HICP annual inflation rates" vaguely hints at the inflationAreas parameter, but the default country list and valid codes are unexplained, and lastNObservations is entirely undocumented.

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

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

The description uses a specific verb ("Fetch") and names the exact data resources: Eurosystem key policy rates (DFR, MRR_FR, MLFR) and HICP annual inflation rates. This clearly distinguishes the tool from unrelated siblings like ecb_fx_rates or ecb_convert_invoices, though it does not explicitly route against those alternatives.

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 when-to-use guidance, no exclusions, and no mention of alternatives such as ecb_fx_rates. The description says what data is fetched but gives no context on when an agent should choose this tool over sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only informational operation by saying "Return" and lists the kind of data returned, but it does not state authentication needs, rate limits, pagination behavior, or what happens if no list is loaded.

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 that states the scope and return content without any redundant wording. Every part of the sentence contributes useful information.

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

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

For a parameterless informational tool with no output schema, the description adequately explains the return values and the scope of the loaded list. It could be slightly more complete by clarifying prerequisites for loading the list or how to obtain it, but the core return contents are covered.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The baseline for a parameterless tool is 4, and the description does not need to compensate for missing parameter documentation.

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 ("Return") and specific resources (publication metadata, entity counts split by persons vs enterprises, active sanctions programme codes) with a clear scope (currently loaded EU Consolidated Financial Sanctions List). It is clear what the tool does, but it does not explicitly distinguish itself from the screening and lookup siblings.

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

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

The description offers no guidance on when to use this tool versus alternatives such as eu_sanctions_screen or eu_sanctions_lookup. The intended usage is only implied by the returned content, with no exclusions or prerequisites stated.

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

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

With no annotations, the description carries the full transparency burden and it discloses only the data source, not behaviour: it is silent on whether multiple filters are ANDed or ORed, how many results come back by default, or what happens when a lookup key is unknown. The undisclosed result cap (limit default 20, max 100) and nil-result handling are exactly the details an agent needs before calling a compliance lookup.

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 sentence that front-loads the verb and resource, then packs the key formats inline as parenthetical examples. Nothing is wasted and the important content leads.

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 six-parameter compliance lookup with zero schema descriptions, no annotations and no output schema, the description leaves too much open: filter composition semantics, default/limit behaviour, and result shape are all unaddressed. It covers the 'what' adequately but not the 'how it behaves'.

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

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

Schema description coverage is 0% across six parameters, so the description must compensate, and it does partially: it names five of the six concepts and even supplies format examples (EU.27.28 for reference number; RUS, IRQ, IRN for programme; ISO-2 for country). It never mentions the `limit` parameter nor explains that all filters are optional or how they combine.

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

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

The description uses a specific verb ('Look up') plus a precise resource ('sanctioned entities in the official EU Consolidated Financial Sanctions List') and enumerates the lookup keys, which is far more informative than the tool name alone. It does not, however, explicitly differentiate itself from sibling tools eu_sanctions_screen and eu_sanctions_list_info, so an agent must infer the boundary itself.

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

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

Listing the accepted key types (EU reference number, logical ID, programme, subject type, ISO-2 country) implies when the tool is useful, but there is no explicit when-to-use/when-not guidance and no routing to eu_sanctions_screen or eu_sanctions_list_info. Usage remains inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does real work: it discloses that fuzzy hits are labeled 'possible match' rather than determinations, and that every response carries a publication date, source attribution, and a not-legal-advice disclaimer. It omits read-only status confirmation, rate limits, and the 200-query batch ceiling, 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?

Three front-loaded sentences: purpose first, match semantics second, response caveats third. Every sentence adds information an agent needs and there is no 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 6-parameter tool with no output schema, the description covers result interpretation and disclaimers well but leaves the four optional filters unexplained and never describes the shape of a match entry in the response. Adequate but with real gaps for a compliance-screening call.

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

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

Schema coverage is 67%, so the schema already documents queries, country, programmes, subjectType, and fuzzyThreshold. The description restates the query input types without adding new meaning and says nothing about the optional filters or how fuzzyThreshold relates to the 'possible match' labeling.

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

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

The description names a specific verb (screen) and resource (EU Consolidated Financial Sanctions List, DG FISMA/FSF), plus the inputs it accepts (names, EU reference numbers, identification numbers). It never names or distinguishes itself from the sibling eu_sanctions_lookup, so an agent must infer the split from the tool name 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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of the sibling eu_sanctions_lookup despite near-identical subject matter. The screening scope is implied by the verb, but nothing steers the agent between the two sanctions tools.

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

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

With no annotations, the description carries the full behavioral burden, yet it does not state what is returned, how 'latest' is defined, refresh frequency, result limits, or whether authentication is needed. 'Fetch the latest' implies freshness but discloses nothing concrete.

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 no filler, so the purpose lands immediately. It is slightly under-informative rather than verbose, which caps it at 4 rather than 5.

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

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

No output schema, no annotations, and an undocumented 3-value enum mean the description should explain the feed modes. Instead it covers only part of the parameter space and says nothing about the return payload, leaving the agent under-equipped to call the tool correctly.

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

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

Schema description coverage is 0% for the single 'feed' enum parameter (exploited, critical, latest), so the description must compensate. It gestures at 'exploited' and 'critical' but never explains the 'latest' option or the default value of 'exploited', leaving the enum semantics ambiguous.

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 (fetch) and resource (vulnerabilities) plus the source database (EU ENISA EUVD), which is clear. However, it names only two of the three feed modes and gives no cue distinguishing it from the sibling euvd_search_vulnerabilities, so an agent still has to inspect the schema to understand the tool's full scope.

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

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

There is no statement of when to use this feed tool versus euvd_search_vulnerabilities or euvd_lookup_by_id, and no mention of prerequisites, freshness cadence, or exclusions. The agent gets a purpose statement but no 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?

No annotations exist, so the description carries the full burden, and it does establish that the tool returns static policy/attribution metadata rather than live vulnerability data. However, it does not state that the operation is read-only and side-effect free, nor whether the policy is stable or could change, leaving minor behavioral questions open.

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 sentence with no filler, front-loading the action and the exact resource. Every word earns its place, and the acronym expansion adds real disambiguation value.

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

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

For a no-parameter metadata fetch with no output schema, the description identifies the content adequately enough to call it confidently. A brief note on what the metadata contains (e.g., licence terms vs. citation format) would close the remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter detail is missing because the schema is an empty object.

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 ('Return') and a precisely named resource ('ENISA European Vulnerability Database (EUVD) reuse policy and attribution metadata'), expanding the acronym so the agent knows the data source. It is clearly distinct from the sibling data tools like euvd_search_vulnerabilities and euvd_lookup_by_id, though it never explicitly names those alternatives.

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 usage is implied rather than stated: an agent can infer this is the call to make when it needs licence terms or attribution text before reusing EUVD data. There is no explicit 'call this when...' or note about whether it must be called before the other euvd_* tools.

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

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

No annotations exist, so the description carries the full disclosure burden. It establishes the authoritative data source, but says nothing about behavior on an unknown ID (empty result vs error), record completeness, rate limits, or authentication — gaps that matter little for a simple read but are still undisclosed.

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 sentence, front-loaded with the action and immediately followed by the two accepted ID formats. Nothing is redundant and nothing needs trimming.

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 read tool this is close to sufficient, but with no annotations and no output schema the description should at least sketch what a lookup returns (advisory/CVSS/exploitation fields) or what a miss looks like, and it does neither.

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

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

Schema coverage is 0% and the single parameter is just a minLength-3 string, so the description must supply the format. It does, via concrete CVE-2024-3400 and EUVD-2026-107265 examples that clarify the two accepted identifier grammars.

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 (look up) and resource (a vulnerability record by ID) and names the authoritative source (ENISA European Vulnerability Database). It implicitly distinguishes exact-ID lookup from the sibling euvd_search_vulnerabilities, but 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 phrase 'a specific CVE ID ... or EUVD ID' implies this is the exact-match path and the format examples make the input obvious, but there is no explicit when-to-use or when-not-to-use guidance and no mention of euvd_search_vulnerabilities as the alternative for keyword/range queries.

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

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

No annotations are provided, so the description carries the full disclosure burden. It says nothing about result limits, pagination, sorting, auth requirements, or what the response contains — for an 8-parameter search tool this is a meaningful gap.

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 packs in the resource and all filterable dimensions with no wasted words, though it stops short of additional useful 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?

With 8 parameters, no annotations, no output schema, and 0% schema coverage, the description should explain the 'size' parameter, pagination/result-limit behavior, and return shape. It covers most filter dimensions but omits these, leaving it insufficient for 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 coverage is 0%, so the description must compensate. It helpfully maps 'keyword'→text, 'CVSS score range'→fromScore/toScore, 'EPSS score range'→fromEpss, and 'exploited status'→exploited, but leaves the 'size' parameter entirely unexplained and gives no range units or boundary semantics.

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

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

States a specific verb ('Search') and a specific resource ('EU ENISA European Vulnerability Database'), plus the filter dimensions. An agent can distinguish it from euvd_lookup_by_id and euvd_licence_info, but it doesn't explicitly differentiate from the sibling euvd_exploited_and_critical.

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

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

Usage is implied by the enumeration of filter dimensions (keyword, vendor, product, score ranges, exploited status), but there is no explicit when-to-use or when-to-prefer-an-alternative guidance, and no mention of euvd_lookup_by_id for single-record retrieval.

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 computation method (residual load from Fingrid consumption, wind and solar forecasts), the direction of the ranking (lower = cleaner/cheaper), and the key caveat that no exchange prices are used. It omits return shape/pagination details, but the methodological disclosure is the substantive risk an agent needs.

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, zero filler, with the core ranking semantics front-loaded and the caveat trailing. Every sentence adds information the agent cannot get from the empty parameter schema.

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

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

The conceptual model is complete, but for a tool with no annotations, no output schema, and two completely undocumented parameters, the description should at minimum clarify what topN and hoursAhead control and what the ranked result looks like. As written, an agent can grasp the idea but must guess at invocation semantics.

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

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

Schema description coverage is 0% – neither topN nor hoursAhead has any description, no defaults or max ranges are explained in prose. The description's 'coming hours' loosely implies hoursAhead but says nothing about topN (how many ranked hours are returned) or the 1-24 / 1-72 bounds, so it fails to compensate for the coverage gap.

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

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

States a concrete verb+resource ('Ranks the coming hours by residual load') and defines the metric precisely (consumption forecast minus wind and solar, all Fingrid). It implicitly separates itself from siblings like fingrid_co2_intensity and price tools via 'NOT a price forecast', but never explicitly names an alternative.

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

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

The description says what the ranking means and warns it is a heuristic rather than a price forecast, which implies when it is appropriate. However it gives no explicit when-to-use guidance and does not route the agent to fingrid_co2_intensity, fingrid_series, or fmi_fingrid_nowcast for the underlying data.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses the data source (Fingrid dataset 396), units, geography, and the presence of a comparison and non-fossil share, but it omits data freshness/latency, what 'recent window' means, and any output/return details.

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 filler: metric, units, dataset, comparison, and secondary output are packed efficiently. Nothing extraneous is present.

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 one configurable parameter and no output schema, the description should explain how hoursBack affects the result and what the return values contain. It only partially names the returned concepts (emission factor, non-fossil share) and leaves the comparison window and parameter behavior unclear.

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

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

Schema description coverage is 0%, and the description never mentions the sole parameter hoursBack or how it relates to the 'recent window'. The parameter's meaning is left entirely to its name and schema range/default, so the description adds no semantic value.

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 metric and scope: 'Current emission factor of electricity consumed in Finland' with units gCO2/kWh, dataset 396, comparison to a recent window, and non-fossil share. It is clearly distinguishable from generic siblings like fingrid_series or fingrid_dataset, though it does not name alternatives 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?

There is no explicit when-to-use guidance, no exclusions, and no comparison to sibling tools such as fingrid_grid_snapshot or fingrid_cheap_hours. The phrase 'vs the recent window' implies a comparative current reading but does not route the agent among alternatives.

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. It says the data is 'raw' and limited to CC BY datasets, but gives no information on resolution, units, pagination, rate limits, or licensing attribution requirements attached to the results.

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 first sentence is tight and front-loaded, but the bulk of the text is an unstructured id dump with no indication of what each id represents, which makes it hard to skim and only partly earns its space.

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

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

With no annotations, no output schema, and no schema descriptions, the description should explain the time window behavior and dataset semantics. It leaves the agent guessing about the default 24h window, maximum 168h, and what each id returns.

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

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

Schema description coverage is 0%, so the description must compensate, but it never explains datasetIds (array of 1-20 integers) or hoursBack (default 24, max 168). The curated id list helps with datasetIds values but gives no meaning to the ids or the time window.

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 ('raw time series for given Fingrid dataset ids') and scopes it to Fingrid-produced CC BY datasets. It does not, however, distinguish this from the sibling fingrid_series, which an agent could easily confuse with it.

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

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

There is no statement of when to use this tool rather than fingrid_series, fingrid_grid_snapshot, or fingrid_cheap_hours. The curated id list implies usage but never says 'use this when you need arbitrary/raw series' or names any alternative.

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 does convey two useful traits — the data is real-time and 'latest' (freshness semantics), and it is a broad multi-metric aggregation rather than a filtered query. It says nothing about refresh cadence, units, upstream rate limits, caching, or error behavior when the upstream API is unavailable, which matters for a live-data 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 with zero filler, front-loaded with the freshness attribute ('Latest real-time') and the geographic scope ('Finnish') before the field list. Every clause names a returned quantity and earns its place.

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

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

With no output schema and no annotations, the description must stand in for both. It does enumerate the metrics, which is the most valuable part, but leaves the response envelope (flat object? nested by metric?), units (MW, Hz, gCO2/kWh), and timestamp field unspecified, and gives no routing to closely related siblings. Adequate to call, not quite sufficient to consume results confidently.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The enumeration of returned metrics helpfully compensates for the absence of any output 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 names a specific resource and scope: a real-time snapshot of Finnish grid metrics from Fingrid, enumerating the exact fields returned (consumption, production, wind, nuclear, hydro, net import, frequency, system state, CO2 factor, non-fossil share). An agent can tell this is the 'current state' reader rather than a time-series or forecast tool. It lacks an explicit verb and doesn't name the sibling it differs from (fingrid_series, fmi_fingrid_nowcast), keeping it below 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?

No when-to-use guidance appears. With siblings such as fingrid_series, fingrid_co2_intensity, fingrid_cheap_hours and fmi_fingrid_nowcast in the same family, the description never says to pick this tool for a single current reading vs. historical series or forecasts. 'Real-time'/'Latest' faintly implies currency, but that is inference, not guidance.

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

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

No annotations exist, so the description carries the full burden, yet it only lists three topics. It does not state that the call is read-only, requires no authentication, or what shape the answer takes (terms text vs. structured fields), and it does not say whether rate-limit values are the caller's quota or the upstream API's policy.

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?

There is no wasted language, but the three-word fragment is under-specified rather than tight: it is not a sentence, has no structure, and gives the agent nothing front-loaded beyond keywords. Brevity here costs clarity rather than buying it.

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

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

With no output schema and no annotations, the description is the only source of truth for what this call yields, and it delivers three nouns. For a compliance/attribution tool the agent needs to know what content comes back (licence name, attribution string, quota numbers) and whether it applies to all Fingrid tools.

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

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

The tool takes zero parameters, so the baseline is 4. The empty schema means there is nothing for the description to disambiguate, and the listing of covered topics is sufficient parameter-level context.

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

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

The description is a bare noun list ("Licence, required attribution, rate limits.") that essentially restates the title "Licence and attribution for Fingrid data" plus one extra item. There is no verb and no explicit statement that it returns licensing terms for Fingrid data, leaving the agent to infer purpose from the tool name and title.

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?

No when-to-use guidance is given, and no sibling is named even though the catalogue contains many parallel licence_info tools (ecb_licence_info, ted_licence_info, fmi_licence_info, digitraffic_licence_info, etc.) that an agent must distinguish this from. The agent must infer that this applies specifically to Fingrid data from the name alone.

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

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

With no annotations, the description carries full behavioral burden. It explains what some groups contain but omits licensing/authentication needs, data freshness, units, return format, and whether the call is read-only—all relevant for a Fingrid data 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 front-loads the purpose and then enumerates groups and parenthetical details. It is efficient, though the nested parentheses make it slightly harder to parse than a bulleted list would.

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

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

The description is incomplete for a tool with a time-range parameter, no output schema, and no annotations. It never explains how 'hoursBack' affects results, what the returned series look like, or any licensing constraints, leaving the agent to guess on important dimensions.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully clarifies the contents of the 'reserves' and 'imbalance' groups beyond the bare enum, but says nothing about the 'hoursBack' parameter (default 24, range 1–168), leaving half the parameters semantically thin.

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 ('Time series') and enumerates the exact group values, so an agent knows what data it retrieves. It does not distinguish this generic series tool from siblings such as fingrid_grid_snapshot or fingrid_co2_intensity, leaving potential overlap unclear.

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 explicit guidance on when to use this tool versus the specialized siblings. The group list implies some usage, but given tools like fingrid_grid_snapshot and fingrid_co2_intensity, the absence of routing guidance is a real gap.

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 add useful context by naming the upstream source (FMI), the payload standard (CAP 1.2), the licence (CC BY 4.0), and the coverage area. It says nothing about authentication, rate limits, refresh cadence, pagination, or what the response looks like, leaving real gaps for a live-data 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 tightly packed sentence with the resource and coverage front-loaded and the licence tucked into a parenthetical. Nothing is wasted, though it is dense enough that the parameter hints are absent entirely.

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 five parameters, zero annotation coverage, no output schema, and no parameter documentation, the description only covers what the data is. An agent still cannot tell how to filter by region, what includeCancelled or minSeverity do in practice, or what the return payload contains.

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

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

Schema description coverage is 0% and the description never mentions any of the five parameters; regionFilter in particular is a free-form string with an empty default and no explanation of expected format. Enum'd language and minSeverity plus the bounded maxAlerts are partially self-documenting in the schema, but the description adds no meaning beyond that.

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 (fetch) and resource (active FMI CAP 1.2 warnings), and enumerates hazard types and geographic scope (Finland and Baltic Sea). It clearly separates itself from siblings like fmi_station_weather or fmi_weather_observations by being warning-focused, though it never explicitly names an alternative.

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

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

The word "active" implies this is for current in-force warnings rather than historical observations, which implicitly signals when to reach for it. However, there is no explicit when-to-use/when-not guidance and no mention of the sibling fmi_alerts_licence_info or fmi_fingrid_nowcast as alternatives.

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 useful context: the licence is CC BY 4.0 and the payload is attribution metadata, which tells the agent this is a safe informational read. It stops short of stating that the call takes no arguments, needs no auth, and returns a static/licence text rather than dynamic data.

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

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

A single front-loaded sentence with no filler, hedging, or repetition. Every word (tool subject, licence identifier, and payload type) 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 zero-parameter, no-output-schema tool this is close to sufficient: it names both the licence and the attribution content the caller will get. The main residual gap is that with no output schema nothing describes the shape of the response (text block vs. fields vs. URL).

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming it is argument-free. Baseline 4 applies; the description correctly does not waste words on phantom parameters.

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

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

Clear verb ('Return') plus a specific resource ('FMI CC BY 4.0 open-data licence and attribution metadata'), which distinguishes it from the fingrid/ecb/vies licence siblings. It does not, however, differentiate itself from the closely named 'fmi_fingrid_licence_info', which an agent could easily confuse with it.

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

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

There is no explicit when-to-use or when-not-to-use statement and no named alternative. Usage is only implied by the resource itself — an agent infers it should call this when it needs attribution text for FMI data. The nearby 'fmi_fingrid_licence_info' is never addressed as a routing choice.

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 load, and it does disclose the substantive contents of the response (licence terms, attributions, rate limits) as well as implying a read-only informational call. It stops short of saying the payload is static/cached or whether attribution must be surfaced to end users in a particular form.

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 sentence with no filler, front-loading the return contents and the dual-provider scope. Every clause (licence, attributions, rate limits, both providers) carries information an agent needs.

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

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

There is no output schema, so the description substitutes by naming what the response contains, which is sufficient for a zero-parameter compliance endpoint. It could be stronger by tying the call to the nowcast feed workflow or noting whether attribution obligations differ between the two sources.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the description suggests hidden inputs, which is consistent with the empty 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?

Uses a specific verb ('Returns') and enumerates the resource: CC BY 4.0 licence details, required attributions, and rate limits. The phrase 'for both FMI and Fingrid' signals this is the combined scope, which separates it from the single-provider siblings fingrid_licence_info and fmi_alerts_licence_info, though it never names them 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?

No explicit when-to-use statement or named alternatives; the reader must infer from 'both FMI and Fingrid' that this is the right call when consuming the combined nowcast feed rather than a single provider. The title's reference to the nowcast feed carries this routing signal, not the description itself.

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 lists included features and excludes Nord Pool/ENTSO-E prices, but it does not state read-only behavior, data freshness or latency, response shape, or limits. For a data feed with no output schema, this leaves substantial behavioral gaps.

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 three-sentence description front-loads the core 'hourly joined feature feed' and then packs in source variables and feature details without obvious filler. It is dense but appropriately sized for a complex joined data product.

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

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

Given five undocumented parameters, no annotations, and no output schema, the description should explain parameter usage and return shape but does not. It gives a useful inventory of included data but is incomplete for 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?

All five parameters (topN, places, hoursBack, hoursAhead, includeStationBreakdown) have 0% schema description coverage, and the description never explains their meaning, defaults, units, or effects. The mentions of 'hubs' and 'hourly' are too indirect to map meaningfully to the places and time-window parameters.

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

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

The description specifies a joined hourly feature feed and enumerates the FMI and Fingrid variables it combines, so the agent can tell it apart from raw weather or grid-series tools. It does not explicitly name sibling alternatives, but the 'joined feature feed' framing and the no-day-ahead-price note provide useful differentiation.

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

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

There is no explicit when-to-use/when-not guidance or named alternative among tools like fmi_station_weather, fingrid_series, or fingrid_cheap_hours. The phrase 'Hourly joined feature feed' implies its nowcasting use case, but the agent must infer that from context.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it only adds 'live' (freshness) and a CC BY 4.0 license note. It says nothing about rate limits, authentication, coverage/station availability, or what happens when no recent observation exists for a 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?

A single well-formed sentence with the data scope front-loaded and no filler; the license tag is the only appended element. It is efficient, though its brevity comes partly at the cost of the missing parameter and usage detail.

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-optional-parameter read tool with no output schema, the description establishes what the data is and its freshness, which is close to sufficient. It falls short because neither parameter is explained and no annotation fills that gap, leaving the agent to guess the effect of hoursBack and maxStations.

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

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

Schema description coverage is 0% and the description never mentions 'hoursBack' or 'maxStations'. The schema supplies types, defaults and bounds, but the description contributes no meaning about what the lookback window or station cap actually control, so it does not compensate for the coverage gap.

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

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

States a specific verb ('Fetch'), a specific resource ('sea-level and water temperature observations'), and constrains it geographically ('Baltic Sea mareograph ... Finnish coast') plus temporally ('live'). This implicitly separates it from weather siblings like fmi_station_weather and fmi_weather_observations, though it never names them 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 word 'live' hints that only recent data is returned, but there is no explicit statement of when to pick this over fmi_weather_observations, fmi_station_weather, or fmi_fingrid_nowcast, and no prerequisites or exclusions are given. An agent must infer the choice from the resource name alone.

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

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

With no annotations, the description carries the full burden and it does disclose useful traits: the upstream is FMI's WFS, data is hourly, and no Fingrid API key is needed. It says nothing about rate limits, result size/ordering, units, time zone, or what a response looks like, which leaves meaningful behavioral gaps for a data-fetch 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 sentences, no filler, with the core purpose front-loaded and the variable/location list packed into one clause. The trailing key-requirement sentence is short and relevant, so nothing is wasteful, though the parenthetical list is dense enough to be slightly hard to scan.

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 annotations, no output schema, and no parameter documentation means the definition is thin for a 3-parameter data tool: units, time zone, and the historical pull window are entirely unstated. The description also does not explain that places is capped at 10 or that past hours can be requested 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 description coverage is 0%, so the description must compensate for all three parameters and it does not: places, hoursBack, and hoursAhead are never mentioned. It also omits the historical window implied by hoursBack (0–72) and the 72-hour cap on hoursAhead, both of which materially affect results.

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 — hourly FMI WFS weather forecast — and enumerates the six variables and the five hub locations it covers. It implicitly separates itself from fmi_weather_observations by saying 'forecast', but never names that sibling or fmi_fingrid_nowcast explicitly, so the differentiation is inferred 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?

There is no when-to-use or when-not-to-use guidance; the agent is not told how to choose between this and fmi_weather_observations or fmi_fingrid_nowcast. The only routing hint is 'Does not require a Fingrid API key', which weakly implies it is a keyless alternative to the Fingrid series tools, but no condition or exclusion is spelled out.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'live' data and a CC BY 4.0 license, but omits important details such as whether the operation is read-only, permission requirements, rate limits, or error handling 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, efficient sentence that front-loads the verb and resource. It is appropriately sized for the tool's simplicity, though the parenthetical list of variables makes it slightly dense.

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

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

Given the tool's simplicity (2 parameters, no output schema) and the absence of annotations, the description should explain the parameters and basic behavior. Instead, it omits any parameter semantics and does not describe return format or constraints, leaving significant gaps for an agent to infer.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It hints that 'places' refers to Finnish cities, but gives no explanation of the 'hoursBack' parameter or its valid range (1–24 hours), leaving both parameters largely unclear.

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 ('Fetch') and resource ('live synoptic weather station observations') and lists the measured variables, making the tool's purpose clear. It does not, however, differentiate this tool from the sibling 'fmi_station_weather', which likely serves a similar role.

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?

No guidance is given on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The description simply states what the tool does without contextual usage instructions.

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. It usefully discloses a scope boundary — company-level data only, no person data, representatives or addresses — which is real behavioral context an agent needs before calling. However it says nothing about result volume, whether maxPerEvent caps per event type, pagination, or licensing, which for an unannotated, schema-less-output tool is a meaningful gap.

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

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

Three sentences, front-loaded with what is returned, then the necessary event-type vocabulary, then the scope exclusion. The long enum list earns its place because no schema enum exists; nothing is redundant.

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

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

With no annotations, no output schema and six parameters, the description should also say what a returned event record looks like and how maxPerEvent bounds the response. It covers what the tool returns conceptually and its privacy limits, but leaves the agent guessing about result shape and volume.

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

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

Schema coverage is 67% and critically the eventTypes array has no enum, so the description's full list of valid event-type strings (new_company, name_change, liquidation_ended, merger, demerger, etc.) supplies semantics the schema does not. Date-window semantics are implied by 'date window'. location, companyForm and maxPerEvent are left to their schema descriptions.

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

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

States a specific resource (PRH Trade Register events) and scope (registered in a date window), and enumerates the event categories covered. It does not distinguish itself from the sibling prh_watch_companies, so an agent cannot tell from the text alone which PRH tool to pick.

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 date-window framing and the 'default yesterday' schema defaults imply a daily register-monitoring use case, but the description never says when to use this versus prh_watch_companies or what to do when no window is supplied. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden, and it does disclose substantive content: the response covers attribution obligations and concrete restrictions (no PRH/YTJ logos, no look-alike UI, GDPR). It never states that the tool is read-only with no side effects, nor what form the terms come back in, which is a notable gap given zero annotation coverage.

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 compact phrase with zero filler, and the most decision-relevant content ('restrictions (no PRH/YTJ logos, no look-alike UI, GDPR)') is front-loaded and parenthetical. It is a noun fragment rather than a sentence, which costs a little clarity but wastes nothing.

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 zero-parameter, zero-output-schema tool this is close to adequate: the agent knows the topics returned. However, nothing indicates the return format, whether the terms are intended for human display or machine parsing, or whether attribution obligations propagate to downstream use — the main things an agent needs to act on licence output.

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

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

The schema has zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description implicitly confirms this is a no-input informational lookup rather than a query tool.

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

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

The description names the resource precisely — licence, attribution and restrictions for PRH data — and even enumerates the restriction types covered (no PRH/YTJ logos, no look-alike UI, GDPR). It lacks an explicit verb ('returns/describes'), but an agent can tell what this tool is for versus siblings such as prh_company_events or prh_watch_companies, which serve entirely different purposes.

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?

No sentence says when to call this tool or what it should precede/follow. There is no mention of the sibling *_licence_info tools (fingrid, ecb, fmi, vies, euvd, digitraffic, ted) or of whether licence terms must be checked before redistributing PRH data, so usage must be inferred entirely from the tool name.

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 that snapshots are kept locally per watchName, which fields are reported, and that person data is omitted, but it does not explain first-run behavior, whether the snapshot is updated by the call, or any persistence/side-effect semantics.

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

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

The description is two sentences, front-loaded with the core behavior and immediately followed by the key data-scope exclusion. There is no wasted language.

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 a useful partial picture: the fields reported and the company-only scope. It still leaves important completeness gaps around return shape, first-run behavior, and whether the local snapshot is mutated.

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

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

Schema description coverage is 0%, so the description must compensate for two undocumented parameters. It meaningfully explains watchName as the local snapshot key and identifies businessIds as Business IDs, but it does not add format details beyond what the schema already constrains.

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

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

The description uses a specific verb and resource: it checks Business IDs against a stored snapshot and reports named field changes. It also scopes the tool to company-level data and explicitly excludes person data. It does not, however, explicitly differentiate itself from the sibling prh_company_events tool.

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

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

The usage context is implied by 'last snapshot' and 'watchName', which suggests repeated checks over time. But there is no explicit guidance on when to use this instead of prh_company_events or when not to use it, and no prerequisites are stated.

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

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

No annotations are supplied, so the description carries the burden; it does disclose that rate limits and usage restrictions are part of the response, which is meaningful behavioral context about the upstream TED API. However, it does not state that the call is read-only/side-effect free, whether the values are static or cached, or the response shape.

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 enumerates the four things returned. No filler, no restatement 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?

With no output schema, the description usefully enumerates the returned content (licence, attribution string, rate limits, restrictions), which is the key information for this trivial lookup. It stops short of describing format or whether attribution must be displayed verbatim, which would have made it fully complete.

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

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

The tool takes zero parameters and the schema is empty, so there is no parameter semantics to explain; baseline is 4. Nothing in the description contradicts the empty 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 names the specific resource (licence, attribution string, rate limits and restrictions) scoped to TED data, and the title reinforces it. An agent can distinguish it from siblings like fingrid_licence_info or ecb_licence_info purely by the dataset qualifier, though no verb (e.g., 'returns') is used.

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 infers it should call this when it needs attribution text or rate-limit constraints before using TED endpoints such as ted_search_tenders. There is no explicit 'use when' clause or statement of what to do with the returned licence terms, but for a zero-parameter informational tool the intent is reasonably recoverable.

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 the most important job: disclosing that this tool is stateful and keeps state in a local file keyed by alertName. That is a non-obvious, high-impact trait an agent could not infer from the schema. It omits what the first call returns, whether state is durable across sessions, and whether results are ordered or deduplicated across different filter combinations.

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 sentence with no filler, and the differentiating trait (state-based deduplication via alertName) is front-loaded. Nothing to trim.

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 8-parameter, unannotated, no-output-schema tool, this covers the critical stateful behavior but leaves real gaps: what a first call (no prior state) returns, whether filters must stay constant between calls for the delta to be meaningful, and the shape of the returned notices. Adequate but short of complete.

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

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

Schema coverage is 75%, and the description compensates for the notable gap: alertName has no schema description, and the description explains exactly what it does (scopes the persisted state). It adds no detail on the other seven parameters, but those are documented in the schema.

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

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

States a specific behavior: returns only TED notices not returned by a previous call with the same alertName. The delta/stateful nature is unambiguous. It stops short of naming the sibling ted_search_tenders as the non-alert alternative, so the agent must infer the distinction from the name 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 rather than stated: 'previous call with the same alertName' hints that repeated calls with a stable alertName yield new notices. But there is no explicit when-to-use, no mention of when to prefer ted_search_tenders for a full search, and no guidance on alertName reuse or first-call behavior.

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

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It adds useful return context ('deduplicated, structured, organisation-level records with attribution') but does not disclose permissions, rate limits, pagination behavior, or how maxResults affects the result set.

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 tight sentences with no filler, and the primary purpose is front-loaded before the return characteristics. Every sentence contributes to the agent's understanding.

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 annotations and no output schema, the description provides the core search purpose and some return-value context. However, it omits sibling differentiation, usage conditions, and any output-shape guidance beyond 'organisation-level records', leaving meaningful gaps.

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

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

Schema description coverage is high (89%), so the schema already documents most parameters well. The description mentions CPV code, country, and publication date but adds no syntax or semantics beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: searching EU public procurement notices on TED, with the main filter dimensions (CPV code, country, publication date). It does not explicitly differentiate itself from the sibling ted_new_tenders_alert, so it is clear but lacks sibling positioning.

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

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

The description implies usage as a general search tool through its filter summary, but it never states when to use this tool versus ted_new_tenders_alert or any alternatives, nor does it give prerequisites or exclusions. Usage is inferable but not 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 must carry the behavioral burden. It implies a read-only, static licence/policy payload, which is consistent, but it doesn't state that the response is non-parameterized static text, nor does it mention response format, caching, or licensing constraints on reuse of the data itself. No contradiction with anything, but only partial 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?

A single front-loaded sentence that enumerates the returned artifacts without filler. Slight deduction because the phrasing 'reuse policy ... safeguard details ... attribution metadata' is dense but slightly abstract, and no short lead-in like 'Static licence info for VIES data' anchors it.

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

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

For a zero-parameter info tool with no output schema, the description should make clear what an agent receives and how to use it. It lists the categories but not the shape or granularity of the response, and gives no hint about pairing it with vies_validate_vat_batch for compliance/attribution workflows. Adequate but leaves gaps.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline of 4 applies; the description correctly does not waste words on parameters.

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

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

The description names a specific verb ('Return') and enumerates the exact resources delivered: VIES reuse policy, GDPR company-level safeguards, and attribution metadata. It is clearly a static informational/legal-metadata tool, distinct in substance from the sibling action tools like vies_validate_vat_batch. The only weakness is that, among the many '*_licence_info' siblings, it doesn't explicitly frame itself as the VIES-specific member of that family.

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 indication of when an agent should call this versus the other VIES tools or the other '*_licence_info' tools. No prerequisites, no mention of whether it is optional context to fetch alongside a VAT validation call. The agent must infer usage entirely from the tool name.

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 disclosure burden; it does convey that this is a real-time status probe over a fixed set of 28 EU member states plus XI, which is useful scope information. However, it says nothing about the response shape (per-country status?), caching/rate limits, or whether partial outages are reported, so key behavioral traits remain undisclosed.

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 zero filler; the scope qualifier ('all 28 EU + Northern Ireland (XI)') is the only extra detail and it earns its place.

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

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

There is no output schema and no annotations, so the description is the only source of information about results — yet it never describes what 'availability' looks like per database. For a simple zero-param probe this is nearly adequate, but an agent cannot predict the return structure.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description does usefully clarify that coverage is the full EU-28 plus Northern Ireland rather than a caller-selected subset.

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 ('Check ... availability') and a precise resource ('all 28 EU + Northern Ireland (XI) national VAT databases connected to the European Commission VIES gateway'). It is readily separable from the nearest sibling (vies_validate_vat_batch) because it reports database/service status rather than validating numbers, though 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?

Usage is only implied: an agent can infer this is a health/pre-flight check before running VAT validation, but the description never says when to call it, when not to, or which sibling to use instead. No prerequisites or conditions are stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses that validation uses the official VIES API and that GDPR sole-trader personal data is automatically redacted, but it omits operational behavior such as authentication requirements, rate limits, failure handling, and response format.

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 efficiently conveys the core action, data source, and two key behavioral traits.

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 are no annotations and no output schema, so the description must do more to make the tool fully usable. It leaves supplierCountryCode unexplained and does not describe the return value or error behavior, which are important for an agent invoking the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It partially clarifies vatNumbers as 'one or more EU/XI VAT numbers', but it never explains the supplierCountryCode parameter or its default value.

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: batch validation of EU/XI VAT numbers against the official European Commission VIES REST API. It clearly distinguishes itself from sibling VIES tools such as vies_member_state_status and vies_licence_info by focusing on batch VAT-number 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?

The mention of B2B reverse-charge eligibility implies a business use case, but the description does not explicitly say when to use this tool versus alternatives or when not to use it. Usage is inferable from the purpose but not fully guided.

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