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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral value beyond them by enumerating the returned fields and coordinate systems (EPSG:25832 and WGS84), which matters since there is no output schema.

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 operation, followed by id provenance, return contents, a worked example, and sibling routing. Every sentence earns its place; only the enumerated field list is slightly long but justified by the absence of an 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 no output schema, the description compensates by listing the returned fields, and it documents the single required parameter's provenance plus an end-to-end 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 the pattern is enforced there, so baseline would be 3. The description adds meaning beyond the schema by identifying the id as the same UUID DAWA uses for /adgangsadresser and giving a concrete example invocation with a real id and expected output.

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 with a precise domain gloss ('husnummer: street + house number, the entrance') and explicit source (DAR). It distinguishes itself from siblings dar_get_address and dar_list_addresses by naming exactly what it returns and routing unit-listing elsewhere.

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 a clear alternative with condition: to list floors/doors at this entrance, call dar_list_addresses with the same id. Also clarifies the id is the same UUID DAWA used for /adgangsadresser, which helps an agent decide it can reuse an id from elsewhere. No explicit when-not guidance relative to dar_get_address or dar_get_street.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: the returned record embeds the husnummer and includes coordinates in two CRS. It does not say what happens for an unknown UUID (empty vs error), which is the remaining gap.

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 the id provenance, then the return payload, then a concrete example call with sample output, then the exclusion. Every sentence carries distinct information with no 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?

