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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds a valuable behavioral guarantee beyond the annotations: it 'always returns an evaluable status rather than an empty result,' which shapes agent interpretation of results. No contradiction with 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?

Two sentences with no wasted words. The main purpose is front-loaded, and the second sentence adds a key behavioral distinction that helps the agent reason about results. Every sentence earns its place.

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

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

For a zero-parameter status tool with rich annotations and an output schema, the description is complete. It states what is checked, guarantees a non-empty evaluable result, and explains why that matters. Nothing necessary for correct invocation is missing.

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

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

There are zero parameters, and schema coverage is 100%, so there is nothing missing. The baseline of 4 applies because no parameter semantics are needed; the description appropriately says nothing about parameters.

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

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

The description states a clear verb and resource: 'Check whether the I14Y API is reachable and which endpoints respond.' This distinguishes it as a status/health tool from the data-retrieval siblings, though it does not explicitly name a sibling or exclusion. It is clear but lacks explicit sibling differentiation.

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

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

The description provides clear use context: it is meant to check API reachability and to distinguish 'no data matched' from 'the source is down.' It implies when to use it (after empty results or when API health is in question), but it does not explicitly state when not to use it or name alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'including its value type and version', giving some content context, but no additional behavioral details such as error conditions, localization defaults, or response structure beyond what the output schema would provide. This is acceptable but not rich.

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

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

The description is compact and front-loaded with the core action, followed by concise parameter explanations. Every sentence contributes useful information, with no redundancy or filler. The Args block is clean and easy 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?

For a simple read-only lookup with two parametershol, strong annotations, and an output schema, the description is complete. It tells the agent what the tool returns, how to source concept_id, and what language affects. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry the parameter meaning burden. It does this well: concept_id is described as a UUID from list_concepts, and language is described as affecting titles and descriptions. These add practical meaning beyond the bare schema names, though the description could have noted the default language.

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

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

The description opens with a specific verb and resource: 'Retrieve one concept definition', which clearly distinguishes it from sibling tools like list_concepts and get_dataset. The title 'Get one concept' reinforces the singular focus. An agent can immediately tell this tool fetches a single concept by ID rather than listing or searching.

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

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

The description gives clear context that concept_id is a 'UUID from list_concepts', which tells the agent where to obtain the ID before calling this tool. It also explains that language is used for titles and descriptions. It does not explicitly discuss when not to use this tool versus search_catalog or list_concepts, so it misses a full explicit exclusion statement.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that the returned record is 'full' and 'including endpoints,' plus the language-dependent behavior of titles and descriptions.

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

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

The description is compact and front-loaded with the main purpose in the first sentence. The Args section is minimal and every line contributes either parameter meaning or workflow context. There is no filler or repetition.

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

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

For a simple single-record retrieval tool, the description provides the necessary workflow source for the ID, the language behavior, and the scope of the returned record. An output schema exists, so detailed return structure is not needed in the description. The annotations cover safety and idempotency.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does so well: data_service_id is identified as a UUID from `list_data_services`, and language is defined as affecting titles and descriptions. The schema only supplies types/enums, so this adds meaningful semantics.

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

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

The description states a specific verb ('Retrieve'), a resource ('the full record for one registered API'), and a distinctive detail ('including endpoints'). It clearly differentiates from list_data_services and other sibling get_* tools by targeting a single record rather than a collection.

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

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

The description explicitly tells the agent to source data_service_id from `list_data_services`, which establishes a clear workflow and prerequisite. It does not explicitly enumerate when not to use the tool, but the singular-record framing and sibling list make the selection context clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds value beyond annotations by disclosing the aggregation behavior — that one call returns contact point, coverage, documentation links, and every distribution with its licence — a trait an agent cannot infer from the schema or annotations 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?

The first sentence front-loads the purpose, the second sentence earns its place by explaining why aggregation matters, and the Args block is cleanly formatted. The phrasing 'answers «who publishes it, through which interface, under which licence»' is slightly florid but not filler, so the size 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 an output schema documenting return structure, annotations covering safety and idempotency, and both parameters explained including value provenance, nothing an agent needs to call this tool correctly is missing. The workflow context (used after search_catalog or list_datasets) completes the picture.

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

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

