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

With no annotations supplied the description carries the full load, and it delivers real operating facts: the x402 micro-payment ($0.01 USDC per call), the OpenStreetMap/ODbL provenance, the hard result cap of 50, and the distance-from-centre ordering. It omits failure behavior for unresolvable cities and whether results outside radius_km are excluded or merely ranked, which keeps it short of a 5.

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?

One compact sentence that front-loads the capability, preceded by a short cost/latency-style banner. Nothing is redundant, though the pricing tag competes with the purpose statement for first position.

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?

For a simple three-parameter read lookup with a fully described schema, the description covers cost, data source, result cap and sort order. The main residual gap is error behavior for bad city strings and whether the radius filters or only bounds the search.

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 100% with per-parameter descriptions including ranges and defaults, so the baseline is 3. The description does add spatial meaning to radius_km and limit by tying results to distance from the city centre, but that is marginal on top of an already self-documenting schema.

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?

States the resource (mosques), the input mode (a named city, geocoded), the cap (up to 50) and ordering (by distance from city centre). That implicitly separates it from mosques_near, which presumably takes coordinates, but the sibling is never named, so the boundary has to be inferred.

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 parenthetical '(geocoded)' hints that this is the city-name entry point rather than a coordinate lookup, and the 'up to 50' cap hints at lightweight listing. There is no explicit when-to-use / when-not guidance, no mention of what happens if the city is unknown, and no pointer to mosques_near or halal_city as alternatives.

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