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

With no annotations provided, the description carries the burden of explaining behavior. It communicates that the operation fetches metadata and lists what is returned, which is useful. It does not explicitly state read-only behavior, error conditions, or any caveats, though 'Fetch' strongly implies a non-mutating lookup.

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

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

The description is three efficient sentences: what it does, what it returns, and why to use it. Every sentence contributes value, and nothing is redundant or 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?

Given that there is no output schema, the description helpfully names the main return categories. It is complete enough for a straightforward metadata-fetching tool with only two parameters. A slightly richer example of how the metadata supports query construction would make it fully complete.

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

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

The input schema already fully documents both parameters and the language enum, so the description adds little parameter-level meaning. The statement that metadata contains variable IDs and code lists implicitly explains why table_id matters, but it does not go beyond the schema's own 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 description clearly identifies the action ('Fetch detailed metadata for a table') and the resource (a table), and also names the returned components, so the purpose is specific and actionable. It does not explicitly differentiate itself from the sibling tool get_table_info, which could plausibly overlap, so it misses the top score.

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 a clear use case: 'Use this to construct queries.' This tells the agent when the metadata is needed. However, it does not mention alternatives or when not to use this tool, such as distinguishing it from search_tables or get_table_info.

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 of behavioral disclosure. It usefully explains the vs_*/agg_* distinction and points to metadata as the source for valid IDs, but it does not describe the response structure, pagination, or exact return contents. This is adequate for a simple fetch tool but not richly transparent.

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 type definitions and a practical discovery hint. Every sentence earns its place with no filler or repetition of schema details.

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 simple 2-parameter schema and the absence of an output schema, the description is largely complete: it defines what code lists are, how IDs are structured, and where to find valid IDs. The only notable gap is the lack of explicit return-format detail, but the definition of valuesets/groupings indirectly conveys what will be retrieved.

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, but the description goes beyond the schema by explaining the meaning of ID prefixes (vs_* vs agg_*) and providing concrete examples. The language parameter is already fully documented in the schema, so the description does not need to repeat it.

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 'Fetch a code list', a specific verb and resource, and immediately clarifies the two types (valuesets vs_* and groupings agg_*). This distinguishes the tool from siblings like query_table or fetch_metadata, which serve different data/metadata needs.

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

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

The description implies when to use the tool—when you need valid values or aggregation mappings—and explains how to discover available code lists via table metadata. However, it does not explicitly state when NOT to use it or name alternative sibling tools, leaving some 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates a read-only retrieval operation and specifies the kind of data returned (title, time range, variables). While it doesn't discuss errors, pagination, or permissions, none of those are implied threats for this simple overview function.

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 deliver the core purpose and usage guidance with no filler. The primary functionality is front-loaded, and the usage note earns its place by clarifying when to invoke this 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?

The description sufficiently covers what the tool does and what it returns given its low complexity and fully documented parameters. It could be slightly richer about the response structure, but for a basic overview tool, the information provided is adequate.

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 input schema fully documents both table_id and language. The description adds no additional parameter meaning beyond what the schema already provides, so 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 action ('Get') on a clear resource ('table') and enumerates the scope of information returned (title, time range, variables). It also distinguishes itself from the sibling fetch_metadata by framing this as a 'quick overview' before full metadata retrieval.

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 'Use this for a quick overview before fetching full metadata' gives clear, context-specific guidance on when this tool is appropriate. It doesn't explicitly name alternatives or list when-not-to-use conditions, but the intended workflow is apparent.

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

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

With no annotations provided, the description carries the full burden and clearly states the operation (listing), the selection criterion (tables updated within N days), and the intended purpose. It is non-destructive and transparent, though it does not describe the return format or any 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?

Two short sentences that front-load the action and temporal scope, followed by the intended use case. There is no redundant or filler content.

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

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

For a tool with only two parameters and no output schema, the description is sufficient to invoke it correctly. The schema covers parameter details and the description adds the use case, though naming sibling alternatives would improve completeness.

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 fully documents both parameters. The description references 'N days' but adds little meaning beyond what the schema already provides, so 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 uses a specific verb ('List') and resource ('tables') with a clear temporal filter ('updated in the past N days'). It clearly communicates the tool's scope, though it does not explicitly differentiate it from sibling tools like search_tables.

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 sentence 'Use this to find newly published statistics' provides an explicit intended use case. It does not mention exclusions or alternatives, but the context is clear enough for a simple list 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?

With no annotations, the description must carry behavioral disclosure. It does usefully document value-selection syntax and output formats, implying a read-only data fetch, but it never states whether the operation is read-only, what the response structure looks like for each format, or any API constraints/limits. This 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?

The description is tightly organized with a one-line purpose, a bulleted syntax reference, a one-line format list, and a layout tip. No filler is present, though the output-format list partially duplicates the schema enum.

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

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

For a 6-parameter tool with nested objects and no output schema, the description covers the critical query syntax and format options, but it does not explain the response/return shape for any format, when to use code_list vs value_codes, or how output_values affects results beyond the schema's terse note. It is functional but leaves gaps.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds significant value by specifying exact valueCodes syntax (wildcards, top(N), from(...), range(...)) that the schema only hints at with examples. It also explains layout control via stub/heading for certain output formats, going 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 opens with 'Query data from a table using the v2 API syntax,' identifying both the action (querying) and the resource (table). This is clear and distinct from siblings like search_tables and get_table_info, though it does not explicitly contrast itself with them.

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

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

No guidance is given on when to choose query_table over the sibling tools. It does not state that search_tables should be used to find tables first, or that get_table_info/fetch_metadata provide metadata. The only context is 'Query data from a table,' which is more purpose than usage direction.

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 disclosure burden. It transparently documents wildcards, boolean operators, special filters, proximity search, and geographic indicators. It does not mention result shape or pagination, but it meaningfully explains how the search behaves beyond what the name alone suggests.

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 efficiently structured: the purpose is front-loaded in the first sentence, and the query syntax is organized as a scannable bullet list. Every clause contributes useful information 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 moderate complexity of the tool, the description is largely complete: it explains the query language, supported filters, and geographic notation. The main gap is that there is no output schema and no description of what the search results contain, which an agent would need to know for downstream steps.

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 already documents all three parameters, so the baseline is 3. The description adds substantial value by explaining query syntax details, filter prefixes, proximity syntax, and geographic code meanings, which go far beyond the schema's examples. The language and include_discontinued parameters are fully covered by 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 opens with a specific action and resource: 'Search for tables in Statistics Norway (SSB) database.' This clearly distinguishes it from sibling data-retrieval tools like query_table and metadata tools like get_table_info.

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 establishes clear context for when to use this tool: when looking for tables by metadata using search syntax. It does not explicitly discuss alternatives or exclusions, such as 'use query_table to retrieve data,' but the purpose is clear enough for an agent to infer the intended use.

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