Aleva open data

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

Annotations already establish that this is a safe, idempotent, read-only, closed-world query. The description goes beyond that by disclosing pagination behavior ('pass next_cursor to get the next page') and the exact shape of returned records, which annotations cannot express.

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

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

Two tightly written sentences: the first front-loads what the tool returns, the second covers pagination and the field list. No filler, and the return-value detail is justified since no output schema exists.

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

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

With no output schema, the explicit field list (month, passengers, domestic, international, movements) and pagination note fill the main gaps an agent would hit. It does not explain units or how the month / month_gte / month_lte filters interact, but those remain readable from the schema.

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

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

Schema description coverage is 100%, so every parameter is already documented as a baseline 3. The description adds nothing about filter semantics and, if anything, risks confusion by naming 'next_cursor' when the actual parameter is 'cursor'.

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 (air passengers in Sweden) with an explicit granularity (per month), which is clear and unambiguous. It does not, however, distinguish itself from the nearby sibling airport_passengers, which an agent could plausibly confuse with a nearly identical-sounding dataset.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of the adjacent sibling airport_passengers that covers similar-sounding data. The only clue is the resource name itself, so the agent must infer everything about selection.

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

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

Annotations already declare readOnly, idempotent, and closed-world, so safety is covered. The description adds genuinely new context beyond them: results come back as a list, pagination works by passing next_cursor, and the caveat that months is partial for the current year.

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

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

Front-loaded with purpose, then pagination, then a compact field list. The trailing field enumeration is dense but each entry earns its place given no output schema. No filler sentences.

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

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

With no output schema, the description correctly takes on the burden of describing return fields and pagination, including the partial-year caveat for months. An agent has enough to call and interpret the tool, though return-type/format details for a single page are only lightly specified.

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

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

Schema coverage is 100%, so every parameter (year, limit, cursor, airport, year_gte, year_lte, airport_prefix) is already documented in the schema. The description does not add filter semantics beyond the schema; its field list describes return columns, not parameters, so the baseline 3 applies.

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

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

States a specific resource and scope ('Passengers per airport and year') and enumerates the returned fields, so an agent knows this queries passenger statistics. It does not explicitly distinguish itself from the sibling air_passengers_monthly, which is the main gap preventing a 5.

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

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

No when-to-use guidance, no alternatives named, and no explanation of how the year/airport filters interact. The only operational hint is pagination via next_cursor, which is a mechanics note rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description usefully adds that it returns a list of records and is cursor-paginated, which the annotations do not convey. However, it offers no rate limits, result-size behavior, or cursor expiry details, and the pagination note names 'next_cursor' while the actual parameter is 'cursor', which could misdirect an agent.

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

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

Purpose is front-loaded in the first clause, followed by pagination mechanics and field definitions in one dense paragraph. Every element is relevant, though the field list duplicates schema content and slightly dilutes focus.

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 compensates by listing the returned fields (month, measure_code, measure, value) and explaining pagination, which is what an agent needs to consume results. It is only missing guidance on choosing this dataset over others and any note on default/max row limits.

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

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

Schema description coverage is 100%, so all seven parameters are already documented, including the measure_code value mapping. The description largely restates the schema's measure_code meaning and lists returned fields rather than adding filtering semantics, so the baseline of 3 applies.

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

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

The description names a specific resource (consumer price index) and its granularity (per month), so an agent can tell it apart from other dataset tools like house_prices or air_passengers_monthly. It does not explicitly contrast itself with any sibling, but no sibling covers the same data, so the lack of differentiation is a minor gap.

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 versus alternatives, nor any prerequisite or exclusion. The only procedural guidance is 'pass next_cursor to get the next page,' which describes pagination mechanics rather than when this tool is the right 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds pagination behavior and, critically, the full return-field list, which is real behavioral context given there is no output schema. It does not mention rate limits or auth, but the bar is lower with annotations present.

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

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

Purpose and pagination are front-loaded in the first two clauses, followed by a compact semicolon-delimited field list. The field enumeration is long but each entry earns its place by documenting the (otherwise undocumented) response shape.

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 supplies the return fields and their meanings plus pagination semantics, which is what an agent needs to call and consume the tool. The one notable omission is guidance on choosing it over court_rulings_by_court.

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

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

Schema description coverage is 100%, so all seven input parameters are already documented in the schema and the baseline is 3. The field list explains returned columns rather than adding input-parameter meaning, so it does not raise this above baseline.

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

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

The description states a specific resource (published court rulings) and that it returns a list of records, so the agent knows it is a query/read tool. However, it never distinguishes itself from the close sibling court_rulings_by_court, so an agent cannot route between the two from the description alone.

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

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

The only usage guidance is pagination ('pass next_cursor to get the next page'), which is procedural rather than selective. There is no statement of when to use this tool versus court_rulings_by_court or any of the other stats tools, and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint and a closed (non-open-world) dataset, so the safety profile is covered. The description usefully adds pagination behavior via the cursor loop and enumerates the shape of rows, but says nothing about ordering, volume, or freshness beyond the 'latest' field.

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, front-loaded sentences with no filler: purpose, pagination, then the result fields. Terse and effective, though the field list reads slightly like a schema dump rather than prose.

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

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

With no output schema, the description correctly compensates by listing the returned columns and explaining the cursor pagination loop. The notable remaining gap is the absence of any differentiation from the near-identical sibling court_rulings.

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

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

Schema description coverage is 100%, so both limit and cursor are already documented. The description restates pagination ('pass next_cursor') without adding format or range detail beyond the schema, 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 name/title plus 'Rulings per court' plus the returned field list (court_code, court, rulings count, latest date) make clear this is an aggregate of ruling counts grouped by court. This distinguishes it in substance from the bare sibling court_rulings, but the description never explicitly contrasts them, so it falls short of a 5.

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

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

There is no guidance on when to reach for this aggregate versus the sibling court_rulings, nor any stated preconditions. The only procedural note ('pass next_cursor to get the next page') is pagination mechanics, not usage selection.

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

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

