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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it explains the distinct snippet formats, notes that Leaflet/OpenLayers use one load per map start, and clarifies that every 50 XYZ raster tiles count as one map load. It also reinforces that only a publishable key belongs in a page.

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 front-loaded with the core purpose and then lists output variants efficiently. The long first sentence is dense but each variant is relevant for choosing the right snippet; there is little fluff, though it could be broken up for readability.

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 heavy lifting by explaining what kinds of code snippets are returned and when each is appropriate. It also covers the publishable-key constraint and style pairing, leaving only the sibling-tool distinction (especially versus map_code) underdeveloped.

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 baseline is 3. The description adds some value by linking the style parameter to list_styles and emphasizing the publishable key constraint, but it does not add meaning for center, zoom, or other parameter details beyond what the schema already documents.

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 tool produces embeddable map code using a publishable key, and it enumerates the output variants (HTML, npm/SDK, framework components, Leaflet/OpenLayers, XYZ tile URL). However, it does not differentiate itself from the sibling map_code tool, leaving potential ambiguity about which code-generation tool to choose.

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 gives output-selection guidance ('Give the human the one that fits their site') and says to pair the snippet with a built-in look or published style from list_styles. But it does not explicitly state when to use this tool versus map_code or other siblings, nor does it provide exclusions or prerequisites.

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