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

No annotations are provided, so the description carries the burden. It discloses the sorting (most famous first), the distance field (distance_km), and the radius default (50 km, max 500). It does not mention rate limits, authentication, or what happens with invalid coordinates, but for a read-only list tool this is acceptable. It does not contradict any annotations (none present).

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 two sentences: a clear functional statement with sorting and output details, followed by the default/limit and a direct instruction to geocode first. Every sentence adds value, and it is front-loaded with the primary action.

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 straightforward proximity query tool with no output schema, but the description covers the key output (distance_km), sorting (most famous first), and constraints (radius bounds and default). Given the low complexity and no nested objects, the description is complete for an agent to select and invoke 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 60% (limit and radius_km have descriptions, but latitude/longitude and category do not). The description adds context beyond the schema: it explains that the radius is in km, default 50, and mentions the distance_km field. It also mentions the famous-first ordering which relates to the limit. It compensates for missing schema descriptions for lat/long by explaining they are WGS84 coordinates. Category is listed but not explained fully—though the schema includes an inline list of allowed values, rendering the description's mention adequate.

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 specifies a concrete action: 'List filming locations within a radius of a WGS84 coordinate, most famous first, each with distance_km'. It clearly identifies the resource (filming locations) and the distinguishing behavior (proximity search with distance output), which sets it apart from siblings like 'search_locations' and 'what_was_filmed_here' by emphasizing the proximity and radius concept.

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?

It states a clear use case: 'the direct answer to "what was filmed near me?" and to set-jetting itineraries' and provides a prerequisite: 'Geocode the place yourself, then call this with its latitude and longitude.' It lacks explicit guidance on when NOT to use it or which sibling to use instead, but the context is sufficient for typical use.

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