Annotations cover safety (readOnly, idempotent, openWorld=false), and the description adds pagination via next_cursor and field definitions. However, it does not state whether the list is complete, sorted, or subject to rate limits, leaving some 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?

Two compact sentences that front-load the resource and pagination instruction. The field list is helpful but slightly dense; no wasted words.

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

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

For a read-only list tool with no output schema, the description covers the resource, pagination, and return fields. It omits ordering, completeness guarantees, and sibling differentiation, making it adequate but not 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?

Schema description coverage is 100%, so the schema already documents all 5 parameters. The description mentions next_cursor but adds no syntax, format, or constraint details beyond what the schema provides.

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

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

States a specific verb+resource ('Debt restructuring applications per month') that is clear and distinct from siblings. It could better differentiate from debt_restructuring_by_age, but the core purpose is unambiguous.

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

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

No explicit when-to-use or when-not-to guidance. Usage is implied by the name and sibling context, but the description does not name alternatives like debt_restructuring_by_age or explain when to choose one over the other.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety profile is covered structurally. The description adds pagination behavior ('pass next_cursor to get the next page'), which is genuinely useful context beyond annotations. It does not disclose result ordering or handling of empty ranges, so it is adequate but not rich.

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

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

Two short sentences with the resource stated first and pagination/fields following; no filler. Only minor cost is that the field list is a somewhat dense clause rather than clearly framed as output.

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 compensates by enumerating the return fields (year, age_group, applications) and explaining pagination, which is what an agent needs to consume results. The gap is the lack of any statement distinguishing it from the sibling 'debt_restructuring'.

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

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

Schema description coverage is 100%, so every parameter (year, limit, cursor, year_gte, year_lte) is already documented in the schema, making 3 the baseline. The description lists returned fields (year, age_group, applications), which describes output rather than parameter meaning, so it adds nothing to parameter interpretation.

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 restates the title almost verbatim ('Debt restructuring per year and age') and adds the return fields, so an agent learns the data shape but not a distinct verb or scope. It does not differentiate from the sibling 'debt_restructuring', which presumably offers the same resource without the age dimension. Purpose is implied rather than specifically 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 guidance and no mention of alternatives, even though 'debt_restructuring' is the obvious sibling for a non-age-broken-down query. The only usage-adjacent sentence concerns pagination, not tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description usefully discloses what the response contains (licence, sources, freshness) even though no output schema exists, but says nothing about failure behavior for an unknown tool name or rate limits.

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

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

A single short sentence with no filler, and the key scope word 'one' is placed early. It is a noun fragment rather than a sentence, which slightly weakens front-loading of the action.

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-only metadata tool this is close to adequate, and the description compensates for the missing output schema by listing the returned categories. It still omits error/unknown-tool behavior and does not explicitly disclaim that it returns no data rows.

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

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

There is a single parameter with 100% schema description coverage that already explains the accepted source of the tool name. The description only reinforces the single-tool scope ('one data tool') without adding format or naming-convention detail beyond the schema.

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

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

The title 'Describe a tool's data' plus the description's enumeration (fields, parameters, licence, sources, freshness) makes clear this returns metadata about one data tool rather than the data itself, which cleanly separates it from the data-retrieval siblings. It falls short of an explicit verb-resource sentence and never states outright that it returns a description/documentation.

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, no prerequisites, and no mention of how it relates to the closest siblings (search_catalogue for discovery, tools/list). The only workflow hint lives in the parameter schema ('A tool name from tools/list or search_catalogue'), not in the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world scope, so the safety profile is covered. The description still adds real value: it states the single-record return, the error path when nothing matches, the zone serial/fetch semantics, and a required attribution obligation, which goes well beyond the annotations.

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 return behavior and error semantics are front-loaded before the field enumeration, and each field listed conveys distinct information. The long run-on field list is dense but every entry earns its place given the absence of an output 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?

With no output schema, the description fully carries the return-value burden via an explicit field list with types and meanings, plus error behavior and licensing/attribution requirements. An agent has everything needed to call and interpret results.

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

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

Schema description coverage is 100% and the single 'name' parameter is documented as 'Domain name, e.g. example.se'. The description adds no additional syntax or formatting detail for the input itself, so the baseline of 3 is appropriate.

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

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

The description makes clear this retrieves a single domain record from the latest DNS zone snapshot, with a stated single-record return and error-on-no-match behavior. It does not distinguish itself from siblings like search_catalogue or the domains_* tools, so it stops short of a 5.

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

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

There is no explicit when-to-use guidance, no exclusions, and no mention of alternative tools for finding domains (e.g., search_catalogue). The only routing hint is the error-when-no-match behavior, which is a correctness note rather than 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?

Annotations already declare readOnly, idempotent, closed-world, so the burden is lighter, and the description adds real context: cursor-based pagination ('pass next_cursor to get the next page'), the Europe/Stockholm timezone convention, and a required attribution/licensing notice. It stops short of stating rate limits or ordering guarantees.

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

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

Front-loads the one-line purpose, then covers return/pagination, then enumerates output fields, then ends with the attribution requirement. Given there is no output schema, the field list earns its space rather than being redundant.

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

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

With no output schema, the description carries return-shape disclosure and does it well by listing every field and its type. Pagination and licensing obligations are covered; only minor items like default page size or ordering are absent.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including enum-like tld values and the date format. The description restates the date timezone and the cursor paging convention but adds no semantics beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb-resource pair ('Dropped .se and .nu domains on a date') and names the exact TLD scope, which clearly distinguishes it from siblings like domains_expiring and domains_new. It does not explicitly reference those alternatives, but the 'dropped' framing is unambiguous.

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

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

Usage is implied by the date-scoped purpose, but there is no explicit when-to-use vs. when-not guidance and no mention of the sibling tools an agent might confuse this with (expiring/new/valuable). Adequate but leaves routing to inference.

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

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

Annotations already establish read-only, idempotent, closed-world behavior. The description adds useful context beyond that: pagination via next_cursor, detailed return fields, and the required CC BY 4.0 attribution.

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

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

Well front-loaded: purpose first, then pagination, output fields, and attribution. The length is justified because there is no output schema, though the inline type annotations could be trimmed.

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

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

