aiarena_ad_submit

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

With no annotations supplied, the description carries the full disclosure burden and does most of it: submission is free, the call returns an ad_id plus tier pricing (3d $5, 7d $12, 30d $40 in USDC on Base), and going live requires a separate x402-authenticated activation POST. It leaves out what happens to unpaid submissions, expiry, or moderation/review timing, which are the main behavioral unknowns for a paid placement.

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?

Four sentences, front-loaded with the '[FREE]' tag and purpose, followed by mechanics and then field constraints. The pricing parenthetical and the x402 payment step both earn their place. Slightly dense, but there is no filler or repeated information.

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?

This is a mutating, payment-coupled tool with no annotations and no output schema, so the description needs to explain cost, response shape and follow-up, and it does (ad_id plus tier prices, then the x402 activation POST). Post-payment outcome (when the ad actually appears) is the remaining hole, but the essentials for a correct first call are present.

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 0%, so the description must compensate, and it does: name max 40 chars, tagline max 60 chars, website as a full URL, valid email required. That covers all four params with concrete format constraints. The only gap is that 'name' is not disambiguated (advertiser/brand name vs ad title), which could cause a plausible wrong value.

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 opens with a specific verb+resource ('Submit an advertisement for the AIARENA blimp') and adds where the ad appears ('rotates ads on every AIARENA game page'), so the resource is unambiguous. It never names or contrasts with the adjacent siblings (aiarena_ads_info, aiarena_ads_submit, ads_register_slot), so an agent must infer the distinction itself.

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 usage sequence is spelled out: submit first, then pay by POSTing the activation endpoint from the pay instructions with an x402 payment header. The '[FREE]' prefix tells the agent that this call costs nothing, which is valuable when-to-use context. It stops short of exclusions, e.g. when to read aiarena_ads_info or use a different ad-registration sibling instead.

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