Aeralas Maps

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

Annotations declare readOnlyHint and openWorldHint but say nothing about cost, output medium, or diagnostic content; the description adds all three — free, no image returned, and a specific list of what the report contains. It does not describe what happens on a failed layout or whether warnings are per-annotation keyed, which it could since there is no output schema.

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?

Three short sentences, front-loaded with the action and its output, no filler. Each sentence carries a distinct fact: what it reports, that there is no image, and that it is free to repeat before make_map.

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 15 parameters and nested objects, no output schema, and this being the pre-commit validation step, the description covers what an agent needs to decide and call: cost, output medium, diagnostic payload, and the ordering relative to make_map.

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 80% across 15 parameters, so the schema does the heavy lifting and the baseline of 3 applies. The description adds nothing parameter-specific — it never mentions mapId, dpi, autoLabel or annotations, so the agent must read the schema to learn that visuals can be supplied for dry-run evaluation.

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?

A concrete verb and resource ('lay out the map and report what it had to compromise on') plus an explicit enumeration of what is checked: overlapping labels, truncated text, off-page annotations, imagery quality, what was drawn. 'Returns no image' and 'iterate here before make_map' separate it cleanly from the render sibling before either schema is opened.

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 the workflow position unambiguously ('iterate here before make_map') and gives a use case (editing drafted labels). It falls short of naming preview_map, the sibling whose territory most overlaps, so the agent must infer the difference between a no-image check and an image preview from 'Returns no image' alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral value by disclosing the two possible outcomes, including the non-error 'still awaiting payment' state that an agent might otherwise misread. It omits how long payment confirmation takes to propagate or any handling of invalid ids.

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 precondition and followed by the result states, with no restated title or filler.

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 still tells the agent what comes back (download link, mapId, or awaiting-payment status), and the single parameter is fully covered by both schema and prose. Nothing essential for a correct call is missing.

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%, so the parameter is already documented as the id make_map returned; the description goes beyond that by establishing provenance (returned when x402 payment failed) and the timing condition for supplying it (after user confirmation).

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 action (look up an order by id) and a specific outcome (download link plus mapId for revisions), and it explicitly ties itself to make_map's x402-failure path, which separates it from siblings like check_map or revise_map.

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 a precise trigger: call with the order id only after the user says they have paid, and explains that make_map is where the id comes from. It does not explicitly state the negative case (do not call before payment, or what to do if the id is unknown), which keeps it just short of a 5.

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

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 by structured data. The description adds two useful bits of context beyond that — that the call costs nothing ('Free.') and that a payment path (x402) is described rather than executed — but says nothing about output format or size, keeping it at a solid middle score.

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?

A single front-loaded sentence lists the covered topics efficiently, with the cost note isolated as 'Free.' The list runs on somewhat without connectives, but every clause carries distinct information and nothing is wasted.

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 zero-parameter, read-only info tool with annotations supplying the safety profile and no output schema to explain, the description covers content, pricing, payment method, and purchase path. It is nearly complete, only missing a note that no map artifacts are produced or returned.

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?

The schema has zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the description misleads about inputs.

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 enumerates the specific informational payload (map contents, price, imagery coverage/quality, x402 payment, direct purchase), which makes it clear this is a read-only 'about the service' endpoint rather than an action tool. It lacks an explicit verb ('returns'/'describes') and never contrasts itself with the sibling action tools, so it stops short of a 5.

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?

There is no statement of when to call this versus check_map/make_map/preview_map/revise_map, nor any prerequisite or sequencing guidance. The trailing 'Free.' hints there is no cost barrier but does not constitute usage guidance.

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

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

Annotations only say it is not read-only, is open-world and non-idempotent. The description goes well beyond that by disclosing the $1 USDC price, the exact two-step payment handshake (requirements returned on first call, then sign and re-call), and success-only billing — critical facts no structured field carries.

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?

Three short sentences, each earning its place: what it returns, what it costs and how payment works, and where revisions belong. Front-loaded with the outcome and download link.

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?

Covers the highest-stakes unknowns for a paid, 16-parameter render tool: price, payment flow, billing on failure, and the free-revision escape hatch. It omits two useful details an agent would otherwise infer from the schema only — that X-Map-Id comes back on a paid export, and that address or center must supply the frame.

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 75% and the nested annotation object is documented in detail, so the schema is doing the heavy lifting. The description adds nothing about any of the 16 parameters, not even the dpi/pageSize tradeoffs implied by 'print-resolution'. Baseline 3 applies.

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 a specific verb and resource ('Render the print-resolution map and return a download link') and implicitly separates itself from preview_map by the word 'print-resolution'. It also names revise_map as the follow-on path, so an agent can place it among its siblings without opening any schema.

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?

Gives strong operational context: the x402 two-call payment flow, that the charge only lands on a successful render, and that revisions go through revise_map. It stops short of an explicit 'call preview_map first to iterate for free' exclusion, which is the most likely routing question an agent will have.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds meaningful behavior: watermarked output, screen-size rendering, image return, and free cost. It does not disclose rate limits or persistence details, but with annotations present the bar is lower.

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?

Three short sentences with zero waste, front-loading the core action, output, watermark, use case, and free/paid distinction.

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 complex 15-parameter tool with no output schema, the description adequately covers what is returned (an image), the preview limitation (watermark), and how it relates to make_map. The remaining detail is carried by the rich schema and sibling relationship.

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 80%, so the schema already documents most parameters. The description adds no parameter-specific meaning beyond 'Same request as make_map,' making the baseline score of 3 appropriate.

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 states a specific verb and resource: render the map at screen size with a PREVIEW watermark and return it as an image. It also distinguishes the free preview from the paid sibling by saying 'Same request as make_map. Free.'

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 phrase 'so the user can see the layout before buying' gives a clear when-to-use context, and 'Same request as make_map. Free.' implies the preview precedes a paid make_map call. It does not explicitly name exclusions or route to check_map/revise_map, so it falls short of 5.

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

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

The annotations already mark this as a non-read-only, open-world operation. The description adds useful behavioral context: the 7-day free re-export window, the requirement for a make_map-returned mapId, and the crucial rule that frame parameters are immutable while labels, annotations, styling, overlays, and page elements can change.

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 action and free-window condition, then immediately gives the frame constraint and mapId requirement. Every sentence earns its place, with no repetition of schema details.

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 16-parameter nested tool, the description supplies the key behavioral and invocation constraints, and the rich schema covers most parameter details. It does not mention previewing or checking a map first, but that is a minor gap given the available schema and annotations.

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 75%, so the schema already documents most parameters. The description adds cross-parameter meaning by grouping address, center, groundWidthM, pageSize, orientation, and dpi as the immutable frame, while identifying labels, annotations, styling, overlays, and page elements as editable.

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 states a specific verb and resource: re-export a map bought with make_map, free for 7 days. It distinguishes this from make_map by specifying that it operates on an existing mapId rather than creating a new map.

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 clearly says when this tool applies: re-exporting a previously bought map within the free 7-day window. The frame-immutability rule also implies that changing the frame requires make_map instead, though it does not explicitly name preview_map or check_map as alternatives.

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