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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the automatic fallback to sub-unit (underenhet) lookup when the ID is a location, which an agent could not infer from the schema. It stops short of auth/rate-limit or result-shape detail, but the fallback disclosure is a meaningful addition.

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 and identifier format are front-loaded, followed by the field list, fallback behavior, and alternative tool. The field enumeration is long but functional since it tells the agent what one call yields; nothing is wasted, though it is dense.

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 single-parameter lookup with an output schema, the description covers everything an agent needs: identifier format, an example, the alternative tool for name-only queries, and the sub-unit fallback. Return-value detail is not needed because an output schema exists.

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% and the single parameter is fully documented as '9-digit organisation number'. The description restates the same format and adds only an example value, so it adds marginal value over structured data. 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?

States a precise verb+resource ('Full record for one Norwegian company') and enumerates the returned fields (address, industry codes, employee count, VAT, bankruptcy status), making the scope unambiguous. It is clearly differentiable from sibling search_companies and get_company_financials.

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 the agent: 'Use search_companies first if you only have a name', and notes the sub-unit fallback when the orgnr is a business location rather than a legal entity. Both the when-to-use and the alternative are named.

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/openWorldHint annotations, the description discloses valuable behavior: only the latest filed year exists, a PDF link is included, coverage is not universal, and missing data returns a clear 'no accounts filed' result rather than an error. These are exactly the traits an agent needs to handle results and failures.

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, then the field list, then constraints and edge cases. Dense but every sentence earns its place; 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?

Since an output schema exists, return-value explanation is not required, yet the description still summarizes the returned fields. Combined with annotations and the documented edge cases, an agent has everything needed to invoke and interpret this 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 100% (the single orgnr parameter is documented as '9-digit organisation number'), so the schema carries the load. The description adds a concrete example value (orgnr='923609016'), which is mildly helpful but not substantive parameter semantics 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?

