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

No annotations are provided, so the description carries the full burden. It discloses what the call yields (filter keys, valid values, source URL) and its role as a prerequisite step, but says nothing about permissions, rate limits, or failure behavior for an unknown dataset_id — the kind of behavioral detail an unannotated tool would ideally supply.

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, then the usage rule, then returns — a sensible ordering with no filler sentences. Slight redundancy: the 'Returns: DatasetDetail with ...' block restates fields that an output schema already publishes, so a sentence is spent duplicating structured data.

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

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

For a one-parameter read tool with a rich output schema, the description supplies everything needed: what it does, why to call it first, and concrete example filter keys/values. It is essentially complete, with only minor gaps around error cases and freshness of the discovered metadata.

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%: the single `dataset_id` parameter already documents its curated-ID nature, case-insensitivity, and discovery path with examples. The description's concrete filter keys and values are about the *result*, not about how to set the parameter, so it adds little beyond the schema — 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 a specific verb and resource ('Describe a dataset's filterable dimensions, returnable measures, and source') and explicitly separates itself from the sibling `get_data`, which it positions as the downstream step. An agent can distinguish this metadata-inspection tool from retrieval tools without opening a schema.

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

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

It gives a clear precondition ('Use this before calling get_data on a new dataset') and names the alternative being deferred to. It does not explain when this is unnecessary (e.g., a dataset already described) or route to the other siblings `search_datasets` / `list_curated` for discovery, so it stops just short of a full when/when-not 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?

With no annotations, the description carries the burden, and 'Query... return matching rows' implies a read-only operation but never states it outright. It does add useful behavioral detail (CC-BY attribution, source URL, row_count, and the authorisation truncation rationale), though some of that overlaps the schema. No auth, rate-limit, or pagination behavior is disclosed.

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 tight one-line purpose statement is front-loaded, followed by four compact examples that each illustrate a distinct capability. The examples are longer than strictly necessary but each earns its place by showing a different parameter combination.

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 query tool with an output schema and 100% schema coverage, the description supplies the practical context an agent needs (discovery pointer, example filter usage, truncation caveat). The Returns section partially duplicates the output schema, so there is minor redundancy rather than a gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The examples reinforce real filter keys and the start_period/end_period pairing, but they largely restate what the schema already documents thoroughly rather than adding new 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 opening sentence gives a specific verb and resource ('Query a curated ASIC register dataset and return matching rows'), and the four worked examples make the scope concrete. It stops short of naming or contrasting siblings like search_datasets or describe_dataset, so an agent still has to infer routing, but the purpose itself is unambiguous.

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

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

The examples effectively demonstrate the range of valid invocations (filters, period bounds, include_full_authorisation) and the dataset_id schema note points to the discovery tools. There is no explicit when-not-to-use or a stated 'call describe_dataset first' workflow, so it is clear context rather than full routing guidance.

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

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

With no annotations, the description carries the burden well: it discloses the 50-row default cap, that huge registers blow the context window, that truncation sets DataResponse.truncated_at, and that `authorisation` is silently truncated to ~200 chars unless include_full_authorisation=True. It does not state read-only status, permissions, or rate limits, which keeps it out of the top band.

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 a one-line summary, then contract details, then worked examples; every block earns its place and the examples double as invocation templates. It is longer than strictly necessary, with some repetition of limit behavior between prose and 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?

An output schema exists, yet the description still explains the truncated_at signal, which is the key thing an agent must react to. Combined with the filter/limit guidance, it is complete enough to call correctly, missing only sibling-selection guidance and any note on write-safety or auth.

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 exceeds it by adding rationale and cross-parameter interaction (filter vs. limit tradeoff, include_full_authorisation being ASIC_AFS_LICENSEE-only,-string fallback for filters). The examples duplicate the schema's own examples rather than adding new syntax.

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: 'Return the most recent observation(s) per measure for a dataset', and clarifies two distinct semantics (register snapshot vs. time-bounded fields). It never explicitly contrasts itself with siblings like get_data or list_curated, so an agent must infer the boundary, but the purpose itself 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?

Gives concrete guidance: pass `filters` to drill into one entity without truncation, or raise `limit` for a bulk dump, backed by four worked examples. It stops short of an explicit 'use latest instead of get_data when...' rule, so the selection boundary against siblings is left implicit.

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

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

No annotations are provided, so the description carries the burden, and it does add real context: the listing is read-only in nature and the curated IDs are specifically the ones where get_data supports plain-English filter keys and returns aliased, well-typed columns. It also states the return shape is a sorted list. It doesn't cover versioning behavior or what happens if the dataset set changes, hence not a 5.

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

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

The purpose is front-loaded in the first sentence, followed by a compact explanation of curated semantics and a short Returns block. All content earns its place, though the line break structure is slightly looser than necessary for such a small tool.

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

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

With no parameters and an output schema present, the description only needs to convey purpose and the meaning of the returned IDs, which it does. The remaining gap is the absence of routing guidance against search_datasets/latest, which is a minor omission for a simple enumeration 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?

The tool takes zero parameters, so by rule the baseline is 4. The description correctly reflects a no-argument listing and adds no misleading parameter hints.

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

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

The description gives a specific verb and resource — 'List every curated dataset ID in this version of asic-mcp' — and defines what 'curated' means in terms of sibling behavior (get_data accepts plain-English filter keys; IDs are documented via describe_dataset). An agent can distinguish this from search_datasets without opening any 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?

It implies a discovery role by tying curated IDs to get_data and describe_dataset, but never states explicitly when to call this versus search_datasets or latest. No exclusions or prerequisites are given, so usage must be inferred.

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

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

No annotations are provided, so the description carries the burden. It discloses the matching surface (IDs, names, descriptions, curated keywords), case-insensitivity, relevance ranking, and the returned DatasetSummary fields. It omits no harm salient for a read-only search, though it never explicitly states the read-only nature.

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 what/where is front-loaded before the catalogue enumeration and code examples, and the examples earn their place by showing expected return shape. The long enumerated list of register types is somewhat bulkier than necessary for an agent that already has list_curated().

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, the description needn't explain return fields, and its inclusion of matching scope and ranking behavior is sufficient for correct invocation. Slight gap in not clarifying how results relate to the other sibling tools, but nothing blocking.

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 query and limit in full. The description adds only illustrative query examples, not new parameter semantics, so the baseline 3 is 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?

States a specific verb (fuzzy-search) and resource (the curated ASIC dataset catalogue), and immediately differentiates itself from the list_curated sibling by noting that list_curated gives the live list rather than a search. An agent can tell it apart from siblings without opening any 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?

Explicitly routes agents to list_curated() for the live list and demonstrates two concrete query scenarios, giving clear usage context. It does not, however, clarify how this differs from describe_dataset, get_data, or latest, so the sibling guidance is partial rather than complete.

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