With no output schema, the description takes on the return-value burden and discharges it by enumerating the embedded fields and coordinate systems, plus a worked example. Only error/not-found behavior is unaddressed, which is minor for a single-id lookup.

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 schema already documents the UUID format and pattern, so the baseline is 3. The description adds real meaning beyond the schema by clarifying that the id is the same UUID DAWA used for /adresser, which tells the agent where to source valid values.

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 one Danish address ... from DAR by its UUID') and immediately disambiguates the granularity by defining adresse as a specific door/floor unit, which distinguishes it from dar_get_access_address and dar_get_street.

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 names the exclusion ('Not for text search') and routes to the two correct alternatives with the conditions that select them (API key for dar_search_addresses, municipality + road code for dar_list_access_addresses). It also tells the agent when the id is valid (stored DAWA ids keep working).

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 (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial context beyond them: the API key requirement, the ~80,000-character raw size, that doc comments are stripped by default, and that output truncates at 60,000 characters. These are exactly the operational facts an agent needs and cannot get from 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?

Well front-loaded with the auth requirement and resource first, then size/behavior, then the two params with examples. Every sentence carries actionable information (auth, size, default stripping, filter syntax, docs toggle, truncation) 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?

There is no output schema, yet the description compensates fully by describing the return shape: SDL text, doc comments stripped by default, and truncation at 60,000 characters. Combined with the auth requirement and filter semantics, 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%, so the baseline is 3, but the description genuinely enriches both params: filter is explained as matching type/input/enum blocks by case-insensitive name substring with two illustrative examples, and include_docs is clarified as retaining field definitions and legal references. This goes beyond the terse schema 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?

States a specific verb and resource: 'Fetch the GraphQL schema (SDL) for DAR/v2'. This is clearly distinguishable from the sibling dar_graphql, which executes queries, since this tool retrieves the schema itself.

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 operative context well: it requires DATAFORDELER_API_KEY and describes the default doc-stripped behavior versus include_docs. It gives concrete filter usage examples, but never explicitly states when to prefer this over dar_graphql (e.g. before writing a query), so routing to the alternative 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value by naming the return fields and the downstream id handoff, but says nothing about lookup-miss behavior or the fact that both parameters are optional (required: 0), leaving the 'neither supplied' case undefined.

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 compact sentences, front-loaded with the core action and return shape, followed by a concrete example and a workflow handoff. The example earns its place; nothing is padded, though the second sentence carries two distinct ideas.

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 only two params, no output schema and no nested objects, the definition is nearly self-contained: it names the return fields and the follow-up tool. The remaining gap is the optional-parameter edge case, which neither the description nor the schema resolves.

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 baseline is 3, but the description adds real semantics beyond the schema: it frames the two parameters as alternative lookup keys ('by its 4-digit code or by UUID'), which the schema does not state, and ties the returned id to the postcode_id parameter of another tool.

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 (Fetch) and resource (Danish postcode/postnummer) with the two accepted key forms, and enumerates the returned fields (id, code, name, status). This clearly separates it from sibling getters like dar_get_street, dar_get_address and dar_get_access_address, which target different entities.

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?

Provides a concrete example call and, more importantly, states the downstream usage: pass the returned id as postcode_id to dar_list_access_addresses. That routes the agent through a real workflow. It stops short of explicit when-not guidance or stating what happens if neither identifier is supplied.

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 (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds real value by disclosing the return shape (name, administering municipality, per-municipality road codes, postcodes) and the fact that a street can span municipalities, plus an auth note for the alternative tool. It does not address what happens when no key is supplied, which is the remaining gap.

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 sentence, then return contents, then a concrete worked example, then the exclusion and sibling routing. Every sentence carries information and the example disambiguates the composite key format.

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?

No output schema exists, so the description correctly compensates by enumerating the returned fields. It is nearly complete for a read lookup, with the only omission being behavior when no identifying parameter is provided.

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 only 33% and 0 parameters are required, so the description's labeling of municipality_code + road_code as a composite key and street_id as a UUID is genuinely useful. However it never states how the two lookup modes interact if both are supplied, nor what error surfaces with zero parameters.

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 (Fetch) and resource (named road / NavngivenVej) with the two accepted lookup keys (UUID or municipality_code + road_code). It explicitly names the sibling it is not (dar_search_addresses) and clarifies it does not search 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?

Explicitly lists the two use conditions (by UUID, or by municipality_code + road_code) and an exclusion clause ('Does NOT search by name') that routes the agent to dar_search_addresses, noting the API key requirement there. 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 cover the safety profile (readOnly/openWorld/idempotent), and the description adds substantial context beyond them: the API key requirement, the service-enforced virkningstid/registreringstid rule and its consequence (superseded versions), paging caps (first max 1000, default 100), the { data, errors } envelope, and reference-vs-nested-object behavior. This is exactly the kind of behavioral detail an agent cannot infer from 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?

Despite its length, it is front-loaded (purpose, endpoint, auth) and then organized into a scannable rules block plus a complete example and return-shape note. Every line carries operational information the agent needs to build a valid query.

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 output schema, the description compensates by describing the raw return envelope, and it covers auth, entity inventory, mandatory filters, paging, spatial filters, and field-name quirks. Nothing an agent needs to issue a correct first query appears to be 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% for the two parameters (query, variables), so the schema baseline already carries the parameter contract. The description goes further by specifying what the query string must contain (entity names, required time filters, filter operators, cursor paging, ae/oe/aa field encoding) and provides a worked example, adding real meaning 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?

States a specific verb and resource ('Send any GraphQL query') plus the exact endpoint (graphql.datafordeler.dk/DAR/v2), and the 'raw' framing implicitly separates it from the typed sibling helpers like dar_get_address. An agent can identify this as the escape-hatch tool 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 clear context for what the tool is for and directs the agent to dar_get_graphql_schema to discover fields, but never states when to prefer this raw tool over the typed siblings (dar_get_address, dar_list_addresses, etc.) or what it cannot do. Context is clear; exclusions and alternative-selection criteria are absent.

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 (readOnly, idempotent, non-destructive, openWorld), so the description's value is in the extras it supplies: anonymous access when no API key is set, 1-based pagination with page_size capped at 100, and the has_more/full-page continuation rule. It stops short of error behavior or rate limits, but the added operational context is substantial.

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 filters in a scannable bulleted block, then pagination, then the exclusion. Slightly long overall, and the Danish municipality-code examples in the final sentence are borderline redundant, but nearly every line carries actionable 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 an 8-parameter, no-required-parameter list tool with no output schema, the description covers filter selection, pagination, auth mode and result contents (coordinates in EPSG:25832 and WGS84). Only minor gaps remain, such as the default page_size behavior and what happens with conflicting filters.

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 88% so the baseline would be 3, but the description goes further: it frames the four filter parameters as an either/or choice ('filtered by one of'), explains the provenance of each UUID, warns that postcode_id is NOT the 4-digit postcode, and gives a worked call example plus leading-zero municipality codes.

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 ('List access addresses (husnumre)') and immediately distinguishes itself from dar_search_addresses by scope. The parenthetical Danish term and the filter list make the resource unambiguous among the many dar_* siblings.

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 names when to use each filter mode (municipality_code+road_code, street_id, postcode_id, cadastral_parcel_id), where each id comes from (dar_get_street, dar_get_postcode, earlier results), and closes with the exclusion: 'Does NOT search by street name. For that use dar_search_addresses (needs DATAFORDELER_API_KEY).' 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses the return granularity ('compact records'), names the returned fields, and explains the expected cardinality for single-family houses.

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 example, then return shape, then the pointer to dar_get_address. Four short sentences with little waste; the single-family-house note is marginally tangential but earns its place by setting cardinality expectations.

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 output schema, the description correctly compensates by naming the return fields and describing their compactness. Nothing essential to correct invocation is missing for a simple two-parameter read tool; pagination or ordering behavior is unstated but unlikely to matter at this scope.

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 both parameters (access_address_id and the status enum) are already fully documented in structured data. The inline example illustrates realistic ID usage but adds no syntax or semantic detail beyond the schema, so 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?

States a specific verb and resource with scope: 'List the unit addresses (floors/doors) that belong to one access address (husnummer).' The concrete example output (12 addresses at Oehlenschlægersgade 35) lets an agent distinguish it immediately from sibling tools like dar_get_access_address and dar_get_address.

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 to dar_get_address for full detail and notes that a single-family house typically yields one address with no floor/door, which tells the agent when this tool is useful but may return little. It does not explicitly contrast with the closely named siblings dar_list_access_addresses or dar_get_access_address, so the routing guidance is clear but partial.

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 readOnly/idempotent/openWorld/destructive=false, but the description adds substantial non-obvious behavior: the API key requirement, case-sensitivity, automatic first-letter upper-casing, exact-match requirement for Danish letters, unranked results, and cursor pagination. This is well beyond what the structured fields 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?

The critical operational facts (prefix-only, case-sensitive, API key) are front-loaded, and the level breakdown is well structured with examples. It is somewhat long, with a few redundant asides (e.g. the worked example plus inline examples), but nearly every sentence carries load.

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?

There is no output schema, and the description explicitly says the return is ids and text only, tells the agent which sibling to call for coordinates/postcode, and covers pagination. Nothing needed to call this 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?

With 60% schema coverage, the description compensates well: it explains the query prefix format ('Vejnavn husnummer, postnr By'), the meaning of each level enum value, and the after cursor for pagination. It does not cover limit behavior or only_current beyond what the schema already states (status 3 gældende), so it stops short of a 5.

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 (find) and resource (streets, access addresses, unit addresses) plus the matching semantics (official text starts with a prefix). It clearly distinguishes itself from sibling getters by framing itself as the prefix-search entry point and naming the follow-up tools (dar_list_access_addresses, dar_get_access_address).

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 enumerates the three level modes with when-to-use guidance and examples for each, states the default, and names the alternative tools to call afterward. It also states the negative constraint (no fuzzy, substring or typo-tolerant search) and how to disambiguate unranked results.

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/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious operational context: the REST sunset date of 2027-01-15 and what changes after it, plus the CC BY 4.0 attribution obligation. It stops short of stating latency expectations or failure modes, but the added value over annotations is substantial.

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, then a structured 'Returns:' list of the four reportable facts, then a 'Use first when...' routing sentence. Every sentence carries distinct information with no repetition of the title.

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 output schema, the description must enumerate what comes back, and it does — REST reachability and latency, API-key configuration, sunset date, and attribution text. That is exactly the information an agent needs to interpret the response and act on it.

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 the baseline of 4 applies per the rubric. There is nothing for the description to clarify about inputs, and it correctly spends no words on parameters.

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 — check connectivity to DAR and report which access paths are configured — which is clearly a diagnostic/status operation distinct from the data-retrieval siblings (dar_get_address, dar_list_addresses, etc.). An agent can identify this as the health-check tool 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?

Gives explicit trigger conditions ('Use first when a DAR call fails unexpectedly') and a concrete decision use case, naming the sibling dar_search_addresses and the prerequisite (needs API key) that this tool answers. Both when-to-use and which-alternative-is-affected are spelled out.

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