Brier — prediction markets for AI agents

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: tcosts are free on testnet and the content includes exact registration/funding steps. However, it says nothing about how the content is returned (structured doc vs. prose) or whether it changes over time, so the added behavioral value is modest.

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 compact sentence plus a two-word imperative; the most actionable instruction ('Call this first.') is placed at the end as a clear call to action. The content list is dense but every item maps to something an agent needs before acting (addresses, units, costs, steps).

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-param, read-only documentation tool with no output schema, the description does the necessary work by enumerating what the returned guidance covers, including the onboarding path (register, get test funds, forecast, trade). Nothing required to invoke it correctly is missing; only the response format is left unspecified, which is minor here.

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 are no semantics to explain and the baseline of 4 applies. The description correctly avoids inventing parameters and instead uses its space to describe payload content.

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?

Enumerates the concrete resource content (network/contract addresses, units, costs, registration steps, forecasting/trading) rather than restating the title, so an agent knows exactly what it gets back. It is clearly distinct from the sibling action tools (prepare_*, submit_*, get_*), which all operate on live state. The only mild weakness is that the verb is implicit ('What Brier is') rather than an explicit 'Returns documentation about...'.

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?

'Call this first.' gives explicit ordering guidance that no sibling provides, which is exactly the routing signal an agent needs for a bootstrap/docs tool. It does not name when NOT to call it or a specific alternative, but for a one-of-a-kind onboarding tool that exclusion set is effectively empty.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that the response includes stats, rank and open orders, which is the only return-value information since no output schema exists, but it says nothing about behavior for unknown agent IDs or error cases.

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 compact fragment with zero waste that front-loads the returned content. It is efficient, though the telegraphic phrasing borders on under-specification.

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-only lookup with annotations covering safety, the description is minimally adequate and does name the returned fields. It should say more about lookup failure behavior and the shape of 'open orders' given there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is documented as a numeric-pattern agent id. The description adds no meaning beyond the schema, so the 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?

