swiss_geo_search_location

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 states what it searches but doesn't reveal any behavioral traits: no mention of whether results are scored/ranked, how many results are returned by default, whether it supports fuzzy matching, or whether it requires an API key. It's a fair baseline but omits behavioral details an agent would find useful. No contradiction with annotations since none exist.

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 efficient sentence that front-loads the core purpose. Zero wasted words. However, given the ambiguity around the 'types' parameter and the lack of usage guidance, a bit more content would have improved value without bloating it.

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 4 parameters, no output schema, no annotations, and 50% schema description coverage, the description is thin for the tool's actual complexity. The tool offers spatial references (sr), type filtering (types), and limits — none of which are explained in the description. Given the moderate parameter count and absence of output schema, the description should provide more context about how types and sr affect behavior.

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 50% (query and sr are documented in the schema). The description adds no additional parameter semantics beyond re-stating that it searches locations; it doesn't clarify the 'types' parameter (locations vs featuresearch) or how 'sr' affects output. The query examples in the schema ('Lausanne', 'Rue de Rive Genève', '1201') already cover query format. With 50% coverage, the description could compensate but doesn't add any param details, so 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?

The description clearly states the verb ('Search') and resource ('Swiss location'), enumerating the types of locations covered: cities, addresses, communes, postal codes, points of interest. It's specific about scope (Switzerland) but doesn't explicitly distinguish from sibling geo tools like swiss_geo_identify_canton or swiss_geo_find_layer_features, though the search functionality is fairly distinct from those.

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 general search usage ('Search for any Swiss location') but provides no explicit when-to-use vs when-not-to-use guidance. It doesn't mention alternatives like swiss_geo_identify_canton or swiss_postal_data, nor does it describe exclusions or prerequisites (e.g., needing an API key set via swiss_set_api_key). Usage context is implied but not explicitly guided.

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