find_facilities

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and scope. The description adds two behavioral details beyond those: it defaults to profile home area and travel radius, and it 'Sends only coarse coordinates' – a privacy-relevant disclosure. These add value over the annotations, but it doesn't describe return behavior or error cases. Given the annotations cover the primary safety profile, a 4 is appropriate.

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 first sentence front-loads the resource types, and the second covers defaults and privacy. Every word contributes to understanding the tool's scope and behavior. Excellent 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?

Despite having an output schema, the description leaves parameter usage largely unexplained. With 5 optional parameters and 0% schema coverage, the agent cannot determine how to filter by kinds, set limits, or interpret the radius. The description is too sparse for the tool's complexity, even though the output schema exists. It needs more detail on parameter semantics to be 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 0%, so the description must compensate for parameter explanations. It only vaguely references 'defaults to the profile home area and travel radius,' which hints at radius_m and lat/lon but does not explain kinds, limit, or the exact semantics of coordinates. An agent has no guidance on how to use the kinds enum or limit parameter. This is a significant gap for a 5-parameter 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?

The description clearly identifies the tool as listing fitness-related facilities from OpenStreetMap, enumerating specific types (gyms, sports centres, outdoor fitness stations, pools, tracks, parks). It distinguishes itself from siblings like find_sessions or find_meals by focusing on physical locations. The phrase 'from OpenStreetMap' gives a specific data source, making the purpose unambiguous.

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 states that it 'Defaults to the profile home area and travel radius,' which tells the agent when no coordinates are provided. It implies that providing lat/lon overrides defaults, but it does not explicitly say when to use this tool versus geocode or other siblings. It gives context but lacks explicit exclusions or alternative routing, so it earns a 4.

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