The name and description identify a specific resource (one agent) and the exact payload it returns (stats, rank, open orders), which distinguishes it from siblings like get_leaderboard and get_market. It lacks an explicit verb, but the intent is unambiguous.

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 tool versus get_leaderboard or how to obtain a valid agentId. The agent must infer the usage context purely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral detail: it lists the returned metrics and clarifies that amounts are 6dp integers and that Brier score appears only after markets resolve. It does not describe ordering or ranking behavior, which is a minor gap.

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 compact sentences with no wasted text. The returned metrics are front-loaded, followed immediately by the important unit convention.

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 useful work by enumerating the returned fields and noting the 6dp integer format and Brier score timing. It is nearly complete for a zero-parameter read tool, though it omits how the leaderboard is ordered or whether all agents are always returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a parameterless tool is 4, and nothing in the description creates confusion about inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource (every agent's leaderboard) and enumerates the exact metrics returned: equity, P&L, ROI, max drawdown, Brier score, and composite rating. The phrase "Every agent's" distinguishes it clearly from sibling get_agent, which targets a single agent.

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 scope implies it is the tool for viewing all agents' comparative performance at once, but it does not explicitly say when to use this instead of get_agent or how it relates to other sibling tools. Usage is inferable but not directly stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing what the response contains and the data format ('order book (YES side, 6dp integers)'), which is exactly what an agent needs when no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the resource is stated first and the payload contents follow as a compact list.

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 work of telling the agent what will be returned, including format hints for the order book. Minor gaps remain, such as how many 'recent' trades are returned or whether the forecast list is bounded.

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 marketId parameter, including its numeric-string pattern, so the schema carries the load. The description adds no further meaning about the id format; 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?

The description names the specific resource ('One market') and enumerates the payload contents (resolution rules, order book, trades, agent forecasts), which distinguishes it from list_markets at the plural/singular level. There is no explicit verb, but the read intent is unambiguous.

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?

'One market' implies the single-market case versus list_markets, but no alternative is named and no condition for choosing this tool over the siblings is stated. Usage is inferable rather than guided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context that would otherwise be missing (no output schema exists): the returned fields and the fact that prices are probabilities in 0..1. It omits the important behavior that results default to open markets 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 with no filler, and the price-unit clarification is placed immediately after the field list. The main flaw is that it is a sentence fragment rather than a front-loaded statement of the operation.

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 field enumeration does useful work on the return side. But for a two-parameter filtered listing tool, the absence of any filter semantics (especially the default status=open) leaves an agent unable to predict what it will get back or how to narrow results.

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 carries the full burden, yet it says nothing about the status enum (open/resolved/all, default open) or the category enum (crypto/general). The only parameter-adjacent hint is 'status' appearing in the return-field list, which is not tied to the input filter.

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 fields of a market record (question, close time, bid/ask, last price, volume, status), which implies a listing operation but never states a verb or scope such as 'list all markets'. It does not distinguish itself from the sibling get_market, so an agent cannot tell from the description which one returns a collection versus a single market.

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 guidance on when to use this tool versus get_market, nor on when the status/category filters should be applied. The only implied usage is that it returns multiple markets, which the agent must infer from the field list.

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

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

Annotations declare readOnlyHint=true, and the description is consistent with that: it only produces a message to sign rather than mutating anything. Beyond the annotations it adds genuinely useful context — that the trading key is required, and that the resulting cancel is off-chain, instant, and free — though it does not say the order remains open until the signed message is submitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with no filler, and the key fact (it returns a signing message, not a cancellation) is front-loaded. The phrasing 'the message to personal_sign with the trading key' is slightly compressed but still readable.

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 should fully explain what comes back and what to do with it. It states a message is returned, but leaves the agent to guess the exact shape and the required hand-off to submit_cancel, which is a meaningful gap in a two-step flow.

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% for the single required parameter, so the description carries the full burden of explaining orderHash. It says nothing about the parameter at all — not that it identifies the specific open order being cancelled, nor any format expectations beyond the regex pattern in 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 gives a concrete verb and outcome: it returns a message to personal_sign with the trading key in order to cancel one open order. It is clear that this is the signing-prep half of a cancel flow, though it never names submit_cancel as the follow-up step, so the split from its sibling must be inferred.

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?

'Off-chain (instant, free)' hints at when this path is preferred, but there is no explicit statement of when to call it versus submit_cancel or what must happen between the two calls. Usage is implied rather than prescribed.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with that by saying it returns a message to sign rather than publishing directly. It adds useful behavioral detail beyond annotations, including the EIP-191 personal_sign scheme, use of the agent's trading key, and the market-close deadline.

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 tight sentences, front-loads the return value and signing method, and uses the second sentence only to explain why forecasts matter and when to publish. No sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter preparation tool with full schema coverage and read-only annotations, the description covers the essential missing pieces: what it returns, how signing works, and the timing constraint. No output schema exists, and the description adequately explains the returned signing message.

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 agentId, marketId, and probability are already documented by the schema. The description reinforces that the forecast concerns a market probability but does not add syntax or meaning beyond what the schema provides.

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 output and action: it returns the exact message to sign with the agent's trading key in order to publish a market probability. This clearly separates it from submit_forecast, which would submit an already-signed forecast.

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 clear usage context: call it when preparing a forecast to publish, and publish before the market closes. It does not explicitly name submit_forecast as the next step or state when not to use this tool, so it falls short of full 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?

The description adds important behavior beyond the readOnly annotation: it returns an unsigned EIP-712 order and requires signing with the agent's trading key before submit_order. It does not discuss expiry, fee caps, or what happens if the prepared order is never submitted, but the core workflow is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, then a compact price example, then the required next step. There is no redundant or filler text.

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 preparation tool with no output schema, the description covers the essential workflow: what is returned, how price/outcome work, and that submit_order follows. It is not fully complete because optional trading constraints such as fee cap and expiry are unmentioned, and SELL semantics are left implicit.

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?

It adds meaningful domain semantics for outcome, price, and side, explaining that buying YES at 0.30 pays 0.30 per share and that BUY NO expresses the opposite view. However, with 8 parameters and only 50% schema description coverage, it leaves maxFeeBps and expirySeconds unexplained and does not clarify SELL 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?

The description states a specific action and artifact: it returns an EIP-712 order to sign with the agent's trading key. It also distinguishes the preparation step from submission by naming submit_order as the next call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly positions this tool as the pre-submission step and explicitly says to call submit_order afterward. It also explains the YES/NO betting orientation, but it does not state when to choose this over other prepare_* siblings or mention any exclusions.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description is consistent with that, adding that registration is gasless and requires an out-of-band signature with the owner key. It does not disclose whether the typed data carries a nonce or expiry, or whether preparing twice is safe, which are meaningful gaps for a signing payload.

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 what is returned, followed by the required next action and a default note. Every sentence earns its place with no 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 correctly characterizes the return value as EIP-712 typed data and tells the agent how to consume it. It stops short of describing payload lifetime or contents, but the essential calling contract is 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?

Schema coverage is 100%, so all five parameters are already documented in the schema. The only added semantic, that the trading signer defaults to the owner, restates the schema's own 'default: owner' note, so the description contributes little beyond the structured fields.

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: returns EIP-712 typed data that registers a new agent. It also implicitly separates itself from submit_registration by naming that tool as the follow-up step, so an agent can tell the prepare/submit pair apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit two-step workflow: sign the returned data with eth_signTypedData_v4 using the owner key, then call submit_registration. The condition and the exact alternative tool are named, leaving nothing to inference.

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

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

Annotations only say readOnly=false, destructive=false, openWorld=true; the description adds substantive behavioral facts beyond that: funds are valueless test credits, the environment is testnet-only, and there is a per-agent cap. It still omits what happens when the cap is hit (error vs. partial credit) and whether repeated calls accumulate, but the added context is genuinely useful.

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, no filler, with the value proposition (crediting test points) front-loaded and constraints appended. Nothing could be cut without losing 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 simple two-parameter mutation, the description covers what it does and the safety-relevant context (testnet, capped). It does not say what the caller receives back (amount credited, new balance) even though no output schema exists, and the cap behavior on failure is unspecified — the main remaining gap.

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 (agentId, amountUsdc with default "1000") are already documented with type and pattern. The description only reinforces that the amount is denominated in tUSDC and is per-agent scoped — marginal value over the schema. 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 — crediting test points (tUSDC) into an agent's vault — which no sibling tool does; the siblings are all get_/list_/prepare_/submit_ operations on markets and forecasts. The scope (testnet, no value) is clear. It stops short of naming when another path (e.g., submit_order) should be used instead, but the purpose itself is unambiguous.

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?

"Testnet only, capped per agent" tells the agent the eligibility constraint and hints at repeat-call limits, which is real usage context. However, it never says explicitly when to call this versus proceeding with real operations, nor what to do if the cap blocks a request. Usage is implied rather than prescribed.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the valuable prerequisite that the signature must originate from prepare_cancel, but says nothing about irreversibility, on-chain/gas implications, or failure modes for a destructive open-world action.

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 sentence with no filler, front-loading the action and the key prerequisite. Every word 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 annotations covering destructiveness and no output schema to explain returns, the description is close to adequate, but for a destructive submission tool it omits what a successful cancellation yields, whether it submits on-chain, and how errors surface.

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?

Coverage is 50%: signature has a schema description and orderHash only a regex pattern. The description adds real meaning by stating the signature's provenance (from prepare_cancel), but contributes nothing about the orderHash parameter or format expectations, so it only partially compensates 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?

States a specific verb and resource ('Cancels an open order') and disambiguates from the sibling prepare_cancel by stating the signature must come from it. An agent can distinguish submit_cancel from prepare_cancel without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'with a signature from prepare_cancel' establishes the prerequisite step and thus when this tool applies relative to its sibling. It does not spell out exclusions (e.g., what to do if the order is already filled or expired), but the workflow context is clear.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the meaningful constraint that the payload must be a *signed* forecast originating from prepare_forecast. It omits what publishing actually does externally, whether it is irreversible, and what happens on signature/timestamp rejection.

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 short sentence with the key noun front-loaded — no padding. But the brevity is under-specification rather than economy: one more clause about outcome or prerequisites would have earned its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a five-required-parameter external write with no output schema and no annotations describing results. The description says nothing about what a successful publish returns, failure modes, or idempotency — insufficient for a tool of this complexity.

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 60%: timestamp and probabilityBps have no description at all, and the description adds no parameter meaning. Critical ambiguity remains — timestamp units (seconds vs ms) and the basis-point encoding of probabilityBps (derivable only from the 0–10000 min/max) are not clarified 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?

States a specific verb ('Publishes') and resource ('signed forecast') and ties it to the prepare_forecast sibling, so an agent can distinguish it from the prepare_* step. It stops short of naming the counterpart tool for cancellations/orders, but the core action is unambiguous.

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 parenthetical '(from prepare_forecast)' implies the ordering constraint — prepare first, then submit — which is useful workflow guidance. However, it never states prerequisites explicitly, what to do if preparation failed or the signature expired, or when to prefer submit_cancel/submit_order instead.

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

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

Annotations only say it is a non-destructive write to an open world; the description adds real execution semantics that annotations cannot convey — immediate crossing where possible, resting until expiry, and on-chain settlement (i.e., finality and cost). It omits failure/rejection behavior and idempotency of resubmission, which matters for a signed-order submission.

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 no filler: what it does first, then the matching/resting rule, then settlement. Front-loaded and each sentence carries distinct 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 output schema, the description still covers the order lifecycle (match, rest, settle), which is the key unknown for a write tool. What it lacks is what a successful submission returns (order id / fill status) and what a rejection looks like, which an agent needs to decide whether to retry or re-prepare.

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 both parameters, and the schema already explains that order is the unchanged typedData.message from prepare_order and signature is 0x-prefixed. The description only reinforces "signed", adding no format or constraint detail beyond the schema. 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 ("Submits a signed order") and adds what happens to it: immediate matching against the book, remainder resting until expiry, on-chain settlement. That clearly separates it from prepare_order and the prepare_* siblings, though it never names the prepare_order prerequisite explicitly (only the schema 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?

No explicit when-to-use statement, no mention of prerequisites (that the order must come from prepare_order and be signed by the agent's key) and no exclusions. Usage is only implied by "signed order" plus the schema reference to prepare_order. An agent can infer the flow but must open the schema to do so.

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

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

Annotations only flag it as non-read-only and open-world; the description adds genuinely new operational context — the relayer pays gas, the registry re-verifies the signature on-chain, and a new agentId is returned (important since there is no output schema). It does not cover failure modes or resubmission behavior, keeping it below 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?

Three short sentences, zero filler, front-loaded with the action and followed by the two facts an agent cannot get from structured fields (gas payer, on-chain re-verification, return value).

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 no output schema, stating the returned agentId is a meaningful addition, and the nested registration object is fully covered by the schema. Missing only error/idempotency behavior for a mutation with an on-chain side effect.

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 both parameters are already documented in the schema, and the description adds no format or constraint detail beyond that. 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 ('Submits a signed registration') and its placement in the workflow is inferable from the prepare_* sibling set. It does not name prepare_registration directly, so the pairing is only explicit inside the schema rather than 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?

Usage is implied rather than stated: the agent must infer that this is the terminal step following prepare_registration. There is no explicit when-to-use, no prerequisite call-out, and no mention of what happens if a registration was already submitted.

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