For a read-only list tool with nine optional filters and no output schema, the description covers the return fields, pagination, and legal attribution requirement. Complete enough for an agent to call correctly.

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

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

Schema description coverage is 100%, so the schema already documents all nine input parameters. The description reinforces pagination but says 'pass next_cursor' while the input parameter is named cursor, a minor naming mismatch that adds slight confusion rather than clarity.

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

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

States the resource and condition clearly: domains about to be released, with return fields that describe the payload. It does not explicitly differentiate from siblings such as domains_dropped or domain_lookup, so it is clear but lacks sibling routing.

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 or alternatives are given. The description never references siblings or explains when to choose this tool over domains_dropped, domains_new, or domain_lookup.

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

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

Annotations already carry readOnly/idempotent/openWorld, so the bar is low; the description still adds real value by disclosing pagination via next_cursor, per-field semantics (nameservers empty when removed, serial, detected_at) and the mandatory CC BY 4.0 attribution requirement. Missing detail on default result size or ordering is minor.

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

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

Front-loads purpose, then pagination, then the column list, then licensing. The field enumeration is long but each entry carries type/semantic content, and the required attribution sentence is not 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?

With no output schema, the description correctly compensates by listing returned fields with types and noting empty-on-removal behavior. Pagination and licensing obligations are covered, leaving only minor gaps such as default page size visibility.

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

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

Schema description coverage is 100%, so the schema already documents tld, date, limit, cursor and tld_in. The description restates the date ('Europe/Stockholm') and reuses the same field vocabulary but adds no parameter syntax or precedence meaning beyond the schema (e.g. how tld and tld_in interact). Baseline 3.

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

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

States a specific verb-equivalent ('New .se and .nu domains') plus a scope (on a date), which clearly separates the 'new registrations' concept from sibling datasets like domains_dropped and domains_expiring. It never names those siblings explicitly, so differentiation is inferred rather than declared.

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/when-not guidance or naming of alternatives. Usage is implied by the required date and the 'new domains' framing, and pagination is addressed via next_cursor, but the agent gets no routing help between this and the other domain datasets.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts — cursor pagination and a mandatory attribution/licensing requirement — but says nothing about rate limits, error behavior, or result staleness.

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

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

Purpose and pagination are front-loaded in the first two sentences, and the field list is justified because there is no output schema. The attribution block is legally necessary but long and unsplit, making the sentence structure heavier than it needs to be.

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 every returned field with type and meaning, and covers pagination and licensing. What is missing is sibling disambiguation against domains_expiring/domains_dropped, which matters for a 10-parameter read tool in this dense catalogue.

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

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

Schema description coverage is 100%, so all 10 filter parameters are already documented. The description repeats the same field names and only adds interpretive value for score ('higher is shorter, cleaner and closer to real words'), which is a return field, not a parameter. Baseline 3 applies.

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

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

States a concrete resource and scope: domains about to be released, enriched with a value score. It never names the closely related siblings (domains_expiring, domains_dropped, domains_new), so the agent must infer the boundary itself, which keeps this from a 5.

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

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

Usage is implied rather than stated: the score and word/compound/trademark fields signal this is for finding registerable, high-quality domains, and release_at/days_left imply a registration window. There is no explicit when-to-use, no exclusions, and no routing to domains_expiring or domains_dropped.

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

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

Annotations already declare readOnly, idempotent, and closed-world behavior, so the safety profile is covered. The description adds genuinely useful behavior beyond that — that results are paginated and that the page token is passed back — though it calls the token 'next_cursor' while the actual parameter is named 'cursor', a naming mismatch that could trip up an agent.

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, front-loaded sentences with zero filler: what it is, how pagination works, what comes back. Every clause carries 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, the description does the right thing by enumerating returned fields and types, which is what an agent needs here. It stops short of explaining what 'series' actually contains (measures/categories) or result ordering, but the core contract is complete.

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

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

Schema description coverage is 100%, so all five parameters (including the year vs year_gte/year_lte distinction and limit bounds) are documented in the schema. The description's 'Fields:' list describes return columns, not inputs, so it adds nothing to parameter semantics. Baseline 3 applies.

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

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

The description states a specific resource and scope ('Electricity production and use per year'), making it immediately clear what data comes back. It does not, however, differentiate itself from the sibling electricity_forecast, so an agent still has to guess which of the two fits a given question.

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 exclusion conditions, and no mention of the closely related electricity_forecast sibling. The agent gets a data topic but no routing signal.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and idempotentHint=true, so the safety profile is covered. The description adds genuine value beyond them by disclosing the return shape (a list of records) and the cursor-based pagination contract, which no structured field provides since there is no output schema.

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

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

Two compact sentences that front-load the resource and then cover pagination and return fields without padding. The only minor waste is that the first sentence duplicates the title verbatim rather than adding 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 seven-parameter read-only list tool with no output schema, the description usefully fills the output gap by enumerating the returned fields and explaining cursor pagination, while annotations cover the safety profile. It falls short only on undefined terms ('forecast') and the missing relationship to the electricity_balance sibling.

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

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

Schema description coverage is 100%, so parameter meanings (year equals, year_gte/lte, series_in, limit, cursor) are already fully documented in the schema. The description's field list (year, series, twh) describes output columns rather than adding parameter semantics, so the baseline 3 is appropriate.

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

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

The description names a specific resource (electricity production per source) and notes it includes forecast values, so an agent knows what the tool surfaces. However, the opening sentence is a verbatim restatement of the title and it never distinguishes this from the very similar sibling electricity_balance, leaving selection ambiguous.

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

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

The description explains pagination mechanics ('pass next_cursor to get the next page') but gives no guidance on when to use this tool versus alternatives. With electricity_balance as a near-identical sibling and no exclusions or selection criteria stated, routing remains guesswork.

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

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds paging semantics and, importantly, a licensing/attribution requirement that no structured field conveys. It stops short of describing result ordering or cursor expiry.

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

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

Purpose, pagination contract, and attribution are front-loaded before the field list; the enumerated columns are denser than prose but are the only place the return shape is documented given there is no output schema, so every element earns its place.

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

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