Specific verb+resource: retrieves latest filed annual accounts for a Norwegian company from Regnskapsregisteret, with an enumerated field list (revenue, operating profit, net result, total assets, equity, debt split, period, currency). It is clearly distinguishable from the other get_company* siblings by focusing on financial statements and names the exact source registry.

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 triggering question ('what was X's revenue/profit') and the key constraint that only the most recent filed year is available, plus the edge case that sole proprietorships may not file. No sibling alternative is named explicitly (e.g. get_company for general info), so it falls short of full when/when-not routing, but the context is 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 cover the safety profile (readOnlyHint, openWorldHint); the description adds useful context beyond that: data source (Enhetsregisteret), that role holders can be persons or companies, and that resignation flags are returned. It does not mention pagination or rate limits, but for a small scoped lookup that is minor.

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 returned fields, then use-cases, then source, then an example — all sentences earn their place. Dense but not padded; slightly long for the simplicity of a two-parameter lookup.

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 needn't be documented, yet the description still names the roles returned. Combined with annotations and full schema coverage, an agent has everything needed to call this 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 100%, so the schema already documents both parameters including the birth-date default. The description contributes only the example orgnr value and the Norwegian-company context, which is marginal beyond the schema's '9-digit organisation number'.

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 ('get_company_roles') with the exact scope enumerated: chair, board members, CEO, auditor, with names and resignation flags. It is clearly separable from siblings like get_company (registry data), get_company_financials, and get_group_structure.

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 maps user questions to the tool ('who is on the board of X', 'who runs X', 'who audits X'), giving clear context for when it applies. It does not explicitly state when to prefer a sibling like get_company or get_group_structure instead, so no exclusion 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: Norges Bank as source, daily business-day cadence, and the normalization convention (NOK per 1 unit). It omits rate limits and error behavior, keeping it short of 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?

Four tight sentences, front-loading the resource and source, then configuration semantics, then routing, then an example. Every sentence carries distinct 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?

An output schema exists, so return structure need not be described, and the description still supplies the interpretation keys (normalization basis, business-day window) an agent needs. No gaps remain for a two-parameter read 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: that `periods` counts business days and that all columns are normalized to NOK per one unit. The inline example with currencies=['USD','EUR'], periods=30 reinforces correct usage.

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 (daily NOK exchange rates), names the data source (Norges Bank), and explicitly distinguishes itself from the sibling get_key_series for interest rates. An agent can identify the tool without opening the 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?

Gives concrete query patterns ('USD/NOK rate', 'how has the krone moved against the euro') and an explicit alternative with the parameter to use instead (get_key_series(series='interest_rates')). Nothing is left 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?

Annotations already cover the safety profile (readOnlyHint, openWorldHint), but the description adds genuine behavioral context: the return is a nested ownership tree, and non-group companies yield 'a clear answer, not an error' — a useful disclosure about edge-case handling that the annotations do not convey. It adds less about rate limits, permissions, or depth 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?

Front-loaded purpose, then query phrasings, then edge case, then example — a sound information hierarchy with no filler. The three paraphrase questions are slightly redundant, which keeps it just shy of maximal conciseness.

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 explanation is not required, yet the description still sketches the tree shape. With one fully documented param, annotations covering safety, edge-case behavior stated, and a concrete example, an agent has everything needed 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 100% and already documents the single param as a 9-digit organisation number, so the baseline is 3. The description goes slightly further by supplying a concrete worked example (orgnr='923609016' for Equinor), which grounds the expected format and output for the agent.

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+scope: 'Registered group structure (konsern) for a Norwegian company by orgnr', with the exact return shape (nested parent/subsidiary tree with ownership stakes). It is clearly distinguishable from siblings like get_company (single company) and search_companies (lookup) 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?

It routes by user intent, listing the natural-language questions it answers ('what companies does X own', 'is X part of a group', 'who are X's subsidiaries'), which tells the agent when this tool is the right choice. It stops short of naming an alternative tool or stating explicit exclusions, so it is clear but not fully comparative.

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 and openWorldHint, so safety is covered. The description adds real behavioral context beyond that: 'no table IDs needed' (contrasting with the ID-based chain), that it returns the last `periods` observations, and that each series has specific statistical definitions (LFS seasonally adjusted, NIBOR + policy rate, 12-month inflation). It does not mention rate limits or exact output shape, but the output schema covers the latter.

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-loads the tool's role, then the series inventory, then usage and an example. The long enumeration earns its place because each entry resolves an otherwise opaque enum token; no sentence is 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 an output schema exists, return values need not be explained; the description still covers scope, the alternative workflow it replaces, parameter meaning, and a concrete call example. 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?

Schema coverage is 50% — `series` is an undescribed enum, `periods` is documented. The description compensates by explaining what each enum value actually contains (cpi includes 12-month inflation; unemployment is LFS, seasonally adjusted), which is meaningfully more than the bare enum list, and confirms periods = last N observations.

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 concrete verb+resource ('one-call shortcut' returning named Norwegian time series) and enumerates the six resolvable series, which no sibling tool offers. An agent can distinguish it from search_statistics/get_statistics/get_table_info purely from the description.

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 says to use it 'instead of the search/info/fetch chain' and gives representative natural-language queries ('what is inflation in Norway'), plus a worked example with series='cpi', periods=24. The routing decision is fully specified.

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 and openWorldHint, so the safety profile is covered. The description adds real context beyond that: the returned fields (name, navneobjekttype, municipality, coordinates) and the wildcard-capable query surface. It stops short of noting pagination or result-limit behavior.

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 routing guidance, then examples — all three sentences earn their place. The two examples are slightly redundant with each other, which keeps it just under a 5.

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-format explanation is not required, yet the description still names the key returned fields, and it covers scope, routing to the alternative, and input examples. Nothing an agent needs 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?

Schema coverage is 50%: query is documented in the schema ('Place name, wildcard * allowed') and the description's examples reinforce it. The limit parameter has no description anywhere beyond its default/min/max bounds, and the description does not compensate for that gap, so it stays at the baseline.

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 ('Search official Norwegian place names') plus the covered entity types (mountains, lakes, valleys, farms, islands, neighborhoods). It explicitly distinguishes itself from the sibling search_address tool, so an agent can route correctly 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?

Gives an explicit when-to-use ('target is not a street address') and names the alternative for the complementary case ('for street addresses use search_address'). The two example queries also anchor expected input style.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations by describing what is returned (representation point lat/lon, optional boundary polygon GeoJSON) and by flagging the licensing constraint on owner/building/valuation data with instructions to acknowledge the gap rather than guess. This is high-value behavioral context beyond structured fields.

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-loads the action and resource, then adds the input convention, the return behavior, the critical data-availability caveat, and an example — 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 an output schema already covers return structure, the description supplies the missing pieces: identification convention, expected output shape, and the important scope limitation. Nothing an agent needs to call the tool correctly is absent.

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 field semantics are already documented and the baseline is 3. The description adds a concrete worked example (kommunenummer='0301', gardsnummer=207, bruksnummer=100) and ties the parameters to the matrikkel number concept, adding real value over the schema's terse labels.

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 ('Locate') and a precise resource ('Norwegian cadastral property (matrikkelenhet)') with the exact identifier triplet required. It also disambiguates from the sibling search_address by naming it as the upstream source of the matrikkel number.

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 the context for use ('e.g. from a search_address result') and explicitly warns what cannot be retrieved (owners, buildings, valuations), routing the agent away from wrong expectations. It does not, however, name a competing sibling or state when NOT to call it.

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 cover safety (readOnlyHint, openWorldHint), and the description adds real behavioral context beyond them: default fallback behavior, the closed-table successor handling with hints, and the expression syntax accepted. It does not discuss rate limits or payload size, but for a read-only query tool this is substantive added value.

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 core behavior and defaults are front-loaded, and the expression list and two examples each earn their place by disambiguating syntax that the schema only names. It is on the long side, but no sentence is pure 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 3-parameter tool with an output schema, the description covers the ambiguous parts: default selection, expression grammar, and closed-table fallback. Return format is rightly left to the output schema, though lang's effect on results is never mentioned.

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 67%, and the description meaningfully compensates by documenting the selection mapping format ('variable code -> value-code lists') and the allowed expressions from(...)/top(n)/*. Both worked examples tie table_id and selection to concrete outputs, which the schema alone does not convey; only lang is left without added explanation.

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 ('Fetch numbers from an SSB table as a compact CSV table') and immediately frames the tool around retrieval plus selection, which separates it from search_statistics and get_table_info. An agent can tell what it does without opening the 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?

Explains the default path when no selection is given ('totals ... and the last 12 periods, good for recent trend questions') and the alternate path when breakdowns are needed, including the dependency on get_table_info for variable codes. It does not explicitly contrast the tool with search_statistics, so it falls short of naming alternatives, but context is 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=true and openWorldHint=true, so safety profile is covered. The description adds real behavioral context: what the response contains, and notably that a closed table will report a successor table, which an agent could not infer from the schema or 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?

Front-loaded with purpose, then usage conditions, then a concrete example. Three dense sentences with no filler; every clause carries information.

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 single-parameter lookup with an output schema, this covers purpose, usage, expected content, and a worked example. Nothing needed 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?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by giving a concrete table_id example ('07459') and translating the opaque code into actual dimension names an agent will recognize. That meaningfully aids correct invocation.

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 resource and exactly what it returns: variables (dimensions), accepted value codes, time span, and successor table if closed. This is clearly distinguishable from siblings like search_statistics and get_statistics, which the description itself names.

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 says when to use it ('between search_statistics and get_statistics when you need a specific breakdown (region, industry, age group)') and when to skip it ('when defaults are fine (totals, recent periods)'). This is textbook when/when-not 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds real context beyond them: the dataset is limited to Norwegian addresses, results are ranked by distance, and only officially registered addresses are returned. It does not disclose what happens when no address falls within the radius.

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?

Four tightly packed sentences, front-loaded with the resource definition, then output contents, then usage, then a concrete example. 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?

An output schema exists so return values needn't be re-explained, and annotations carry the safety profile; the return-format sentence is still helpful. The main remaining gap is the unexplained 'limit' parameter and the absence of an explicit pointer to search_address for the reverse 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?

Schema coverage is only 25% — just 'radius' is documented in the schema, and 'limit' is undocumented in both schema and description. The description contributes semantics for lat/lon via the example and for radius via 'radius=100', but leaves the default result count and its cap unaddressed, so it only partially compensates for the coverage 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?

States a specific verb+resource with scope: 'Nearest official Norwegian addresses to a coordinate', and even names the payload (distance, municipality, cadastral identifiers). An agent can immediately distinguish this from the forward-looking search_address sibling without opening the 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?

Gives concrete when-to-use guidance ('what address is at lat X, lon Y', anchoring GPS positions) with a working example invocation. It stops short of explicitly naming search_address as the forward-geocoding alternative for name-based lookups, so routing between the two is left 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?

Annotations declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context: it handles partial input and typos, and returns coordinates in EPSG:4258 plus cadastral IDs. It does not discuss failure modes or rate limits, but it meaningfully exceeds 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?

Front-loaded with the core purpose and return payload, then usage and alternatives, then an example. Dense but each sentence carries routing or semantic value; only the return-detail sentence partly overlaps the output 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 an output schema present, return values need not be re-explained, yet the tool's routing, typo tolerance, and example are all covered. Minor gap is the undocumented limit parameter, which leaves result-count behavior unstated.

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 67%: query and kommunenummer are documented, limit is not. The description adds a concrete example query value, which helps with format, but it never explains the limit or municipality filter parameters beyond what the schema already says. 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?

States a specific verb (search) and resource (official Norwegian addresses), and explicitly says it also resolves address to property ID via cadastral identifiers. It distinguishes itself from siblings get_property and get_place by name.

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 explicit when-to-use ('where is <address>', first step before get_property) and when-not (place names that are not street addresses → use get_place). The alternative routing is unambiguous.

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 and openWorldHint, so safety is covered. The description adds real behavioral value beyond that: the returned field set and the decoding of status flags (konkurs = bankrupt, underAvvikling = being dissolved), which the annotations do not convey.

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 and return contract are front-loaded, then usage routing, then compact examples. Slightly verbose with three trailing examples, but every sentence carries information.

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 field list is a bonus rather than a necessity, and routing plus filters plus examples are all covered. The only gap is pagination behavior ('page' is never described), which is minor given an output schema exists.

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 56%, leaving page, limit, min_employees and max_employees undocumented in the schema. The description compensates by explaining limit in the return sentence and giving concrete value examples for naeringskode, kommunenummer and min_employees, though 'page' remains unexplained in both.

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 ('Search the Norwegian company register') plus an explicit enumeration of what is returned. It clearly distinguishes itself from get_company by naming the exact condition (no orgnr) that selects it.

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?

State 'Use when the user names a company without an orgnr or asks find companies that...' and the alternative 'If you already have an orgnr, call get_company instead' give an explicit when-to-use and when-not-to-use with the routing sibling named.

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 and openWorldHint, so safety and search scope are covered. The description adds what a caller would not otherwise know: a summary of the return payload (table IDs, titles, time coverage, last-updated dates) and the position of this call in a multi-step chain. It does not discuss result limits or pagination, which keeps it short of 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?

Front-loaded with purpose and routing before workflow and examples, which is the right order. Slightly over-long at the tail, with two separately labeled 'Example:' clauses and repeated parenthetical asides that a single terse example line would cover.

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 search entry point with an output schema present, the description supplies everything an agent needs: routing against the key-series sibling, payload contents, multilingual query support, and the downstream call sequence. No return-value detail is required given 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 50%: the schema documents 'query' but not 'limit', and the description never mentions the result-count parameter or its maximum of 40. It does add language guidance and two concrete query examples, which enriches the required parameter beyond the schema, but the undocumented parameter keeps this at baseline.

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 ('Search Statistics Norway's ~7,000 statistical tables by keyword') and scopes the corpus size. It explicitly names the sibling it is not (get_key_series), so an agent can route 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?

Declares itself 'always the first step for statistics questions unless get_key_series covers it', enumerates the exact topics that alternative covers, and prescribes the follow-up workflow (get_table_info then get_statistics). Both when-to-use and when-not-to-use are explicit.

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