SCB: slå opp gyldige koder for én variabel

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

No annotations are present, so the description carries the full burden. It does disclose the core behavior — returning code/text pairs and optionally filtering by search text — and adds source/license context. However, it doesn't explain important behavioral details such as whether search is case-insensitive, substring-based, or how invalid sti/variabel values are handled.

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

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

The description is short and front-loaded: first sentence states the function, second gives a concrete usage example, third provides source and license. Every sentence earns its place with no 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?

With no annotations and no output schema, the description needs to fully compensate for missing structured context. It explains what the tool returns at a high level but leaves the required 'sti' parameter ambiguous and does not describe result shape or edge-case behavior. This is enough for a simple example, but not fully complete for reliable 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 already documents 'søk' and 'variabel', and the description's Malmö example adds little beyond that. The required 'sti' parameter is undocumented in both the schema and the description; the agent is left guessing what format or source the path should have, which is a significant gap for a required parameter.

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 states a specific action: 'Gir kode/tekst-parene for én variabel i en tabell', with a concrete example ('finne f.eks. kommunekoden for Malmö'). This clearly separates it from sibling tools like scb_tabell_data (fetch data) and scb_tabell_info (table metadata) by focusing on valid code lookups for a variable.

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 an explicit usage context: use it to look up codes before fetching data ('før du henter tall'). It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to know when this lookup step is appropriate.

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