With no output schema, the inline field list is necessary and supplied, and pagination is explained. Missing are result ordering and the default sort, which matter for paged iteration, but overall an agent has enough to call and page this tool correctly.

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

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

Input schema description coverage is 100%, so all 12 filters are already documented there, establishing the baseline of 3. The description's field enumeration mirrors the OUTPUT shape rather than adding meaning to any input parameter, so no uplift applies.

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

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

States a specific resource (Swedish food composition data) with the measurement basis (per 100 g) and confirms it is a list-returning query. It does not name or contrast any sibling, but the domain is unambiguous against the other tools in the set.

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?

Covers the pagination workflow ('pass next_cursor to get the next page') and imposes an attribution obligation, which is genuine usage guidance. However it never says when to prefer this over related lookups or how the name/name_prefix filters differ, so filtering behaviour must be inferred from the schema.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuine behavioral context on top: that results are a paginated list and which fields come back (month/origin/nights). It stops short of stating ordering or what happens when no filters are supplied.

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 clauses, front-loaded with the resource, then pagination behavior, then the return fields. No filler sentences; every clause carries information the 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?

No output schema exists, so the description's field list is doing necessary work, and all six parameters are documented in the schema. It is nearly complete, missing only guidance on selecting this dataset versus the by-country/by-county variants.

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

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

Schema description coverage is 100%, so the parameters are already documented; baseline 3 applies. The description restates origin values that the schema already gives, and notably refers to 'next_cursor' while the parameter itself is named 'cursor', which adds a small terminology mismatch rather than new meaning.

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

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

States a specific resource ('Guest nights per month') and its return shape, so the agent knows this is a monthly guest-night dataset. However, it does not distinguish itself from the close siblings guest_nights_by_county and guest_nights_by_country, leaving the agent to infer the aggregation difference 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?

The only usage information is the pagination instruction ('pass next_cursor to get the next page'). There is no statement of when to choose this tool over guest_nights_by_county/by_country, nor any note that all filters are optional.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it discloses the paginated return shape and how to advance pages, plus the exact output fields and their types.

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

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

The description is short and front-loaded, stating the dataset first and then the return/pagination and fields. It is telegraphic but every sentence carries useful information, with minimal waste.

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

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

With no output schema, the description compensates by listing the returned fields and their types, and it explains cursor-based pagination. Input filtering options are fully covered by the schema, so the description is adequately complete for this data-listing tool.

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

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

Schema description coverage is 100%, so the schema already documents every input parameter including the year equality filter, range filters, limit, and cursor. The description's field list describes output columns, not input semantics, so it adds little beyond what the schema provides.

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

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

The description states the specific resource (foreign guest nights) and scope (per country and year), which distinguishes it from the total guest_nights and the county-level guest_nights_by_county siblings. However, it is a noun phrase that echoes the title rather than a verb-led statement of what the tool does.

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 many sibling tools such as guest_nights or guest_nights_by_county. The only usage hint is pagination behavior ('pass next_cursor'), which is a mechanic, not a selection criterion.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description earns credit by adding pagination behavior (cursor-based paging) and a full return-field list, which is meaningful given the absence of an output schema.

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

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

Front-loaded purpose statement followed by pagination mechanics and a compact field list, with no filler. The dense semicolon-separated field enumeration is slightly list-like but every element is informative given no output schema.

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

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

For a paginated read-only aggregation endpoint with no output schema, the definition covers what is returned (five named fields with types) and how to page. Filtering semantics are fully delegated to the schema, which is complete, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including year filters and county_code_in. The description adds no parameter syntax or semantics beyond that; its field list describes return values rather than inputs. Baseline 3 is appropriate.

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

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

States a clear resource and grouping dimension: 'Guest nights per county and year.' An agent can distinguish it from guest_nights (unaggregated) and guest_nights_by_country, though the description never names those siblings explicitly, so differentiation relies on the agent inferring from the name.

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 pagination instruction ('pass next_cursor to get the next page') is a concrete invocation guideline. However, there is no guidance on when to choose this over guest_nights or guest_nights_by_country, and no prerequisites or constraints are stated, leaving sibling routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-open-world, so the safety profile is covered. The description adds genuine context beyond that: it discloses that results are paginated and defines the returned fields, including the domain-critical note that the index is normalized to 1981 = 100. Auth/rate-limit behavior is not covered, keeping 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?

Compact and front-loaded: the resource, the pagination mechanic, and the field list appear in one tight sequence with no filler. The only blemish is that 'pass next_cursor' borrows the schema's value wording while the actual parameter is named 'cursor', a minor naming friction.

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 available, the description usefully enumerates the returned fields and their types, including the index base year, which is the key semantic an agent needs. Input parameters are fully covered by the schema, and annotations carry the safety profile. Usage context is the only notable absence.

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

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

Schema description coverage is 100%, so all seven input parameters are already documented in the schema, establishing a baseline of 3. The description explains output fields rather than the query parameters, adding only the '1981 = 100' index semantics as extra meaning; no additional input-parameter guidance is supplied.

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

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

The opening sentence merely restates the title ('House price index'), but 'Returns a list of records' clarifies the behavior as a retrieval/query tool. The resource is identifiable, yet nothing distinguishes it from the many similar statistical dataset siblings (consumer_prices, population, municipal_figures). Purpose is legible but under-articulated.

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 pagination mechanics ('pass next_cursor to get the next page'), but no guidance on when this tool should be chosen over alternatives like consumer_prices, nor any mention of prerequisites or exclusions. The agent gets operational hints but no selection criteria.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it explains pagination ('pass next_cursor to get the next page') and enumerates the returned record fields, which is important since there is no output schema. It stops short of noting rate limits or result-size 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?

Two sentences, with the purpose front-loaded, then pagination, then a field enumeration. The dense field list is justified because no output schema exists, though it could be slightly tightened.

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 statistics tool with no output schema, the description covers the return shape and pagination adequately, and annotations cover the safety profile. The main gap is the absence of any differentiation from job_ads_national, which an agent would need to select correctly.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including the dimension values and the date variants. The description largely repeats the dimension list and otherwise describes return fields rather than adding parameter meaning, so the baseline 3 applies.

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

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

