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

No annotations are supplied, so the description carries the full behavioral burden. It usefully warns that full_description can add a lot of text ('kan veel tekst zijn'), which matters for context budget, but it says nothing about read-only semantics, error behavior for unknown IDs, 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?

Purpose is front-loaded in the first sentence, navigation guidance second, and arguments last, which is the right order for a lookup tool. Slightly verbose in restating that it is a description of a table, but nothing is genuinely 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?

An output schema exists, so return-value documentation is not needed, and the description is sufficient for a two-parameter read lookup. The remaining gaps are the upstream step for obtaining table_id and behavior on invalid IDs; minor for a tool of this complexity.

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 parameter meaning, and it largely does: table_id is illustrated with concrete example IDs ('83765NED', '85874ENG'), and full_description is explained as adding the long official explanation with a size caveat. It doesn't state the default for full_description or any ID-format constraints, but both params gain meaning beyond the bare 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 gives a specific verb+resource: it returns one table's description plus its dimensions (filter targets) and measure count. It explicitly distinguishes itself from siblings by naming get_table_measures for columns and list_dimension_values for dimension values, so an agent can route correctly 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 states the usage context ('Dit is het startpunt om door een tabel te navigeren') and names two follow-up alternatives with their purposes. What it doesn't state is how table_id is obtained in the first place (search_tables), so the workflow entry point is implicit rather than fully spelled out.

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

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

With no annotations present, the description must carry the behavioral load. It does disclose pagination via offset, a hard cap of 1-200 on limit, and that results carry unit and subject group, but it never states that this is a read-only listing or what happens with an invalid table_id.

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 one-sentence purpose followed by a compact Args list; every line adds something. The Args formatting is boilerplate, but no sentence is wasted.

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

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

An output schema exists so return values need no explanation, and all four parameters are addressed with the key constraints. The remaining gap is the absence of any safety or failure-mode context, which matters more because no annotations are supplied.

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 largely does: search is explained as matching title, key, group or description, and limit gains a 1-200 range constraint absent from the schema, while offset is tied to pagination. Only table_id is restated rather than explained.

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

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

States a specific verb and resource ('Lijst de meetwaarden') and disambiguates the term measure as 'kolommen met cijfers', plus notes the enrichment with unit and subject group. It does not explicitly contrast itself with siblings like get_table_info or list_dimension_values, so an agent must infer the split.

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: fetch measures for a given table_id. There is no statement of when to prefer this over list_dimension_values (the complementary tool) or query_data for actual values, and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose useful behavior: pagination via limit (1-500)/offset and the period key encoding ('2023JJ00', '2023KW01', '2023MM01'). However, it does not state read-only safety, whether values are exhaustive, or result ordering.

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 integration note, then a compact Args block. Every element earns its place, though the Args section is slightly list-like 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?

An output schema exists, so return values need not be described. The description covers the key format, the link to query_data.filters, and all five parameters, making it sufficiently complete for an agent to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains table_id, dimension (with an example pulled from get_table_info), search (matches key/title/group with an example), limit (bounded 1-500), and offset (pagination). This adds meaningful semantics absent from the bare 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?

Specific verb+resource ('Lijst de geldige waarden van een dimensie') with concrete examples of what a dimension is (regions, periods, gender, industries). It distinguishes itself from siblings by pointing to query_data.filters for the returned keys and get_table_info as the source of the dimension key.

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 ties the tool into the workflow: the returned 'key' is used in query_data.filters, and the dimension argument comes from get_table_info. This gives clear context for when to reach for this tool, though it does not state exclusions or contrast directly against search_tables or get_table_measures.

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 full burden, and it does disclose real behavior: default measures = first 10, limit range 1-1000, offset pagination, OR within a list / AND across dimensions, and that an unfiltered dimension returns all values. It omits auth needs, rate limits, and read-only confirmation, keeping it short of 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 purpose, then filter syntax, a concrete example, and an Args list. It is a bit long and the filter rules partially repeat between the prose and the Args entry, but for a complex query tool nearly 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?

Given a 7-parameter tool with 0% schema coverage but an existing output schema, the description covers purpose, filter grammar, combination semantics, defaults, and pagination. An agent has everything needed to construct a correct call without explaining return shapes that the output schema already defines.

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, which it does thoroughly. It documents all seven parameters in the Args block, including value syntax for filters, the limit range, pagination via offset, label modes, and that odata_filter is AND-appended.

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 line 'Haal cijfers op uit een CBS-tabel' gives a specific verb (fetch) and resource (figures in a CBS table), which is unambiguously the data-retrieval sibling among metadata tools. It only partially differentiates from siblings by deferring to list_dimension_values, so it stays below 5.

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

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

The description gives strong operational context (how filters combine, how to specify time types) and routes the agent to list_dimension_values for valid values. However, it never states explicit when-not conditions or contrasts with search_tables/get_table_measures beyond the implicit workflow.

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

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

With no annotations, the description carries the full burden. It discloses a genuinely useful behavioral trait (automatic refresh after 24 hours) and notes that force re-fetches from CBS. It omits side effects such as network calls, permission needs, or whether refreshing blocks, but the output schema covers return values.

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 status-check purpose, then the refresh behavior, then the argument description. Every sentence earns its place, though a minor formatting nitpick is embedding a fake Args section inline rather than structuring 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?

An output schema exists, so return values need not be explained. The description covers purpose, automatic-refresh policy, and the sole parameter, leaving little an agent needs beyond this to call 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?

Schema coverage is 0%, and the schema entry for 'force' is a bare boolean with default false. The description compensates by explaining what force does ('Haal de catalogus nu opnieuw op bij het CBS'), giving meaning the schema lacks.

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 specific verbs (show status, refresh) and a specific resource (the local catalog cache), which is clearly distinguishable from the query-oriented siblings. It does not explicitly name or contrast with those siblings, so it stays below 5.

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

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

The 24-hour auto-refresh policy implies when a manual refresh is useful, and 'desgewenst' (if desired) signals optionality. However, there is no explicit when-to-use guidance relative to the sibling tools, nor any statement of when a refresh is unnecessary.

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

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

With no annotations, the description carries the full burden and does well: it discloses the matching algorithm including the fallback behavior, that discontinued tables are excluded by default, and the limit range. It stops short of describing result ordering/relevance or pagination behavior beyond the offset hint.

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 core purpose, followed by matching semantics and then a compact Args list; every sentence earns its place. Slightly list-heavy, but 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?

An output schema exists, so return values need not be explained, and the description covers matching rules, scoping, pagination and all parameters. The main gap is routing guidance relative to the four sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate, and it documents all five parameters with meaning plus examples for query. It adds the 1-50 limit constraint that the schema lacks, though default values (10, 0, false, null) are merely restated from the schema.

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

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

States a specific verb and resource ('Doorzoek de CBS-catalogus') and even quantifies scope (~6000 tables), searching on title and description. It does not explicitly name or differentiate itself from siblings like get_table_info or query_data, 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?

Explains search mechanics (prefix matching, all-terms-required with fallback to at-least-one-term) and that a table ID can be passed directly, which implies how to use it. However, it never states when to prefer this over get_table_info, query_data, or refresh_catalog, and gives no exclusions.

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