Schema description coverage is 0%, so the description carries the full burden for both parameters. It delivers: dataset_id gains provenance (a UUID from search_catalog or list_datasets) which the schema's pattern constraint lacks, and language gains a semantic effect (titles and descriptions). Both parameters are meaningfully enriched.

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?

Opens with a specific verb+resource ('Retrieve the full, aggregated metadata record for one dataset') and immediately positions itself as the aggregated detail tool. The distinction from sibling get_dataset_distributions is clear: this tool returns everything in one call, so an agent can tell them apart without opening either schema.

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

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

Describes the intended workflow (search_catalog → get_dataset) and states where dataset_id comes from (search_catalog or list_datasets). It explicitly contrasts with 'a separate distributions or contact lookup,' steering agents away from redundant sibling calls. It never names get_dataset_distributions explicitly or states hard when-not-to-use conditions, so it stops just short of a 5.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful extras beyond those: distributions each have their own format, licence, and download URL, licences can differ within a dataset, and the agent should read the licence field before reuse. It also reveals consistency with get_dataset. It does not go further into rate limits or error behavior, but the annotations lower that burden.

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 main action, then uses a short positioning sentence, a licence caveat, a sibling note, and a compact Args list. Every sentence contributes either selection guidance, parameter semantics, or a behavioral warning; there is no low-value filler.

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

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

For a two-parameter read-only retrieval tool with an output schema, the description supplies the missing context: what a distribution contains, the licence warning, the source of dataset_id, the meaning of language, and the relationship to get_dataset. An agent has enough to decide when to call it and how to invoke it correctly.

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

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

With 0% schema description coverage, the Args section carries the semantic load and succeeds: dataset_id is explained as coming from search_catalog or list_datasets, and language is defined as controlling titles and descriptions. This meaningfully compensates for the schema's absent descriptions and complements the enum/pattern constraints already present.

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

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

The description opens with a specific verb and resource: 'Get the downloadable files and access URLs for a dataset.' It also differentiates itself from the close sibling get_dataset by noting that get_dataset returns the same distributions 'alongside the rest of the record,' so an agent can distinguish the two without inspecting schemas.

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 frames the tool as 'the «where do I actually get the data» tool' and names get_dataset as the alternative that returns these distributions with the full record, giving clear selection context. It does not, however, state an explicit when-to-use/when-not-to-use rule such as 'use this when you only need distributions; use get_dataset when you need the full record.'

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-destructive behavior, so the description doesn't need to restate those. It adds some domain context about catalogues, but no additional behavioral details such as pagination behavior, sorting, or open-world caveats beyond the annotation.

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, front-loaded with the main action, and clearly separates purpose, context, and arguments. Every sentence earns its place and there is no redundant fluff.

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

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

Given the presence of an output schema and strong annotations, the description covers the essential domain concept and all optional parameters. It is slightly incomplete because it offers no guidance on choosing among sibling list/search tools, but it is otherwise sufficient for a simple read-only listing endpoint.

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

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

With 0% schema description coverage, the description compensates by documenting all three parameters: language controls titles, page is 1-based, and page_size is records per page. This adds meaning beyond the bare schema titles and constraints, though the explanations are minimal.

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 ('List') and resource ('catalogues that feed into I14Y'), then adds a defining sentence about what a catalogue represents. This makes it clearly distinguishable from siblings like list_datasets and search_catalog.

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 guidance about when to use this tool versus alternatives such as search_catalog or list_datasets. It states what the tool does, but an agent is left to infer the appropriate selection context.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context: the resources are harmonised concepts and code lists with a specific semantic role, and they are not reachable via search_catalog. This goes beyond the annotations and schema without contradicting them.

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

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

The description is well-structured: purpose first, then domain context, then a key caveat, then compact parameter documentation. Every sentence adds value, and the Args section is scannable without redundant 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 an output schema presentcherta, no required parameters, comprehensive annotations, and all parameters described, nothing essential is missing. The domain context and search_catalog exclusion complete the picture for an agent deciding whether to invoke 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 description coverage is 0%, so the description must compensate, and it does: every parameter is described. publisher_identifier is enriched with its source (list_publishers), language is clarified as affecting titles and descriptions, and page/page_size semantics are stated. This is sufficient, though terse.

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

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

