Aeralas Maps

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

With readOnlyHint/openWorldHint already covering safety and network access, the description adds the two traits annotations cannot express: no image is produced, and the call is free. Those are decisive for choosing among five siblings, three of which likely cost money or return pixels. It doesn't describe pagination or result volume, but that is minor here.

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 and its outputs, then the cost and routing hint. Every clause earns its place; the em-dash list enumerates concrete failure modes rather than padding.

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 must convey the return shape, and it does: a set of compromise warnings, an imagery-quality assessment, and an inventory of what was drawn. It omits that warnings echo the caller's annotation ids (only documented on the nested 'id' param), a small gap for a 15-param validation tool.

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% and the schema descriptions are unusually detailed (labelScale, offset, autoLabel, groundWidthM), so the structured data carries the parameter burden. The description adds no parameter-level meaning — it never hints that the same frame-addressing inputs as make_map are accepted, nor that dpi/center/address select the layout under test. 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 — lay out the map and report layout compromises (overlapping labels, truncated text, off-page annotations) plus imagery quality and drawn content. The line 'Returns no image' implicitly separates it from preview_map and 'iterate here before make_map' separates it from make_map, though it never names preview_map directly.

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 an explicit workflow rule: 'Free; iterate here before make_map,' which tells the agent to use this as the cheap validation step in a draft-refine-export sequence. It stops short of naming preview_map as the alternative when an actual image is wanted, so the exclusion is inferential rather than stated.

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 flag mutation/open-world/non-idempotent; the description goes far beyond by disclosing the $2.00 USDC price, the two-step x402 payment handshake, the success-only billing guarantee, and the 7-day revision window. These are exactly the behavioral facts an agent cannot recover from annotations or 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 sentences, zero filler, and front-loaded with the action before the payment mechanics and the revision offer. Each sentence delivers a distinct and necessary fact.

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 paid render tool with no output schema, the description covers the essential non-obvious context (cost, payment flow, billing condition) and states the return is a download link. It omits anything about render timing, failure modes, or the warning objects the schema references via annotation ids, which keeps it just short of complete.

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?

With 16 parameters and 75% schema description coverage, the schema carries nearly all parameter meaning; the description contributes no parameter-level detail (no dpi, format, frame, or annotation guidance). Baseline 3 is appropriate, as the schema does the heavy lifting.

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 immediately scopes it with 'print-resolution' plus a download-link return, which separates it from preview_map. It also names revise_map as the follow-on tool, so an agent can place it in the workflow without opening sibling schemas.

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 clear context: this is the paid, print-resolution render, and the x402 protocol spells out exactly when to call a second time. It routes to revise_map for revisions. It stops short of explicitly contrasting with preview_map or check_map, so the preview-vs-purchase decision is left to inference.

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 establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral value beyond that: output is a watermarked screen-size image, not the full-resolution paid render, and it costs nothing — useful for deciding whether to preview or export.

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 render/watermark/return fact and then the why and the cost. Nothing is padding.

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?

No output schema exists, and the description does cover that the return is an image, but it omits format/mime details. For a 15-parameter tool that mirrors make_map, the shared-request statement plus free/watermarked framing is nearly complete, with only minor return-format gaps.

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 nearly all 15 parameters. The one genuinely useful addition is that rendering happens at screen size, which implies the dpi parameter is not honored the way it is for make_map, but this is left to inference rather than stated.

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 (render), resource (the map), output form (image), and the distinguishing trait (PREVIEW watermark, screen size). It also explicitly relates itself to the sibling make_map by saying the request is identical, so an agent can tell preview from purchase at a glance.

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 clear context — see the layout before buying — and notes it is free and shares make_map's request shape. It does not explicitly say 'use make_map when you are ready to buy', so the alternatives routing is implied rather than stated.

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 readOnlyHint=false and openWorldHint=true; the description adds the substantive behaviors that matter — the free re-export window and the hard immutability constraint on address, center, groundWidthM, pageSize, orientation and dpi. It does not describe what a successful re-export returns, but the mutation semantics are well covered.

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 tight sentences with the verb and the free-window hook front-loaded, then the constraint. Every clause earns its place; no filler or restatement of the title.

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-object mutation tool with no output schema, the description carries the essential framing: the required mapId source and the immutability rule. Given the schema already documents the bulk of parameter detail, this is complete enough for correct invocation, though it says nothing about what the revision returns or whether it preserves the original.

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 already high (~75%), but the description adds meaning the schema cannot: it identifies precisely which parameters constitute the frozen 'frame' versus the mutable ones, so the agent knows that passing a new center or pageSize silently makes this a different map. That is real value beyond the per-field descriptions.

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 ('Re-export a map bought with make_map') and immediately scopes it against the purchasing sibling, so an agent can tell this apart from make_map or preview_map without opening a schema. The 'free for 7 days' qualifier further sharpens the purpose.

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 clear when-to-use context: only for an already-bought map, only within a 7-day window, and only when the frame is unchanged. It lists what may change versus what is frozen, which is exactly the decision an agent needs. It stops short of naming preview_map or make_map as explicit alternatives for adjacent cases.

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