The description states a clear resource and granularity (open job ads, per day), so an agent knows it is a statistics query over daily job-ad data. However, it never distinguishes itself from the sibling job_ads_national, leaving the daily-vs-national split ambiguous.

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 use this tool versus alternatives such as job_ads_national, nor any stated exclusions or prerequisites. Usage is only implied by the presence of the dimension parameter, which is not the same as routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the paginated return contract and the exact shape of each record, which matters since no output schema exists.

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

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

Three short sentences, front-loaded with purpose, then pagination, then the return fields. The field listing is dense but earns its place because there is no output schema to convey 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, the description compensates by enumerating the returned fields and explaining pagination, and the annotations carry the safety profile. The remaining gap is routing between this tool and the sibling job_ads, plus the cursor/next_cursor naming mismatch.

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

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

Schema description coverage is 100%, so all five parameters are already documented, and the description adds no syntax or format detail beyond that (baseline 3). It mildly muddies things by calling the paging token 'next_cursor' while the actual parameter is named 'cursor'.

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 opening sentence gives a specific resource and scope: daily counts of open job ads in Sweden. It is clear what the tool returns, though it never distinguishes itself from the sibling job_ads tool, leaving the granularity difference to inference.

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

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

The second sentence gives operational guidance on paging ('pass next_cursor to get the next page'), which tells the agent how to consume results. However, there is no statement of when to choose this tool over job_ads or when-not to use it, so usage selection is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description adds genuinely non-annotated behavior: cursor-based pagination semantics and a legal attribution requirement (Läkemedelsverket, CC BY 4.0), which an agent must honor when presenting results. Return-field volatility or refresh cadence is not covered, keeping it short of a 5.

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

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

Front-loaded with the resource, then pagination, then fields, then the license notice — a sensible order with no filler sentences. The dense semicolon-separated field list is information-carrying, though it reads as a dump and could be trimmed since much of it is inferable from column names.

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 appropriately enumerates the returned columns and their types, plus the ATC-group coding, which is the one non-obvious field. Combined with an exhaustive input schema, an agent can call and interpret this correctly. The gap is the absent sibling differentiation.

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

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

Schema description coverage is 100% and all 8 filters already carry their own descriptions (equals vs starts-with, date bounds), so the schema does the heavy lifting and the baseline of 3 applies. The description only restates the cursor parameter, adding no filter semantics beyond what the schema gives.

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 (medicine shortages) and describes the record shape, so the agent knows what data flows back. But it never states a verb/scope that separates it from its near-identical siblings medicine_shortages_by_group and medicine_shortages_monthly, leaving the agent to guess which of the three to call. Purpose is identifiable but not differentiated.

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

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

There is no when-to-use guidance and no mention of alternatives, despite two obvious sibling candidates in the same domain. The only usage cue is the pagination instruction ('pass next_cursor to get the next page'), which is mechanics rather than selection guidance.

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

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

Annotations already declare readOnly, idempotent, closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the result is a paginated list and next_cursor must be passed back to page, plus a legal attribution obligation when showing 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?

Front-loads purpose, then pagination, fields, and attribution in tight sentences; no filler. Slight redundancy between the description's pagination note and the schema's cursor description, but 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?

With no output schema, the description usefully enumerates the returned fields (atc_group, packages, products) and explains pagination and attribution. Minor ambiguity remains because it says 'pass next_cursor' while the parameter is named 'cursor', but overall the agent has enough to invoke and interpret it.

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

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

Schema coverage is 100%, so limit and cursor are already documented in the schema. The description largely repeats the cursor semantics ('next_cursor from the previous result') rather than adding format or defaulting detail, so the baseline 3 applies.

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

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

States the specific resource and aggregation scope: ongoing shortages grouped by ATC group. This differentiates it from the plain medicine_shortages sibling by implying aggregation, though it never explicitly names when to prefer it over medicine_shortages or medicine_shortages_monthly.

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 guidance and no alternatives named. With three closely named sibling tools (medicine_shortages, medicine_shortages_monthly), the agent must infer the distinction purely from the title and the word 'per group'.

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

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

Annotations already cover the read-only, idempotent, closed-world profile, yet the description adds real context: cursor-based pagination via next_cursor and a mandatory CC BY 4.0 attribution requirement from Läkemedelsverket. That licensing/attribution obligation is behaviorally important and appears nowhere in the structured fields.

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

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

Three tight clauses: purpose, pagination mechanics, then the returned field list with types. Everything is front-loaded and no sentence is redundant.

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

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

With no output schema, the description correctly enumerates the returned fields (month, shortages, packages) and covers pagination and attribution. It is nearly complete, missing only a note on how to combine or prioritize the month equality and range filters.

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

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

Schema description coverage is 100%, so the schema already documents limit, month, cursor, month_gte and month_lte. The description only reinforces the cursor parameter via 'pass next_cursor to get the next page' and adds nothing about the month vs month_gte/month_lte distinction, so baseline 3 applies.

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

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

States a specific metric and resource: new medicine shortages aggregated per month. It is clearly distinct from the sibling 'medicine_shortages_by_group', but the description never explicitly says how it differs from plain 'medicine_shortages', leaving sibling differentiation to 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?

There is no guidance on when to choose this monthly aggregate over medicine_shortages or medicine_shortages_by_group. Pagination is explained, but that is mechanics, not usage selection. An agent must infer the use case from the 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?

The annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering the safety profile. The description adds valuable behavioral details beyond annotations: it explains the pagination mechanism (next_cursor), the return shape (list of records), the output fields, and a required attribution statement. It does not cover error behavior or rate limits, but given the annotation coverage, this is a strong addition.

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

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

The description is front-loaded with the core purpose and pagination instruction, then lists output fields and attribution. Every sentence adds value: the field list is justified because no output schema exists. It is slightly long but not bloated or repetitive.

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 9 parameters, full schema coverage, no output schema, and existing annotations, the description compensates well by documenting the output fields, pagination, and attribution requirement. It is nearly complete, though it could mention default sorting or how the required kpi interacts with optional year filters.

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

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

