swiss_geo_identify_municipality

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

No annotations are provided, so the description carries the full burden. It's a read-only lookup operation and the description implies this by describing an 'identify' action, but it doesn't state behavioral details like what coordinate system is expected (LV03/LV95 vs WGS84), what precision or boundary tolerance applies near municipal borders, or whether the input needs to be within Switzerland's bounds. For a geo lookup, coordinate system specification is a critical behavioral detail that's omitted.

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 a single, clear sentence with no wasted words. It's front-loaded with the primary action ('Identify which Swiss municipality'). One could argue it's slightly under-specified for a geo tool, but for what it contains, it's efficient and well-structured.

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?

This is a fairly simple tool: 2 parameters, no output schema, no nested objects. The description gives the core purpose. However, key context is missing: the expected coordinate system (critical for Swiss geo tools where LV95 differs from WGS84), behavior for out-of-country coordinates, and boundary handling. Given the tool's relative simplicity, the description is adequate but leaves important geo-specific gaps unfilled.

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 0%, so the description must compensate for the two parameters (lat, lng). The description mentions 'coordinate' which implies lat/lng are the input coordinate components, giving them some context. However, it doesn't specify the coordinate reference system (WGS84 vs Swiss LV95), which is a substantive semantic gap for geo tools. The baseline of 3 applies given the 0% coverage but the description adds only minimal parameter meaning.

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 has a specific verb+resource structure: 'Identify which Swiss municipality (commune) a coordinate belongs to.' It clearly states what the tool does (reverse geocoding a lat/lng coordinate to a municipality). It distinguishes from siblings like swiss_geo_identify_canton (which returns a canton, a different administrative level) and swiss_geo_search_location (which searches by name rather than coordinates), though it doesn't explicitly name these distinctions.

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 usage context (given a coordinate, find its municipality) and the sibling set shows related geo tools exist. However, there's no explicit when-to-use vs when-not-to-use guidance, no mention of how it differs from identify_canton or search_location, and no note about coordinate format requirements (e.g., WGS84 or LV95). The clear intent is somewhat implied by ambiguity with the coordinate system issue.

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