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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description explains what it returns (municipality, county, official codes) but doesn't disclose edge-case behavior: what happens if the coordinate is outside Norway, if the address is ambiguous, if both address and coordinate are provided, or if neither is provided. Since it has no required parameters, an agent could call it with zero arguments and the behavior is undocumented. With no annotations and no output schema, this is a significant transparency 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?

Two sentences with no filler. The core purpose and required output (municipality, county, official codes) are stated first, and the input alternatives follow immediately. Every word earns its place.

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

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

With no annotations and no output schema, the description serves as the primary guide for the agent. It covers what the tool takes and what it returns, which is enough for a straightforward lookup. However, there are gaps: precedence between address and coordinate, behavior for missing/outside-Norway inputs, and whether the output includes names only or also codes (it says with official codes, so codes are clear). For a geospatial lookup with this sibling context, the description is adequate but not 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?

Schema description coverage is 100%, meaning all three parameters are documented in the schema itself: address, latitude, and longitude. The description adds the high-level relationship between them ('Give either a coordinate or a free-text address'), which is useful for disambiguation. However, it doesn't clarify precedence if both are given, nor does it specify expected address format beyond what the schema says. Baseline 3 is appropriate when the schema covers parameters fully.

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 states the tool's purpose: finding which municipality (kommune) and county (fylke) a location falls in, including official codes from Kartverket. It also distinguishes itself from siblings by specifying the exact resource (administrative units) and explicitly listing the two accepted input types (coordinate or free-text address). This makes it easy for an agent to differentiate from address search or geocoding tools like search_address or validate_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?

The description implies when to use it: when you need administrative unit membership or codes for a location. It explicitly states that either a coordinate or a free-text address can be given, providing usage flexibility. However, it doesn't explicitly say when NOT to use it or name alternative tools for similar lookups, though the sibling list and clear resource focus provide some differentiation.

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