The input schema has 100% description coverage for all 9 parameters, so the schema already fully documents parameter semantics. The description only adds a mapping for the cursor parameter ('next_cursor') and lists output fields, not input parameters. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description states a specific resource and scope: 'Key figures per municipality and year (Kolada). Returns a list of records.' This makes the tool's purpose clear as a retrieval tool for historical municipal figures. However, it does not distinguish itself from the sibling tool municipal_figures_latest, which likely provides similar data for the latest year, so sibling differentiation is missing.

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

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

The description provides context about the data granularity (municipality and year) and gives operational guidance for pagination ('pass next_cursor to get the next page'). However, it does not explicitly state when to use this tool versus alternatives like municipal_figures_latest, nor does it state any prerequisites or exclusions. Usage is implied but not 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?

Annotations already declare readOnly/idempotent/closed-world, and the description usefully adds return shape ('list of records'), pagination semantics ('pass next_cursor to get the next page'), and a licensing attribution obligation. Those are behavioral facts the structured fields do not carry.

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

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

Purpose is front-loaded followed by pagination and field details, and nothing is padded. The field-type enumeration is slightly verbose but it substitutes for a missing output schema, so it earns its space.

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

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

For a read-only, no-output-schema tool, the description compensates by naming the return fields and pagination mechanism, and flags the attribution requirement. The only real gap is the absence of when-to-use guidance relative to municipal_figures.

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

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

Schema coverage is 100%, so all seven parameters are already self-documented; the description lists returned fields rather than input parameters, adding no syntax or filtering guidance beyond the schema. Baseline 3 is appropriate.

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

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

States a specific resource and scope ('Key figures per municipality, latest year'), so an agent knows it retrieves municipality KPI data for the most recent year. It does not, however, name or contrast with the sibling municipal_figures, which is presumably the same resource without the latest-year constraint.

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. The 'latest year' qualifier implies it is for current-year snapshots versus the historical municipal_figures sibling, but that distinction is left entirely to inference and no alternative is named.

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

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

Annotations already carry readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it returns a paged list, the next_cursor mechanism, per-field types and semantics (votes = votes where both parties voted yes or no), and an attribution obligation. It omits rate limits and error behavior, but for a read-only aggregate tool this is a solid 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?

Front-loaded with the one-line purpose, then pagination, then a compact field list, then the attribution line. Every sentence earns its place, and the dense field enumeration substitutes for a missing output schema rather than padding.

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

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

With no output schema, the description usefully enumerates the returned fields and their meanings, plus pagination and attribution — enough for an agent to interpret results. The main gap is selection guidance relative to party_attendance, but the data-shape completeness is strong.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the cursor/pagination parameter (oddly calling it next_cursor rather than the schema's 'cursor'), but adds no meaning for limit, party, or party_in beyond what the schema already documents.

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

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

States a specific verb+resource: how often parties vote alike, which is a distinct analytical measure from the sibling party_attendance (which would be about presence/participation). It doesn't explicitly contrast with that sibling, but the title and name pin the purpose down unambiguously.

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

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

It explains pagination mechanics ('pass next_cursor to get the next page') but gives no guidance on when to use this tool versus party_attendance or any other sibling, and no preconditions or exclusions. The closest thing to usage guidance is the pagination note, which is procedural rather than selection guidance.

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

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

Annotations already declare readOnly/idempotent/openWorld=false, so safety is covered. The description adds non-obvious context the annotations do not: cursor-based pagination ('pass next_cursor to get the next page'), the returned field semantics including the '-' sentinel for members without a party, and a mandatory attribution requirement ('Source: Sveriges riksdag').

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

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

Front-loaded with the purpose, followed by pagination guidance, field semantics, and attribution in a compact block. No filler sentences, though the field-list run-on and the 'varchar: -' formatting are slightly hard to parse.

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

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

With no output schema, the description carries the return-shape burden and does so by listing all five fields, plus covering pagination and attribution. Only the filter parameters lack descriptive treatment, which is minor for a no-required-params query tool.

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

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

Schema description coverage is 100%, so limit/cursor/riksmote/riksmote_in are already documented and the baseline is 3. The description reinforces pagination behavior ('pass next_cursor') but never explains the riksmote or riksmote_in filters, so it adds little beyond the schema.

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

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

The description states precisely what the tool returns: votes and absence aggregates per party, with the exact field list. It does not distinguish itself from the closely-named sibling party_agreement, but the resource and scope are 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 statement of when to use this tool versus alternatives (notably party_agreement), nor exclusions, prerequisites, or filter guidance. Usage context is only implied by the field list and the riksmote filter parameters.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description goes beyond them by disclosing the pagination contract ('pass next_cursor to get the next page') and enumerating the returned fields, which is real behavioral context for a cursor-paged endpoint.

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

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

Two sentences, front-loaded with the resource and then the pagination and field contract. The field list is dense but earns its place given there is no output schema; nothing is padded.

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

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

Listing the return fields compensates for the missing output schema, and pagination is explained. However, for an eight-parameter tool with zero required parameters, it never says what happens with no filters, nor how the inclusive year bounds interact with the exact year filter.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's field legend largely restates the schema's region_code wording and says nothing about the relationship between year, year_gte and year_lte or the limit default/ceiling.

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 and scope: population records keyed by region and year. An agent knows it is a filtered statistics query. It does not distinguish itself from the sibling population_latest, which is the obvious competing choice for the same 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?

No when-to-use guidance at all. With population_latest, municipal_figures and municipal_figures_latest in the sibling list, the agent gets no signal about when this historical/filterable endpoint is preferable, nor any note that all eight filters are optional.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds real value on top: it states the result is a list of records and explains the cursor-based pagination flow. It stops short of noting ordering or rate limits, but the bar is lower given annotations.

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

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

Front-loads the purpose, then pagination, then the field list. No filler sentences, though the run-on field enumeration reads as a compressed output schema rather than prose.

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

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

With no output schema, the description usefully compensates by enumerating return fields and their types, and annotations carry the safety profile. The main gap is the absence of any guidance on choosing this over the sibling `population` tool.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description adds no syntax or filter semantics beyond the schema, so baseline 3 applies. Minor terminology drift: description says 'next_cursor' while the parameter is named 'cursor'.

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 (population) and a clear scope (latest year and change since first_year). It's easy to understand what it returns, but it never distinguishes itself from the sibling `population` tool, which likely serves the same resource in a different form.

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 or routing against the `population` sibling or `municipal_figures_latest`. The only usage note is operational ('pass next_cursor to get the next page'), which is pagination mechanics rather than tool selection.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, closed world), so the description's job is additional behavior — and it delivers: pagination mechanics, the shape and types of returned fields, and a licensing/attribution obligation. The only gap is that it never states range defaults or how large a full series can be.

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

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

