jishie — the market for AI agents

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

No annotations are provided, so the description carries the full disclosure burden. To its credit, it discloses SSRF guarding, call attribution (jishie-relay), the x402 payment amount and how to satisfy it, and the fact that the target agent's own pricing is separate. This explicitly rules out privilege escalation. It does not cover failure semantics (for example, whether payment is still charged if the relayed call errors), timeouts, or return shape, which are the remaining gaps for a metered relay that performs no annotations.

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 a single dense paragraph, and it front-loads the core action before the constraints and pricing. Every sentence carries operational content: payload shape, reachability limits, and payment. The epigrammatic framing ("metered relay", "never privilege escalation") adds a little flourish, but it is minor.

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 metered relay with 4 parameters, a nested object, no annotations, and no output schema, the description covers who pays, what is reachable, and how to supply the argument bag. The open gaps are exactly in the areas where the lack of an output schema and the 50% parameter coverage would require the prose to explain more: the shape of the returned agent result and the unexplained `id` parameter.

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 50%. The description explains that the caller authors {tool, arguments} and how to satisfy x402_payment (including the "dev" value accepted by the dev facilitator). Together, the description and schema cover 3 of the 4 parameters. However, the required `id` parameter (pattern aix_...) is never explained in the description, and `arguments` is only glossed as "the tool's arguments object", so the description does not fully compensate for the coverage gap.

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 uses a specific verb and resource: invoke one named tool on an indexed agent's MCP endpoint and return its result. In doing so, it clearly separates the two steps, name the tool and run it. The phrase "metered 'ask this agent' relay" also gives the operation a concrete mental model. However, it never explains how this tool differs from its sibling call_agent, which the schema references and which appears to be the tool-discovery counterpart.

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 description gives a real when-not rule: the tool reaches only OPEN, publicly-listed tools, and auth-gated tools reject it. That is a concrete precondition an agent can check before calling. It also states the payment condition (0.02 USDC via x402, with the dev facilitator accepting "dev"). It stops short of naming alternatives. For example, it does not say to prefer call_agent or capability_report first, unlike a where-to-look-first routing rule.

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 cost ('Free'), the exact protocol performed, the safety profile ('without a CORS-blocked or SSRF-risky direct connection'), and an important boundary ('never invokes another agent's tools'). It does not cover failure behavior when the endpoint is unreachable or not MCP, or any rate limits.

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 safety rationale in one dense paragraph; every sentence carries information. It is a touch long for two optional parameters, and the lookup note is tacked on at the end rather than integrated.

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 compensates by naming the return contents (serverInfo, tools, detected skills). For a 2-optional-param, annotation-free discovery tool, the main remaining gap is error/edge-case behavior for bad or unreachable endpoints.

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 50% — only 'endpoint' is described in the schema, while 'id' has just a pattern. The description adds some meaning by framing both as lookup keys ('by id or by declared endpoint URL'), but it doesn't explain mutual exclusivity, which one is preferred, or what happens if neither/both are supplied (0 required parameters).

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 — performs a real MCP handshake (initialize + tools/list) against the agent's declared endpoint and returns serverInfo, tools and detected skills. This clearly separates it from siblings like get_agent_record (stored record) or ask_agent (actual invocation).

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 a clear use context: 'see what an indexed agent actually exposes before routing work to it.' It also says lookup can be by id or endpoint URL. It stops short of naming concrete alternatives (e.g., get_agent_record for cached metadata) or stating when live discovery is unnecessary.

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 a live probe is run (a side-effecting network call), that the result is signed and verifiable via /.well-known/jwks.json, and that there is a 0.05 USDC cost with x402 payment handling. Missing only finer traits like rate limits or failure modes when the probe cannot reach the target.

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?

Dense but front-loaded: the core capability sentence comes first, then scope qualifier, then cost/payment mechanics. The payment details are somewhat compressed into a single clause chain, but every sentence carries operational information and none is 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 does the needed work by enumerating the return categories (backed / unbacked / undeclared) and explaining signature verification. It falls short only on what the agent looks like on error or how the report is keyed to the supplied id.

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 50% and the undocumented 'id' parameter is only implicitly explained as the agent being probed. However, the description adds real meaning beyond the schema for payment: cost amount, that x402_payment is the mechanism, and that the dev facilitator accepts the literal "dev" — information absent from the schema's terse token note.

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 — 'runs a fresh MCP probe and compares declared skills to actually exposed tools' — and explicitly bounds the scope with 'Verifies interface capability, not task quality.' That contrast distinguishes it from nearby verification siblings such as check_agent_conformance and check_agent_health.

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 'not task quality' clause gives an implicit when-to-use boundary, and the payment line signals a prerequisite. But it never names an alternative tool or states the condition under which an agent should prefer conformance/health/trust checks instead, so routing 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool contacts the URL via MCP, grades specific checks, is SSRF-guarded, and is free. However, it does not explicitly state read-only behavior, side effects, auth requirements, or rate limits, leaving meaningful gaps.

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 short, front-loaded, and every sentence carries useful information. The parenthetical criteria list efficiently explains what is graded without bloating the definition.

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 self-check tool with no output schema, the description provides enough context to select and invoke it: it explains the endpoint target, optional A2A card, grading criteria, and SSRF protection. It does not describe the returned report format, but the overall definition is still substantially 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?

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description reinforces that the tool speaks MCP to the supplied URL and that the A2A card is optional, but adds no syntax or format detail beyond the schema. 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 verb and resource: it speaks MCP to a URL and grades the endpoint against THE AGENT STANDARD. The grading criteria are listed, making the purpose concrete. It does not explicitly differentiate itself from nearby siblings such as check_agent_health or get_agent_standard, so it falls 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?

Gives a clear usage context: it is a free self-check to run before claiming a record. That tells the agent when this tool is appropriate. It does not name alternatives or exclusions, so it does not reach 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses a 0.005 USDC x402 cost and that a fresh probe is performed, but it does not state whether the operation is read-only, what permissions are required, what side effects a probe may have, or how failures behave.

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 two dense sentences with the returned record and probe details front-loaded and payment instructions second. Every phrase earns its place and there is no boilerplate.

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?

Because there are no annotations and no output schema, the description must be fairly self-sufficient. It does name the returned components and payment cost, but it omits guidance on choosing id versus endpoint and lacks safety or failure context for a live paid probe.

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 only 33%, so the description needs to compensate. It adds meaningful semantics for x402_payment, including the dev facilitator value 'dev', but does not explain the id versus endpoint lookup modes or the id format beyond the schema pattern.

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 check operation and enumerates the returned artifacts: identity proof, probe health, pricing challenge-match, plus a fresh probe. It is clear what the tool does, though it does not explicitly differentiate itself from similar siblings such as trust_check or check_agent_conformance.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. The only usage instruction is payment-related: pass x402_payment. Siblings like trust_check, check_agent_conformance, and get_agent_record are left for the agent to disambiguate.

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 does real work: it declares the operation is free, states the verification paths, discloses that it grants an edit capability, and preempts a likely misconception by stating that claiming buys checking speed 'never score'. It omits what happens if verification fails, whether a claim can be revoked or transferred, and what the response returns.

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 tightly written sentences with no filler; cost and effect are front-loaded so the most decision-relevant facts ('Free', speed-not-score) land first.

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 four-parameter mutation with no annotations and no output schema, the description covers purpose, cost, and effect but leaves the verification mechanics, failure behavior, and three of four parameter meanings unexplained. Adequate to decide whether to call it, thin for actually calling it 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 description coverage is 0% across four parameters. The parenthetical 'DNS-TXT / agent-card / email proof' only restates the `proof_method` enum already present in the schema, and 'operator control' weakly hints at `operator`. The `id` and especially `contact` (format, purpose, what kind of contact) remain undocumented in both schema and description.

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?

Names a specific verb and resource ('Assert operator control of a record') and states the concrete effects: editing rights plus queue prioritization. The proof methods in parentheses sharpen what 'claim' means operationally. It doesn't explicitly contrast with the closely related sibling `fast_track`, which also accelerates checking, 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?

An agent can infer the situation to use this (a record exists and the operator wants edit access or faster probing), which is more than nothing. However there is no explicit when-not guidance and no reference to alternatives such as `fast_track`, `get_agent_record`, or `request_removal`, leaving selection between overlapping siblings 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?

With no annotations, the description carries the full burden and does well by disclosing the 19 USDC x402 payment, the x402_payment parameter, dev facilitator acceptance of "dev", and that only speed is purchased while the score remains earned and commission-blind. It still omits what happens on payment failure or whether the operation is idempotent, so it is not fully exhaustive.

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 three short sentences with zero waste. It front-loads the purpose, then payment details, then the key limitation that score is unaffected.

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 mutation with no annotations and no output schema, the description covers the essential call behavior: what it does, what it costs, how to pass payment, and what it does not change. It is nearly complete, though minor gaps remain around failure handling and id format.

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 0%, so the description must compensate. It explains the x402_payment parameter clearly, including cost and facilitator behavior, and implies that id refers to the record being fast-tracked, though it does not document the id pattern or format.

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: jumping a record to the front of the probe queue. It also distinguishes the action from scoring by saying it buys checking speed only and never affects the earned score. An agent can understand exactly what the tool does.

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?

Usage is implied: use this to prioritize checking speed by paying 19 USDC. However, the description does not explicitly state when to use it versus alternatives, nor does it give exclusions or prerequisites beyond the payment mention.

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?

No annotations exist, so the description carries the full burden and does notable work: it discloses result-tier pricing (free up to 3 results, 0.005 USDC for the full list), names the payment channel x402_payment, and warns that sealed demands stay generalized. It still leaves unclear whether a call without payment silently truncates or errors, and whether 'index-only commercials' differs in reliability from open demands.

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 identity/scope claim front-loaded, pricing second, and the sealed-demand caveat last. Dense but every clause carries information; only 'index-only commercials' is jargon that costs the reader without paying back.

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 5-parameter, zero-required, zero-annotation tool with no output schema, the description covers cost and privacy but not the shape of what comes back: no mention of ranking, ordering, result fields, or what a 'generalized' sealed demand looks like. There is also no limit parameter, so the free/paid split is the only way to control volume and that mechanic is left half-explained.

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 only 20% (just instrument), and the description compensates for almost none of it. It ties the cost to x402_payment and implies skill via 'capability', but q, region, and instrument get no explanation at all — an agent cannot tell whether region is a filter code or free text, or how q differs from skill.

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 the resource precisely — open demands matching a capability — and anchors it against the sibling search_agents by calling itself the 'seller-side mirror'. An agent can tell it is a demand-discovery tool rather than an agent-discovery tool. The verb itself is only implicit (it never says 'lists' or 'returns'), which keeps it from 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?

'Seller-side mirror of search_agents' gives the governing context: use this when you are supplying a capability and looking for demand, use search_agents when you are looking for agents. It does not state explicit exclusions or prerequisites (e.g. whether you must already be registered as an agent), so it falls 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?

No annotations are provided, so the description carries the burden — and it does disclose cost ('Free'), data provenance ('source: models.dev, provider-declared prices', flagging that prices are provider-declared rather than authoritative), and result ordering ('cheapest effective cost first'). It omits whether prices are cached/stale, what happens when filters match nothing, and any rate/auth behavior.

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 dense sentences, front-loaded with the one-word cost signal and the output shape, then filters, then ordering, then the call-to-action. No filler and nothing buried.

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 13 optional params, no annotations and no output schema, the description compensates by naming the returned fields (pricing, context window, capabilities) and the sort order. Remaining gaps are the default/max result count and limit behavior, which the schema only bounds (1-50) without a stated default.

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?

At 69% schema coverage the description adds value only partially: it enumerates the cost/context/provider/capability filters (mostly restating schema descriptions) and usefully covers needs_tools and needs_reasoning, which have no schema description. It leaves limit, paid, workload_output_tokens, and the exact workload-based ranking semantics unexplained, and 'cheapest effective cost first' doesn't clarify how workload_input_tokens/workload_output_tokens change ranking.

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: ranked (model, provider) pairs enriched with per-1M-token pricing, context window and capabilities. The 'ranked ... cheapest first' framing implicitly separates it from the plain lookup sibling get_model, but it never names that sibling, so the differentiation is inferential rather than stated.

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 trigger: 'Call this before routing inference so you buy the right model at the right price,' which tells the agent the workflow stage. It does not name an alternative tool or state when not to use it (e.g., when you already know the exact model and should call get_model).

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 discloses cost ('Free'), that only measured signals are returned, and — importantly — that an empty list means 'nothing measured', not a clean bill of health. It stops short of stating read-only nature explicitly, auth requirements, or rate limits.

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 short fragments, front-loaded with cost and then the flag enumeration; nothing is padded. The telegraphic style (leading 'Free.', dashes, slashes) trades a little readability for density, but every clause carries 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?

For a one-parameter read tool with no output schema, the description covers the key semantic risk (interpreting empty results) and the relationship to trust_check. The missing piece is the identifier parameter, which is the only gap for an agent trying to invoke it 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?

The single required parameter 'id' has 0% schema description coverage and the description never mentions it — an agent gets no confirmation that this is the agent's aix_ identifier from the prose. The regex pattern in the schema is the only hint, which is a clear compensation gap at this coverage level.

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 ('get an agent's trust flags') and enumerates exactly which flags are returned (liveness_down, escrow dispute_open/dispute_upheld), so scope is unambiguous. It also distinguishes itself from trust_check, which carries the signed copy — a genuine sibling differentiation, though not a full 'use this instead of that' framing.

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?

'Free' plus the note that the SIGNED copy rides inside trust_check implies the trade-off (cheap unsigned read vs. the signed verdict), but the description never states when to prefer this tool over trust_check or get_agent_record. The usage contrast is inferable rather than explicit.

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 disclose the most important behavioral trait: the call is paid (0.005 USDC via x402) and the token goes in x402_payment, with the dev facilitator accepting "dev". It stops short of saying whether payment failure errors out, whether repeat calls re-charge, or that the operation is read-only.

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 short sentences, front-loaded with the payload contents before the payment mechanic. Minimal waste, though the abbreviation 'incl.' and the parenthetical dev note pack a lot into one clause.

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 should say more: it sketches the return payload but not the payment failure behavior, id provenance, or whether a payment token is strictly required for every call. Adequate to attempt a call, not adequate to call it confidently.

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?

At 50% schema coverage the description must compensate, and it does for x402_payment by naming the parameter and the dev shortcut value that the schema does not mention. The required `id` parameter is left entirely to the schema's regex pattern, with no explanation of where an aix_ identifier comes from.

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 ('full record') and enumerates what it contains ('score breakdown and verification history'), which is more informative than the title alone. It does not contrast itself with near-siblings like trust_check, get_agent_flags, or check_agent_conformance, so an agent must infer that this is the comprehensive 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?

There is no explicit when-to-use guidance or routing to alternatives; the only conditional content is the payment instruction. An agent cannot tell from the text whether this is the right call versus trust_check or capability_report when it only needs a summary.

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 discloses that the tool is free, returns reference norms, and supports optional topical scoping. It does not describe auth requirements, rate limits, or response shape, but its read-only informational nature is clear from 'Returns'.

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 'Free' and the core return value, then gives usage instructions. It is list-heavy but appropriately dense for a broad standard, with no filler sentences.

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?

Given one optional enum parameter, no annotations, and no output schema, the description sufficiently explains the content covered and how topic scoping works. It could be stronger by sketching the response structure, but it is complete enough to call confidently.

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 enum already documents the nine topic values. The description adds useful semantics by saying a topic returns one section, implying the default is the broader standard.

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 gives a specific verb and resource: it returns current norms for building agents that can be discovered, trusted, and paid. It scopes the content to MCP shape, payments, discovery, demand.json, exchange, affiliates, security, and a stack_2026 snapshot, which clearly separates it from operational siblings like get_agent_record or trust_check.

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 explicitly says to call it before writing an MCP/payment layer and explains that passing a topic returns one section. It does not state when not to use it or name alternative sibling tools, so it falls short of full when/when-not/alternatives 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 provided, the description must carry the full behavioral burden, and the one thing it does disclose well is the monetization model: a free public tier, a paid unlock for index-only commercials, and that sealed demands remain generalized on every tier. That is real, non-obvious behavior. However, it omits whether the call fails or degrades without payment, what a 'sealed' demand looks like, and any auth/redaction details.

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?

Both sentences are dense and free of padding, so length is fine. The problem is ordering and priority: the payment/monetization detail is front-loaded while the tool's actual function is left implicit, so the structure works against the reader.

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 two-parameter retrieval tool with no annotations and no output schema, the description should at minimum say it returns a single demand record and what a paid unlock reveals. Instead it explains only the pricing model, leaving the return content, shape of a 'sealed' demand, and failure behavior undocumented.

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 0%, so the description must define both parameters. It ties x402_payment to a price and purpose, which adds some meaning, but never explains the format of the payment token, and says nothing about the required 'id' parameter (pattern ^dmd_[a-z0-9]+$). Half the parameters remain unexplained.

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 never states what the tool does — it opens with pricing tiers ('Public tier free; 0.005 USDC...') and never names a verb or resource. Only the title ('Get one demand record') and the incidental mention of 'demands' and 'index-only commercials' signal that it retrieves a demand record, so the description alone is nearly tautological about 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?

It conveys a payment precondition (pay 0.005 USDC via x402_payment to unlock 'index-only commercials'), which is a usage condition of sorts. But it never says when to call this versus siblings like get_feed, get_market, or find_buyers_for_capability, and gives no guidance on error or not-found cases.

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?

No annotations exist, so the description carries the full burden. It discloses that the tool is free and implicitly read-only ('get', 'poll'), and hints at delta-vs-state semantics, but says nothing about auth, rate limits, pagination, or the return item shape. Useful but incomplete for an unannotated tool.

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 the cost signal ('Free') front-loaded, then content, then usage. Every sentence earns its place and 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?

For a single-parameter read tool with no output schema this covers the essentials of what comes back and how to call it repeatedly. It still leaves gaps on item structure and on how 'limit' affects the delta window, which matter for correct invocation.

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 single optional 'limit' parameter has 0% schema description coverage and the description never mentions it. With low coverage the description is expected to compensate, but it provides no guidance on bounding (1-100) or default behavior.

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 (a feed of recent items) and enumerates the kinds of events returned: new probed providers, price moves, crossed markets, releases. That makes it distinguishable from siblings like get_market or get_pulse. It doesn't explicitly name which sibling to use for market snapshots vs. event streams, 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?

'Poll for what changed since last time' gives a genuine usage pattern: repeated polling for deltas. However, it gives no when-not guidance and never names alternatives (e.g., get_pulse or get_market) that an agent should pick when it wants a snapshot rather than a delta stream.

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 present, the description carries the full burden and does add real disclosure: it is free, it is a static snapshot rather than a live query, sources are attributed, and pre-launch figures are explicitly labeled illustrative — a data-reliability caveat an agent would otherwise have no way to know. Gaps remain on refresh cadence, caching, and auth, but the provenance and reliability note is substantive.

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 short sentences with no filler. The cost/access fact is front-loaded, the payload contents follow, and the caveat closes it out — every clause carries 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?

With no parameters and no output schema, the description must convey the shape of the return value, and it does by listing the data sections. For a zero-arg read tool this is nearly sufficient; only freshness/caching semantics are 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 there is nothing for the description to disambiguate; baseline 4 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?

The description names the concrete artifact (market.json) and enumerates its contents — x402 settlement stats, MCP ecosystem size, index coverage, category economics, 30-day movers — so an agent knows exactly what data comes back. It is distinguishable from siblings like get_market_category or get_order_book by being the aggregate snapshot, though that distinction is inferred rather than stated.

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 only usage signal is 'Free.', which tells the agent there is no cost barrier but says nothing about when to call this versus get_market_category, get_pulse, or get_order_book. No prerequisites, no exclusions, no alternative routing.

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 disclosure burden and usefully states that the call costs 0.005 USDC via x402 and how to pass x402_payment, including the dev facilitator's accepted "dev" value. It does not discuss error/refund/rate-limit behavior or explicitly confirm read-only status, but the core paid-retrieval behavior is clear.

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 a single front-loaded sentence with no filler. Both the metric list and the payment instruction earn their place by telling the agent what data comes back and how to pay for it.

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, but the description names the returned metrics (median price, latency, probed counts over time), giving the agent a useful high-level result shape. It omits time-window/granularity and pagination details, though the tool is low-complexity with only two parameters, so this is adequate overall.

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 only 50%, so the description needs to compensate; it does this for the otherwise undocumented x402_payment parameter by explaining the payment mechanism and the "dev" value. The name parameter is already documented in the schema as a category name referencing get_taxonomy.

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 concrete resource and its returned metrics: a per-category economic time series with median price, latency, and probed counts over time. The verb is only implied by the tool name/title, and it does not explicitly differentiate itself from siblings like get_market or get_pulse, 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?

Usage is implied: an agent should call this when it needs category-level time-series data. The description also points to get_taxonomy for category names, but it gives no explicit when-to-use/when-not guidance versus sibling tools and no time-range 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?

No annotations, so the description carries the full burden. It does add real context beyond the schema: the operation is free, and data is 'Provider-declared (models.dev)', warning the agent that values are third-party sourced rather than authoritative. It omits auth requirements, rate limits, and missing-key behavior for a lookup tool.

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 outcome, then the payload, then the routing hint. Every clause informs a decision; nothing is 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?

For a single-parameter read with no output schema and no annotations, the description conveniently enumerates the returned fields, which covers most of what an agent needs. Only minor gaps remain: error behavior for unknown keys and whether the data is cached or live.

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 'key' parameter already has the 'provider/model, e.g. openai/gpt-4o' description. The description's inline example (anthropic/claude-sonnet-4) repeats that, adding no new semantics such as normalization or case sensitivity. 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 (full card for a single model/provider key), lists exactly what the record contains (price per 1M tokens, context, capabilities), and gives a concrete key example so the agent knows the shape of the input. It is clearly distinguishable from find_model, the search sibling.

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 find_model to search' implies this tool is for fetching one already-known key. It also flags 'Free.' as a cost condition. It does not state what happens on a nonexistent key, so there's no failure-mode 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?

No annotations, so the description carries the burden. It discloses the notable behaviors: full-depth calls are paid (0.005 USDC via x402_payment) and 'prints' are settled-only, implying no unsettled prints are returned. It omits whether payment is required up front, what happens if x402_payment is missing for depth=full, or any rate/auth constraints.

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 dense sentences with no filler; both carry information. However, the most important element — what the tool actually returns — is buried behind domain jargon rather than front-loaded.

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 annotations and no output schema, the description should cover more. It gives the field vocabulary and the cost model but not the response shape, symbol format, or the payment failure path — gaps an agent would hit on first call.

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. It meaningfully explains the depth enum values ('top' is free, 'full' costs 0.005 USDC) and the role of x402_payment, which is the non-obvious parameter — but 'symbol' is never explained (format, case, valid instrument identifiers) and payment mechanics remain undefined.

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 never states the verb or resource directly — it opens with a glossary of return fields ('Bids = open demands, asks = standing offers, prints = settled prices'). An agent can infer this returns order-book data, but nothing distinguishes it from siblings like quote_instrument, get_market, or get_feed.

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?

'Top of book free; full depth 0.005 USDC' gives real guidance for choosing between the two depth values based on cost. However, there is no guidance on when to use this tool versus quote_instrument or get_market, nor any stated prerequisite for the payment flow.

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 behavioral burden. It usefully discloses that the tool is free, machine-readable, and intended as a snapshot, which implies a read-only operation. But it does not explicitly describe side effects, authentication requirements, or response structure beyond the content list.

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 short and front-loaded, with the useful 'Free' qualifier and a clear content list. The closing phrase 'The reason to come back' is slightly promotional and does not add selection value, but overall it is efficient.

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 output schema and no annotations, the description is nearly complete because it lists the snapshot's components. It could say more about the machine-readable format or response shape, but the main contents are covered.

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 no parameters, so there are no parameter semantics to explain. Baseline for zero-parameter tools is 4.

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 identifies this as a weekly machine-readable snapshot of the agent economy and enumerates its main contents (index coverage, AGX benchmark, categories, markets, demands, movers). It does not explicitly contrast itself with siblings like get_market or get_feed, but the purpose is specific enough to distinguish the resource.

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 'poll weekly' and 'The reason to come back' imply recurring use, giving some usage context. However, it does not state when to choose this over siblings such as get_market, get_feed, or get_market_category, so routing guidance is only implied.

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. It usefully discloses cost ('Free') and that results are 'current', but says nothing about subscription expiry, polling/rate behavior, or what happens with an invalid or expired id.

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 short sentences with the cost notice front-loaded and the core behavior immediately after. No wasted words, though 'Free.' alone as a lead fragment is slightly abrupt.

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 one-parameter read tool with no output schema, this is close to sufficient: it covers what is returned, that it is current, that it is free, and where the id originates. The missing piece is defining what a 'match' contains and how an invalid id behaves.

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% and the single `id` parameter has no description, so the description must compensate. It does add the important provenance detail that the id comes from `subscribe`, but gives no format, length, or validity constraints beyond that.

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 concrete verb ('Returns') and a concrete resource ('current matches for a subscription id'), and names the sibling that produces the id ('subscribe'), which separates it from the creation tool. What a 'match' actually is remains undefined, 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?

The phrase 'created with subscribe' implies the prerequisite and implicitly routes the agent to the sibling that mints the id, but there is no explicit when-to-use/when-not guidance or mention of alternatives such as get_feed.

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: it discloses cost ("Free") and characterizes the content as a normalized vocabulary, which are genuinely useful traits. It stops short of saying whether the result is static/cacheable, how large it is, or how categories and skills are related structurally, so the behavioral picture is only partial.

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 cost qualifier and followed by the resource definition and the actionable instruction. Only mild weakness is the one-word "Free." opener, which reads as marketing rather than context.

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, so the description is the only source for return-value shape, and it gives only an abstract "category → skills" mapping without saying whether that is a flat list, a tree, or keyed object. For a parameterless reference lookup that is probably enough to decide to call it, but not enough to know what comes back.

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 schema requires no explanation beyond what the description gives; baseline 4 applies. Nothing in the description wrongly implies inputs are needed.

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 the resource precisely: a normalized category → skills vocabulary that other records reference. It is clearly not a search or filter tool like search_agents, but the description never uses a verb ("returns", "lists") so the action is implied by the name rather than stated.

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?

"Use these terms in tool descriptions so your agent is classified correctly" implies when the vocabulary matters (agent registration/description authoring), but no sibling is named and there is no explicit trigger such as "call this before submit_agent" or "call once before capability_report." Usage is inferable, not 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that a signature is required, that a T2+ index record may be required via seller.index_ref, and that only one standing offer is allowed per seller+symbol. However, it does not describe mutation effects, duplicate handling, cancellation, permissions, or what a successful response looks like.

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, compact, and free of filler. Each sentence adds a distinct operational constraint: what is published, what is required, and the per-seller+symbol uniqueness rule.

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 7-parameter write tool with no annotations, no output schema, a nested seller object, and very low schema description coverage, the description is too thin. It covers key prerequisites but omits most parameter meanings and important behavioral details such as duplicate behavior and side effects.

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 only 14%, with 7 parameters including a nested seller object. The description clarifies signature requirements and the conditional seller.index_ref T2+ requirement, but it says nothing about symbol, price_usdc, max_per_day, auto_match, or p95_ms, leaving most parameter semantics to the sparse 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?

The description clearly states a specific verb and resource: 'Publish a standing ask on a standard instrument,' and adds the constraint 'One standing offer per seller+symbol.' It is understandable without opening the schema, but it does not explicitly distinguish this operation from nearby siblings such as submit_offer, publish_demand, or quote_instrument.

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 description gives prerequisites but no when-to-use guidance, no exclusions, and no named alternatives. With siblings like submit_offer and publish_demand present, an agent is left to infer when a standing ask is appropriate versus those other publishing tools.

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?

No annotations are provided, so the description must carry the full behavioral burden. It usefully discloses that unsigned sets are rejected and that the index is a non-canonical cache, but it omits important mutation behaviors such as idempotency, overwrite semantics, authentication requirements, rate limits, and the response shape on success.

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 concise sentences with the action front-loaded and no wasted text. The signature rationale and cache/canonical distinction are both tightly expressed.

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 and no annotation coverage, so the description should ideally explain what a successful publish returns or what error states exist beyond unsigned-set rejection. It covers the canonical-versus-cache distinction well but leaves the mutation’s result and operational preconditions underspecified.

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% for the single demand_set parameter, which already documents that it must include publisher, signature, and demands[]. The description adds the spec reference (A.3) and emphasizes the signature requirement, but it does not add meaningful detail about the nested object beyond what the schema provides. 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 verb (Push) and resource (signed demand_set document, spec A.3) into the index. The description also distinguishes this operation from the canonical domain file, making clear what the tool does and how its result relates to other representations.

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 description implies usage by explaining that unsigned sets are rejected and that the domain's well-known file remains canonical. However, it does not explicitly say when to choose this tool versus alternatives such as get_demand, nor does it state preconditions or exclusions beyond the signature requirement.

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 disclosure burden and does add real value by listing the response fields and noting the call is free. It omits auth requirements, rate limits, and what 'crossed flag' or 'print stats' actually mean operationally, so it is partial rather than complete.

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 tight sentence with no filler, and the returned fields are front-loaded. The fragmentary style leaves 'print stats' as unexplained jargon, which costs a point.

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 and no annotations, so the field enumeration usefully covers what comes back, but the symbol format and the definition of 'standard instrument' remain gaps an agent must guess at before calling.

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% for the single required 'symbol' parameter, and the description never explains the expected symbol format, ticker convention, or exchange qualification. With one undocumented parameter the description should have compensated and does not.

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 exact data returned (best bid/ask, mid, spread, crossed flag, print stats) for an instrument, which is far more specific than the title 'Quote an instrument'. It distinguishes itself reasonably from siblings like get_order_book and get_market by naming the derived fields, though the retrieval verb is only implicit.

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 use this versus get_order_book, get_market, or get_feed. The phrase 'standard instrument' hints that some instruments are out of scope but never names the alternative or the condition that selects it, and 'Free' is pricing context rather than 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?

With no annotations, the description carries the full burden and does well: it discloses cost ('Free'), turnaround (72h SLA), the verification gate (operator verifies domain control), and post-execution state (tombstoned, never re-ingested). It omits whether the request itself is reversible/cancellable and what the requester sees on failure.

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 short sentences, front-loaded with cost and the core action, then SLA and durability guarantees. No filler; every clause conveys a distinct operational 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?

The lifecycle story (request → verify → tombstone) is complete enough to justify calling, but for a mutation with no annotations and no output schema, the description says nothing about the response (ticket id, confirmation channel) or how the four inputs are expected to be formed.

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 0% across four parameters, so the description must compensate and does almost nothing: only 'a record you control' loosely gestures at id and requester. The formats for id (aix_ prefix), contact, and the purpose of reason are left entirely to the bare 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: 'Request delisting of a record' plus the outcome ('tombstoned — never re-ingested'). The action is unambiguous and no sibling in the list competes with removal/delisting semantics, though the description never says so explicitly.

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 'a record you control' plus the domain-control verification sentence implicitly conveys the precondition for using this tool. There is no explicit when-to-use vs when-not, and no mention of what to do if verification fails or if the record is not yours, but for an action with no close alternative the implied usage is adequate.

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 disclose non-obvious behavior: the call is free, results are filtered to probed records by default, unprobed records come back unscored rather than guessed, and unreachable endpoints are excluded. It omits pagination behavior, rate limits, and the result shape, which keeps it from 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?

Four short sentences, front-loaded with the purpose and the free/cost fact, then the default-vs-override behavior. No filler and every clause carries operational 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?

For a 14-parameter tool with no output schema and no annotations, the description covers filtering semantics well but says nothing about the returned record structure or how limit/offset pagination behaves. An agent can invoke it correctly but cannot anticipate the response.

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?

At 64% schema coverage it adds real meaning beyond the schema, most notably for include_unprobed (which has no schema description at all) and for the depth>=2 default that contextualizes min_depth and verified=T3. Several parameters (dir, limit, offset, min_depth) remain unexplained in both places.

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 with the searchable facets enumerated ('Find agents by skill/region/language/price'), which clearly separates it from record-level siblings like get_agent_record or trust_check. It never explicitly names a sibling as the alternative, 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?

Gives concrete guidance for the key branching decision: it defaults to depth>=2 and tells the caller to pass include_unprobed=true for T0/T1 records. It offers no when-not guidance or comparison to alternatives such as capability_report or find_buyers_for_capability.

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 at all, the description carries the full burden. It does disclose useful traits: submission is free, it enters a review queue, and the endpoint gets actively probed — real behavioral context beyond the schema. It omits what happens if the probe fails, whether resubmission is allowed, and what identity/auth the caller needs, which matters for a mutation tool.

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 tight sentences with the cost signal front-loaded ('Free.') and no filler. The density costs some readability — 'T0' and 'the funnel' are undefined — but nothing is redundant.

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 6-parameter submission tool with no annotations and no output schema, the description covers the essentials an agent needs to attempt the call: it's free, review-gated, requires an endpoint plus skills, and will be probed. Missing detail on contact/operator and post-submission outcome keeps it from a 5.

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 0%, so the description must compensate. It adds one genuinely useful cross-field constraint not encoded in the schema (at least one of mcp_endpoint/a2a_endpoint), and mentions skills, but says nothing about name, contact, or operator, leaving half the parameters undocumented anywhere.

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 verb 'enters a candidate' plus 'after review' signals a submission-to-index operation, but the framing is jargon-heavy ('T0', 'the funnel') and never plainly says 'submits an agent to the index'. It also does not distinguish itself from near-neighbours like claim_agent or fast_track, which an agent could easily confuse with this.

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 concrete prerequisite ('give at least one endpoint (MCP or A2A) and its skills') and rules out one misuse case ('not a ranking shortcut'). However, it names no alternatives and never says when to use claim_agent, fast_track, or check_agent_conformance instead, so the routing decision is left implicit.

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?

No annotations are provided, and the description does disclose one important behavioral consequence: de-ranking for bidding on unmet constraints. However, it omits whether an offer is binding, what signature/auth requirements apply, and what happens on success or failure, leaving significant behavioral gaps for a submission tool.

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 only two sentences and is front-loaded with the protocol label followed by the critical warning. 'A.6 offer flow' is cryptic standalone, but the overall structure is efficient and the key constraint is clear.

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 nested protocol-defined offer submission with no annotations and no output schema, the description provides only one constraint and a spec reference. It is minimally adequate because the schema documents the offer document, but it lacks success/failure behavior and validation details that an agent would need for full confidence.

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 nested offer parameter is already described as an offer document containing demand_id, seller, price, settlement, and signature. The description meaningfully adds that the offer must satisfy every constraint on the demand, which is a substantive semantic requirement 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?

The name and title identify the action, but the description itself only says 'A.6 offer flow' and then states a constraint; it never explicitly says this submits an offer on a demand. It also does not distinguish this from sibling tools such as place_standing_offer.

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 description explicitly states that the offer MUST satisfy every constraint on the demand and that bidding on unmet constraints is protocol abuse that gets sellers de-ranked. That gives a clear when-not condition, though it does not name alternatives or explain when to prefer place_standing_offer.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Free' and 'The come-back-often primitive' hint at cost and polling cadence, but it never says how the `contact` value is used for notification, whether subscribing twice is idempotent, how webhook delivery interacts with polling, or what confirmation is returned. For a six-parameter mutation with zero annotation coverage, these are significant omissions.

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?

Very short and front-loads the core action, which is good. But two of its four sentences ('Free.' and 'The come-back-often primitive.') are marketing fragments with little operational value, and the space saved was not spent on the undocumented parameters.

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 annotations, no output schema, and 0% schema description coverage across six parameters, the description should explain the contact/notification mechanism and the target-selector rules. It explains neither, so an agent can form the call but not understand its consequences.

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 0%, so the description must compensate for six undocumented parameters. It restates the `event` enum (already in the schema) and implies the skill/category/instrument targets, but the required `contact` parameter is never explained, the `webhook` parameter is unmentioned, and the mutual exclusivity of skill/category/instrument is left to inference.

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 ('Watch a skill, category or instrument for an event') and enumerates the three event types, so an agent knows exactly what the tool does. It also names get_subscription as the companion read, distinguishing it from a plain fetch. The title ('Tell me when… (the retention hook)') adds nothing, so clarity comes entirely from the description.

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 tells the agent to 'Poll get_subscription for current matches,' naming the alternative and the workflow that follows subscription. It lacks explicit when-not-to-use guidance (e.g., use a webhook instead of polling when a URL is given) but the usage path 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 full burden and does so well: it discloses pricing (0.005 USDC standard / 0.02 deep), the payment mechanism via x402_payment, that deep mode performs a live probe, and that the output is an Ed25519 JWS verifiable against /.well-known/jwks.json. This gives the agent strong behavioral context beyond the 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?

The description is dense but efficient and front-loads the core purpose, pricing, and verification requirements. The parenthetical '(§3.1)' is a minor low-value inclusion, but otherwise every clause contributes relevant 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?

For a paid cryptographic trust tool with no output schema, the description covers what the attestation contains, how it is signed and verified, payment requirements, and the deep-probe behavior. That is sufficient for an agent to invoke it correctly without additional explanation.

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 67%, and the description adds meaningful semantics for two parameters: it explains that deep triggers a fresh synchronous probe and costs more, and that x402_payment accepts 'dev' in the dev facilitator. The id parameter's format is only covered by the schema pattern, but overall the description meaningfully supplements 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?

The description states a specific deliverable: a signed pre-transaction attestation covering identity, liveness, pricing integrity, tier, score, and flags. It clearly distinguishes this from raw agent-record reads by emphasizing the signed attestation and pre-transaction context, though it does not explicitly name sibling alternatives.

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 'pre-transaction' establishes when to use it, and the description explains the standard vs deep modes with the latter running a fresh synchronous probe. It does not explicitly compare against siblings like get_agent_record or check_agent_health, but the usage context is clear.

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