The description opens with a specific verb and resource: 'List harmonised concepts and code lists of the Swiss administration.' It clearly distinguishes this tool from siblings by naming search_catalog as not the way to reach these resources, and the plural 'list' contrasts with singular get_concept.

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

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

The description explicitly says these concepts are not reachable through search_catalog, giving a when-not to use an alternative. It also instructs that publisher_identifier comes from list_publishers, chaining to the prerequisite tool. It does not explicitly contrast with get_concept or search_codelist_entries, but enough context is provided.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the description only needs to add context beyond that. It does: results include OpenAPI links only where the publisher supplied them, the data is the national official register, and language affects titles and descriptions. No contradiction with 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 description is front-loaded with the core definition, followed by the strategic value and a concrete usage sentence. The Args block is terse, parallel, and informative. Every sentence earns its place with no filler.

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

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

Given the output schema, annotations, and sibling context, the description is nearly complete: it explains the purpose, the data caveat, the parameter source, and the intended use. The only small gap is not explicitly describing pagination behavior, but the schema already defines page and page_size bounds clearly.

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

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

Schema description coverage is 0%, so the Args block carries the burden. It meaningfully covers all four parameters: publisher_identifier is tied to list_publishers, language is for titles/descriptions, page is 1-based, and page_size is records per page. This compensates for the empty schema descriptions, though it does not deeply explain filtering behavior.

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

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

States a specific verb ('List') and resource ('machine interfaces (APIs) registered by Swiss public bodies'), then adds what the tool returns: endpoint URLs and OpenAPI specification links. The 'discover whether an interface already exists' use case further clarifies its role and distinguishes it from sibling list/get tools at a glance.

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

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

Gives an explicit use case ('Use this to discover whether an interface already exists before building a scraper') and useful context such as listing official Swiss APIs. It also cross-references list_publishers for the publisher_identifier. However, it does not explicitly contrast with get_data_service or other sibling tools, so there is minor room for ambiguity.

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 `readOnlyHint`/`idempotentHint` annotations, it discloses pagination behavior, dataset volume, and completeness relative to the search index. These are meaningful runtime traits not visible in structured metadata and add real value for 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?

Front-loaded purpose, a single targeted comparison sentence, then a terse, complete Args list. No filler or redundant restatement of the title.

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 an output schema present and annotations covering safety/idempotency, the description covers purpose, alternative routing, filter semantics, and pagination. Nothing needed to invoke it correctly is missing.

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

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

The input schema has no property descriptions (0% coverage), and the description compensates with an Args block for all five parameters, including the source of `publisher_identifier` (`list_publishers`), examples for `access_rights`, and semantics for `page`/`page_size`. This is exactly what an agent needs to construct valid input.

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

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

States a specific action ('List registered datasets') plus an optional filter, and explicitly contrasts itself with `search_catalog`, so an agent can distinguish it from its siblings without opening schemas. The scope is clear and the comparison reinforces what this endpoint is for.

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

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

The description explicitly names the alternative (`search_catalog`) and gives the deciding factors: correct pagination, complete ~2000-dataset register, and coverage of records the search index misses. This tells an agent when to choose this endpoint over the search-based sibling.

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, idempotentHint, openWorldHint, and non-destructiveness, so safety is covered. The description contributes no behavioral detail beyond that—nothing about pagination iteration, ordering, response shape, or side effects—so it adds little transparency 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 description is short, front-loads the purpose in one sentence, and then presents a compact args list where each line earns its place. No redundant prose or repetition of schema defaults.

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 paginated list with a full output schema and strong annotations, the description covers the essential context: what the tool returns at a conceptual level and what each argument controls. An agent has enough to invoke it correctly without needing extra return-value or safety detail.

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

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

With 0% schema description coverage, the description compensates by explaining every parameter: publisher_identifier's source from list_publishers, language's effect on titles and descriptions, page as 1-based, and page_size's range. This is meaningfully more than the bare schema types and defaults, though the definitions are terse.

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

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

The description uses a specific verb ('List') and a clear resource ('registered public services'), with a helpful parenthetical explaining what public services are. It does not explicitly contrast itself with sibling tools like list_data_services, so it stops short of full sibling differentiation.

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

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