Front-loaded with purpose, then pagination, then the return fields — a sensible order. The field enumeration is compact, though the trailing attribution sentence is long and the 'next_cursor/cursor' naming could be tightened.

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 compensates by listing every returned field and its type, plus pagination and attribution requirements — enough for an agent to consume results correctly. It stops short of clarifying date-range semantics (date vs date_gte/date_lte) or default limits, but the schema covers those.

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

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

Schema description coverage is 100%, so all seven parameters are documented in the schema and the baseline is 3. The description restates the same series codes rather than adding syntax or filter-combination guidance, and it names 'next_cursor' while the actual parameter is 'cursor', a small mismatch inherited from the schema wording.

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

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

States a specific verb+resource ('Policy rate and exchange rates per day') and names the concrete datasets via the series codes, so an agent knows exactly what it retrieves. It does not explicitly differentiate from siblings like swestr or consumer_prices, but the resource is specific enough that confusion is unlikely.

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 (query policy/exchange rate series by date) and the description gives one concrete procedural hint ('pass next_cursor to get the next page'). There is no statement of when to prefer this tool over alternatives or any exclusions, leaving context to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety and repeatability are covered. The description adds genuinely useful behavior (multilingual matching in Swedish or English, and that matching spans names, descriptions and fields), but says nothing about result ranking, result limits, or how the returned tool references link back to the sibling endpoints.

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, no filler, with the core action and matching surface front-loaded. Nothing could be removed without losing information.

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

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

With only one fully documented parameter and no output schema, the description carries little burden, and it does tell the agent what class of results to expect (datasets plus querying tools). It falls short of explaining result shape or that returned tool names are callable siblings, which matters in a 38-tool catalogue.

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

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

Schema description coverage is 100%, giving a baseline of 3, but the description adds meaning beyond the schema by specifying that the query string is matched against dataset names, descriptions and fields, and that both Swedish and English terms work. That is real semantic value the 'What to look for' schema note does not convey.

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 ('Find') plus two concrete resources ('datasets and the tools that query them'), and reveals the matching surface (names, descriptions, fields). This functionally separates it from all 38 sibling tools, which fetch concrete data rather than discover 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?

Usage is only implied: an agent can infer this is the discovery entry point before calling a concrete dataset tool, but the description never says so, nor does it mention alternatives such as describe_endpoint or what to do with the returned tool names.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, closed-world), yet the description adds real context beyond them: cursor-based paging, the Europe/Stockholm timezone for 'date', and a mandatory attribution requirement under CC BY 4.0. It does not describe pagination limits or error behavior, keeping it out of 5 territory.

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

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

Front-loaded with purpose, then pagination, then field semantics, then licensing — a sensible ordering with little filler. The field enumeration is dense but justified given there is no output 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?

With no output schema, the description responsibly documents returned fields and their units/meaning (DS record counts, algorithm 13/8 breakdowns) plus pagination and attribution. Only error handling and limits are unaddressed.

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

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

Schema description coverage is 100% and the schema already documents the equals/any-of/gte/lte filter operators, so the baseline is 3. The description only adds a hint about cursor reuse, which is largely duplicative of the schema's own cursor text.

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

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

The description names a specific verb/resource pair ('DNSSEC adoption') and its grouping dimensions ('per zone and day'), which is more informative than the title alone. It does not differentiate itself from siblings such as stats_nameservers or domains_new, so it stops short of a 5.

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

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

It supplies operational usage for pagination ('pass next_cursor to get the next page') and a licensing/attribution obligation, but never says when to reach for this tool versus the other DNS-related siblings. Usage is implied from the resource name 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?

Annotations already declare readOnlyHint/idempotentHint, so safety is covered. The description adds genuinely useful behavioral context beyond that: cursor-based pagination via next_cursor, the exact record shape, and a licensing/attribution requirement for displayed 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?

Front-loaded purpose, then pagination, then fields, then license. The field enumeration is long but each entry carries a type and definition that would otherwise be unavailable (no output schema), so the density is justified.

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 compensates by defining every returned field and the pagination contract, plus the licensing obligation. It is complete for a read-only stats endpoint, though it never explains the filtering semantics (equals/starts-with, zone applicability) that the schema implies.

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

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

Schema description coverage is 100%, so all seven parameters (tld, tld_in, operator, operator_prefix, domains_gte, limit, cursor) are documented in the schema. The description's 'next_cursor' note reinforces the cursor parameter but the field list it enumerates describes outputs, not inputs, so it adds little parameter meaning beyond the schema baseline.

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

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

States a specific resource ('name server operators and market share') with an implicit verb of returning aggregate statistics, which is enough to distinguish it from stats_dnssec and domain_lookup. It is clear but does not explicitly contrast itself with those 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?

No when-to-use guidance, no exclusions, and no named alternatives despite many adjacent siblings (stats_dnssec, domain_lookup, domains_*). The only procedural instruction is how to paginate, not when this tool is the right 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?

Annotations already establish the read-only, idempotent, closed-world profile, so the bar is lower. The description still adds real value by disclosing pagination behavior ('pass next_cursor to get the next page') and a licensing/attribution obligation (Source: Sveriges riksbank, CC BY 4.0), which is behaviorally significant for downstream display.

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

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

