gbif_maps_get_tile_url

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so the bar is lower. The description usefully discloses the return artifact (tile URL strings) and the projection (EPSG:3857 Web Mercator), but says nothing about behavior at out-of-range coordinates, rate limits, or why a generic tool exists alongside the raster/vector variants.

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, front-loaded with the action, no filler. The second sentence partially restates what the srs parameter already documents, which is minor redundancy but keeps the size appropriate.

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 no output schema, the description does the right minimum of explaining that a tile URL is returned, which is adequate for a 12-parameter URL-builder. What is missing is the context an agent most needs: how this tool relates to its vector/raster siblings and the style-listing tool, leaving a real disambiguation hole.

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 100%, so the schema already carries the semantics for all 12 parameters; baseline 3 applies. The description only gestures at 'customizable styling and filters' and otherwise adds nothing, and its blanket claim that tiles come back in EPSG:3857 sits slightly awkwardly against the srs parameter that permits EPSG:4326.

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 names a specific verb and resource: 'Generate a URL for occurrence map tiles,' scoped by styling and filters. That is clear on its own, but the sibling list contains gbif_maps_get_vector_tile_url and gbif_maps_get_raster_tile_url, and the description makes no attempt to distinguish this generic tool from those two near-identical siblings, which is the main ambiguity an agent faces here.

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 only guidance is a downstream-consumer list ('web mapping applications, GIS software, or direct visualization'), which describes what the URL is for rather than when to call this tool instead of the raster/vector tile siblings. With three overlapping tile-URL tools available, the absence of an explicit when-to-use and when-not-to-use rule is a real gap.

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