Agent World

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

With no annotations, the description carries the burden and does disclose the critical behavioral trait: it is a paid call (0.0050 USDC on Base mainnet via x402), plus the output scope shrinkage under lite:true and the 30-minute snapshot cadence. It omits failure modes, latency/timeout expectations, and retry behavior for the payment flow.

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 value is front-loaded ('The x402 agent economy in one call') and the differentiating sentence plus payment note land before the parenthetical detail. It is a single dense sentence whose embedded statistics (28K+, 1886 hosts, 24h/7d/30d) are informative rather than padding, though the length is at the upper end.

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 and no annotations, the description must carry the full load, and it enumerates the returned data sets, the lite-mode variant, the snapshot cadence, and the payment requirement. Nothing an agent needs to decide to call it or to interpret the response 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% and there is only one optional boolean, so the schema already fully documents 'lite'. The description's 'Set lite:true for market vitals + top 5 merchants' largely restates the schema's own wording rather than adding new semantics, landing at the baseline 3.

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 scope ('in one call') plus the exact resource set: PayAI Bazaar market vitals, top-20 merchants, trend history, and catalog position. It also explicitly differentiates itself from every sibling by stating it is 'the only tool on this server about the MARKET rather than about your endpoint.' An agent can distinguish it from world_status, world_catalog, etc. 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?

It gives a clear condition for the market-data use case and contrasts against the server's endpoint-scoped siblings, plus a concrete lightweight-mode instruction ('Set lite:true for market vitals + top 5 merchants'). It does not name specific alternative siblings or state when NOT to use it, so it stops short of full routing 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?

With no annotations, the description carries the burden and does well: it declares the catalog is free, that it is generated live from the gateway's OpenAPI so it 'never drifts,' that it is the $0 PayAI Bazaar listing, and it names the pricing unit (USDC on Base mainnet). It does not spell out whether results are paginated or the exact response shape, keeping it just short of a 5.

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?

Front-loaded with 'FREE catalog' and the core purpose, and the trailing product enumeration earns its place by telling the agent exactly what can be discovered. The list of eleven product names is dense and mildly bloats the sentence, but 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 tool with no annotations and no output schema, the description fully covers what is returned (URL, USDC price on Base mainnet, one-line description), freshness guarantees, and the cost model. Nothing an agent needs to call it correctly 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?

The tool takes zero parameters, so the baseline is 4. The description instead clarifies what each entry contains (public URL, USDC price, one-line description), which is informative but not parameter semantics.

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+resource: it is a catalog listing every paid x402 data product plus LLM inference. It enumerates the products and clearly distinguishes itself from siblings like world_digest or world_sentinel, which are themselves entries in this catalog.

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?

Explicitly routes the agent: 'Use it to discover what is available before paying for a specific tool,' which implicitly names the paid siblings as the alternative path. There is no stated when-not condition, but the discovery-before-purchase context is clear.

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?

With no annotations, the description carries the burden well: it discloses that the operation is free, read-only against a public endpoint, produces an EIP-191-signed report verifiable "in two lines," and is backed by the same engine as the public /x402/doctor route. It omits operational traits such as rate limits, timeouts, or behavior on unreachable targets.

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?

One dense paragraph that front-loads the value proposition and check list before the use case. Some clauses are promotional filler ("the world's doctor," "verify in two lines"), and the trailing "[free]" duplicates the opening "FREE," but nothing is structurally confusing.

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 and no annotations, the description supplies most of what is needed: the score range, the 13 check categories, and the signed-report output form. The only real omission is any mention of how this differs from the fleet sibling or what happens when the target is unreachable.

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% and the single `target` parameter is fully documented as a public http(s) origin or URL. The description adds no syntax or format detail beyond that, so this is the baseline-3 case where 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?

The description names the resource (x402 conformance) and the action (scores an endpoint 0-100 across 13 enumerated checks), with concrete specifics like 402 challenge decodability, CORS and resource.url. It is unmistakably a per-endpoint diagnostic, but it never distinguishes itself from the sibling world_doctor_fleet, which appears to be the multi-endpoint variant.

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 buyer-side safety check before wiring a client to an x402 merchant" gives an explicit situation for use. It stops short of stating when not to use it or routing to the fleet/knock/sentinel siblings, so it is clear context without exclusions.

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?

With no annotations, the description carries the full burden and does well: it discloses the price (0.005 USDC on Base mainnet via x402), the payment rail, the batch ceiling, the exemption from the free 5/hour limit, and the shape of the returned report and fleet summary. It stops short of describing failure modes for malformed origins or what happens if fewer than 10 valid origins are supplied.

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?

Front-loaded with the core action and scope, then supporting details on output, cost, and use case. Dense but every clause carries information; the trailing bracketed payment restatement is mildly redundant with the earlier pricing sentence.

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?

There is no output schema, yet the description enumerates the returns (13 checks, signed 0-100 score, fleet summary with by-verdict counts, average, worst offender) and supplies cost and payment context. An agent has everything required to decide and invoke correctly.

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% and the single parameter is fully documented there, so the baseline is 3. The description reinforces the 1-10 batch bound but adds no syntax detail (e.g., separator handling, scheme normalization) beyond the schema.

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 — 'Batch x402 conformance audit' — with concrete scope (up to 10 origins in one call) and enumerates what each report contains. It also distinguishes itself from the sibling world_doctor by noting it is 'One call instead of ten' and exempt from the free /doctor rate limit.

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 use case: 'For vetting a batch of x402 merchants before wiring a client to any of them.' It also implicitly contrasts with the single-origin /doctor tool via the rate-limit note, though it never states when to prefer world_doctor over this tool outright.

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?

With no annotations the description carries the full load and does so well: monitoring cadence (~30 min), Ed25519-signed alerts to buyer webhooks on state change, registration cost (0.002 USDC on Base mainnet, up to 24h), and the no-watch fallback. It omits rate limits and any explicit statement of the read-only nature, but the behavioral picture is rich.

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?

Front-loads the free status and its return shape before the paid-registration aside, which is relevant because of the registration-pointer fallback. The single sentence is dense and crammed with clauses, but each element carries signal; it is slightly overstuffed rather than wasteful.

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 and no annotations, the description supplies the return fields, the monitoring behavior, and the fallback, so an agent can call and interpret it correctly. Only minor gaps remain (exact pagination/rate behavior, explicit read-only framing).

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 single 'url' parameter is already fully documented; the description only restates 'on the given URL' without adding syntax or format detail. The callback mention belongs to the separate registration endpoint, not this tool's parameter, which adds mild rather than clarifying value. Baseline 3 is 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?

States a specific resource and scope: 'latest state of any ACTIVE continuous-monitoring watch on the given URL', with the concrete return shape (verdict up/degraded/down, last check, checks count, expiry). This is clearly distinguishable from siblings like world_knock, world_sentinel, and world_status.

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?

Explains the use context (look up an active watch on a URL) and the fallback behavior ('if no watch is active you get a registration pointer'), and points to the registration endpoint for the paid path. It does not explicitly name sibling alternatives to contrast against, so it stops short of a full when/when-not guide.

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