The phrase 'registered public services (administrative offerings for citizens)' implies this is the tool for administrative offerings, and the mention of list_publishers suggests a workflow, but there is no explicit when-to-use, when-not-to-use, or alternative tool guidance. Usage is inferred from the name and description 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=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds useful context beyond this by disclosing the return payload (publisher identifiers plus Swiss UID) and the UID's role as the join key to register-mcp (Zefix). No contradiction exists.

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

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

The purpose is front-loaded in the first sentence, followed by a brief return-value note and a clean Args block. Every line adds information with no padding, repetition, or vague 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 an output schema present and all five optional parameters documented in both schema (defaults, enums, bounds) and description, an agent has what it needs to call the tool correctly. Defaults like language 'de' and page_size 50 are already encoded in the schema, and the description covers the rest — the tool is simple enough that 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 0%, so the description carries the full burden for parameter meaning — and it delivers. All five parameters are explained in an Args block, with concrete format guidance: the 'CHE-123.456.789' UID example, 1-based pagination, the 1-100 page_size bound, and language applicability. This completely compensates for the empty schema descriptions.

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

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

The first sentence names a specific verb (List), a resource (public bodies/publishers), and scope (publishing into I14Y), which inherently distinguishes it from sibling tools like list_datasets and list_public_services. However, it doesn't explicitly differentiate itself from siblings, so it falls short of a 5.

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

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

The statement 'Returns publisher identifiers needed by the other tools' gives clear context for when to use it — when a downstream tool requires a publisher identifier. It stops short of naming alternatives or exclusions, such as when to prefer search_catalog over this tool.

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

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

Annotations already mark the tool readOnly/idempotent; the description goes beyond them by disclosing that the upstream index only covers Datasets, that Concept/DataService filters return zero results, and that the server caps the limit because upstream ignores paging. This is exactly the context 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?

Although relatively long, each sentence adds operational value: purpose, return fields, limitation, and parameter caveats. It is organized with a clear intro, limitation callout, and compact Args list. No filler or duplication of the schema.

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

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

With six parameters, an output schema, and sibling discovery tools, the description covers selection, invocation, parameter semantics, and expected returns (titles, publishers, themes, permalinks). The only aspects left implicit, such as sorting/pagination, are either addressed via the limitation or likely covered by the output 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 coverage is 0%, but the Args block describes every parameter with practical detail: query includes examples and an empty-string warning, types carries the 'only Dataset works' caveat, and limit explains the 1-200 cap and server-side capping. This fully compensates for the schema's lack of descriptions.

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

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

Description opens with a specific verb and object: 'Search Switzerland's national metadata catalogue for data resources,' and narrows the tool's role as 'the primary entry point' for discovery. It explicitly distinguishes itself from dataset-specific lookups ('before looking for a specific dataset') and from type-specific siblings by stating which entity types are unsupported. This leaves no ambiguity about what the tool is for.

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 states when to use ('find out who publishes data on a topic before looking for a specific dataset') and what NOT to use it for via the known limitation. It explicitly routes Concept and DataService searches to list_concepts and list_data_services. The empty-query warning also sets expectations around acceptable use.

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 mark the tool read-only, idempotent, and non-destructive. The description adds non-redundant behavioral context: only CodeList concepts return entries and `language` is required by the upstream API, which helps an agent anticipate failures. No contradiction with 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 description is two short paragraphs plus a compact Args list. The core purpose and key constraint are front-loaded, and each sentence adds information without repetition or filler.

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

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

For a paged read-only listing tool with an output schema available, the description covers purpose, applicable concept type, pagination parameters, and the upstream language requirement. It doesn't fully specify behavior for invalid or non-codelist concept IDs (empty vs error), but the CodeList-only statement largely covers the main edge case.

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

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

With 0% schema-level parameter descriptions, the Args section carries the full burden and succeeds: each parameter gets a purpose, and `concept_id` is tied back to `list_concepts`, `language` noted as required upstream, and paging semantics are stated. This is complete and meaningful compensation for the schema gap.

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

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

The description opens with 'List the individual codes of a code-list concept,' a specific verb-plus-resource statement that clearly distinguishes this from sibling tools like list_concepts and get_concept. The title reinforces the scope without ambiguity.

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 says 'Use this to resolve official code values' and adds the precondition that only concepts with `concept_type == "CodeList"` return entries, giving clear when-to-use context. It does not explicitly name sibling alternatives or state 'do not use for X,' so it earns a 4 rather than 5.

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