The description is front-loaded with the resource and followed immediately by pagination and the field inventory. It is dense but nearly every element earns its place; the only slight redundancy is repeating the type annotations that mirror the return shape.

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 field enumeration (date, rate, percentiles, volume, transactions) is the only documentation of the return shape and it is provided with units and semantics. It omits domain context about what SWESTR measures, but structurally it is complete enough to call and parse the tool.

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

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

Schema description coverage is 100%, so all five parameters are already documented, and the baseline is 3. The description only reinforces the cursor parameter's role ('next_cursor from the previous page') without adding format or constraint detail beyond the schema.

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

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

The description names the resource (Swestr per day) and enumerates the returned fields, which hints at a daily interest-rate series, but it never explains what SWESTR actually is (Sweden's overnight rate) and does not distinguish itself from the sibling riksbank_rates tool. An agent unfamiliar with the acronym must guess the domain from the field names 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 statement of when to use this tool versus alternatives such as riksbank_rates, nor any guidance on filtering (date vs date_gte/date_lte). The only operational hint is the pagination instruction, which is a mechanic rather than 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description adds real value on top: cursor-based pagination behavior and precise domain semantics for each returned field ('At most 5 minutes late', 'early counted as 0'), which the agent cannot infer from structure alone.

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?

Dense and front-loaded: pagination instruction immediately follows the purpose, then field definitions. The opening sentence duplicates the title verbatim, which is mildly redundant, but the remaining text 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, the description correctly carries the return-record documentation and does so thoroughly. It does not state data provenance or coverage (seasonal span, geography implied by the Cst example), but for an 8-param list endpoint the essential calling information is present.

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

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

Schema description coverage is 100%, so every parameter including cursor, limit, and the filter variants is already documented in the schema. The description repeats the cursor behavior but adds no semantics beyond the schema, making the baseline 3 correct.

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 statement of the resource and granularity ('Train punctuality per station and day') with the return shape made explicit ('Returns a list of records'). However, it never distinguishes itself from the sibling train_punctuality_daily, which an agent must choose between, so it earns a 4 rather than a 5.

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

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

The description gives pagination mechanics ('pass next_cursor to get the next page') but no tool-selection guidance at all. It never says when to prefer this over train_punctuality_daily, nor when filtered vs unfiltered queries are appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, so safety is covered. The description adds genuine behavioral value beyond that: it discloses the paginated list return shape and the exact fields and their types, which the annotations do not carry.

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

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

Three compact sentences, front-loaded with the resource and grain, followed by pagination and fields. The field enumeration is dense but earns its place given there is no output schema; nothing reads as filler.

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

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

With no output schema, the description usefully enumerates the return fields and types and explains cursor pagination. Gaps remain around what population the data covers (national vs per-operator/station) and how it differs from the non-daily 'train_punctuality' sibling.

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

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

Schema description coverage is 100%, so every parameter including date/date_gte/date_lte/limit/cursor is already documented in the schema. The description's mention of next_cursor maps to that existing field and adds no new syntax, format, or constraint detail, so baseline 3 applies.

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

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

The description names a specific resource and grain ('Train punctuality in Sweden per day'), which is enough for an agent to know what data comes back. It does not, however, distinguish itself explicitly from the sibling tool 'train_punctuality', leaving the day-vs-other-granularity relationship to inference.

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

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

There is no statement of when to use this tool versus the similarly named 'train_punctuality' sibling, nor any note about required filters or typical query patterns. The pagination hint ('pass next_cursor to get the next page') is procedural, not guidance on tool selection.

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

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

Annotations already declare readOnly/idempotent/closed-world, so safety is covered. The description adds genuine behavioral context beyond that: pagination via next_cursor, the meaning of quality codes ('G checked, Y suspect'), the caveat that latest-hour data is not quality-controlled, and a licensing/attribution obligation ('Attribution required when the data is shown'). That is meaningful added value, though no rate limits or error behavior are mentioned.

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

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

Purpose and pagination are front-loaded before the field glossary, and each clause carries useful information (field types, code mappings, attribution). It is dense and somewhat long, but no sentence is pure filler; the field list earns its place by explaining undocumented enums.

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 compensates by enumerating the returned fields and their semantics, plus pagination and the quality/attribution caveats. Combined with a 100%-covered input schema, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description exceeds it by decoding the parameter values (1 temperature, 4 wind speed, 6 humidity, 7 precipitation) and the quality flags, which the schema does not document ('Parameter (equals)' is opaque). The date-range and filtering params still rely on the schema alone.

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

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

The title/description pair states a specific resource and granularity ('Weather per hour and station') and the body clarifies it returns a list of hourly weather records with named fields. The agent can identify it as a historical/observational weather query. It does not explicitly distinguish itself from the sibling weather_now, so differentiation is only implied by the name.

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 versus weather_now or any other sibling, nor any prerequisites or exclusions. It mentions passing next_cursor for the next page, which is operational guidance, but not selection guidance. Usage must be inferred entirely.

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?

Beyond the annotations (readOnly, idempotent, non-open-world), the description discloses pagination via next_cursor, the SMHI quality flag semantics including the caveat that latest-hour data is not quality-controlled, and a licensing/attribution requirement. These are genuinely useful operational details the annotations do not carry, though nothing is said about rate limits or result size 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?

Front-loaded with purpose and pagination mechanics, then a dense but structured field list. It is long, but with no output schema in play the field documentation is doing necessary work rather than padding.

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

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

With no output schema, the description properly compensates by enumerating return fields, units, quality codes, and cursor semantics, plus licensing. It is nearly complete for a read-only list tool; the only real omission is routing guidance relative to weather_history.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, and the description's parameter code list (1 temperature, 4 wind speed, 6 humidity, 7 precipitation) largely restates it. The one added detail is the quality-code meaning, which is output rather than input semantics, so the baseline 3 applies.

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

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

The description names the specific resource and its scope ('Current weather per SMHI station') and implies a now-vs-history distinction via the word 'Current'. It does not, however, name its obvious sibling weather_history or otherwise differentiate itself explicitly, leaving that inference to the agent.

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: 'Current' suggests this is the latest-observation tool versus weather_history, but no when-to-use guidance, prerequisites, or alternative tool is stated. An agent must infer the boundary from the sibling name alone.

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