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

With no annotations, the description carries the full burden. 'Fetch a public creator profile' implies a safe read, and listing the returned fields adds value, but it omits auth requirements, not-found behavior for invalid handles, and any rate-limit or pagination context.

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 that front-load the action and resource, then name the accepted input forms. Every sentence earns its place with no 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 simple one-parameter read tool with no output schema, the description covers the returned fields and input options well. The main gap is failing to differentiate from get_user_profile and to say what happens when the handle is not found.

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 the handle parameter is already fully documented in the schema. The description merely restates that a wallet or alias is accepted and adds no new format, validation, or example detail beyond what the schema says.

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 ('Fetch a public creator profile on Bopster') and names the returned fields (alias, avatar, verified badge, creator stats). It does not distinguish itself from the sibling get_user_profile, leaving an agent to infer which profile tool to use.

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 implies a read-only lookup and notes that either a wallet address or alias is accepted, but gives no explicit when-to-use or when-not-to-use guidance and does not mention the get_user_profile alternative. Usage is inferable but not directed.

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 add real context: values are read live from the BopsterFactory contract on Base, percentages are relative to the total market pool, and fees are zero on refunds (no positions or no winning side). Missing are latency/RPC-failure behavior and whether values can change over time, but the refund edge case is genuinely useful disclosure.

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 the return value and its source, then the interpretation of the numbers, then the edge case. Nothing is wasted and nothing is 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?

No output schema exists, so the description should characterize the return value, and it does by naming the three fee components and their meaning. It stops short of specifying the numeric format (basis points vs. decimal percentages) or the exact response shape, which would be the final gap to close.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The description correctly avoids inventing parameter 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 verb and resource ('Return the Bopster market fee split') and enumerates the exact components returned (protocol, creator, resolver), which no sibling tool covers. The on-chain source (BopsterFactory on Base) further pins down scope so an agent can distinguish it from get_market or quote_position.

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: an agent can infer this is the way to fetch fee configuration, but the description never says when to call it versus related siblings like get_market (which may also surface fees) or quote_position. No exclusions or prerequisites are given.

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 behavioral burden. It communicates that this is a read-style return operation with pagination and a time window, but it omits permissions, data visibility, ranking basis, and rate/limit 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?

It is a single front-loaded sentence with no wasted text. The core purpose, participant categories, time scope, and pagination are all packed efficiently.

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 read tool with a fully described four-parameter schema, the description covers purpose, participant types, time window, and pagination sufficiently to invoke it correctly. Return fields are not detailed, but the absence of an output schema makes that a relatively minor 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 the schema already documents page, type, limit, and period in detail. The description restates participant categories, time period, and pagination but adds no meaningful syntax, defaults, or constraints 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 description uses a specific verb ('Return'), resource ('ranked leaderboard of Bopster participants'), and scope (creator/predictor/oracle leaderboards over a time period). It is clearly distinct from the sibling tools, none of which appear to offer leaderboard data.

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 makes the use case clear: retrieve rankings for a given participant type and time window. It does not explicitly state when not to use the tool or name alternatives, but no sibling tool offers a comparable leaderboard function.

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 carries the full behavioral burden and does so well: it discloses that the message is one-time, the signing standard, that the resulting session is short-lived and limited to IPFS pinning and portfolio reads, and that it cannot move funds or sign transactions. The rate limit is also stated.

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?

Despite being several sentences, every sentence adds useful context: purpose, prerequisite, signature format, session scope, safety boundary, and rate limit. The most important routing information is 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?

There is no output schema, but the description explains what is returned (a one-time message), how it is used, how long the session lasts, what the session can and cannot do, and the rate limit. Nothing material is missing 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?

Schema description coverage is 100%, so the single wallet parameter is already documented with its format and meaning. The description reinforces that the wallet signs the message but adds no syntax or format detail beyond the schema, making baseline 3 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?

The description names a specific resource (a one-time login message) and its exact purpose: signed with personal_sign (EIP-191) to open a short backend session. It also positions the tool as step 1 of creating a market and as a prerequisite for get_portfolio, so an agent can distinguish it from sibling tools.

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 states when to use it (step 1 of market creation, or before get_portfolio) and when not to overuse it ('ask for one only when you're about to sign it'), with an explicit rate limit of 3 per minute. This is exactly the routing and timing guidance an agent needs.

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 helpfully discloses data semantics — amounts in USDC base units (6 decimals) and times in unix seconds (UTC) — and that positions are only included when a wallet is supplied, but it says nothing about read-only nature, behavior on an unknown/invalid address, or response size.

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 dense sentence, front-loaded with the purpose and followed by the return fields and unit conventions. Every clause carries information; nothing is redundant or padded.

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 is no output schema, the field enumeration and unit conventions are essential and present. The only gap for a simple two-parameter read is the lack of any error/not-found behavior, which is minor but not negligible.

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 schema, establishing a baseline of 3. The description echoes the optional-wallet behavior but adds no format or edge-case detail beyond what the schema's patterns and descriptions already say.

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 — fetch the full detail of a single Bopster prediction market — and constrains it to lookup by on-chain address. It also enumerates exactly what comes back (question, category, source, pools, phase, oracle state, optional positions), which separates it cleanly from list_markets.

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 'single ... by its on-chain address' implies this is the point-lookup counterpart to a listing tool, but no sibling is named and there is no explicit when-not guidance. An agent can infer the usage but must do the routing itself.

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 burden and does so well: it discloses the auth requirement and why it exists (backend only shows a portfolio to its own wallet), that each signature is single-use, that the session cannot move funds, and that it is not persisted. It also pins down the amount encoding (USDC base units, 6 decimals), which is a real correctness hazard.

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 purpose, then the units caveat, then the login mechanics. Every sentence carries information an agent would otherwise have to discover by failing a call; nothing is redundant 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?

There is no output schema, and the description compensates by naming what is returned (positions, claimable rewards, refunds) and the amount encoding. Combined with the fully documented three-parameter schema and the disclosed auth lifecycle, an agent has everything needed to call this correctly on the first attempt.

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 baseline is 3; the description goes beyond it by explaining how the three parameters relate (wallet must be the signer, nonce and signature must come from the get_login_message flow, each signature is spent after one call). It doesn't add format details, but the schema already carries those.

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 ('Fetch the Bopster portfolio of a wallet') and enumerates the payload ('open positions across markets, claimable rewards and refunds'). This is clearly distinct from siblings like get_user_profile or quote_position, which return different resources.

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 the exact prerequisite chain: call get_login_message for the wallet, sign with personal_sign, then pass wallet/nonce/signature here. It also scopes applicability to 'a wallet you control' and names the sibling that supplies the nonce, so the agent knows both when to use it and what must happen first.

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 burden. 'Public' and 'Fetch' imply a safe read, and the aggregate-activity scope is useful, but nothing is said about auth requirements, behavior for an unknown or ambiguous handle, auto-detection failure modes, or response shape beyond a list of role categories.

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 zero waste; the resource and its return scope are front-loaded before the accepted input forms. Nothing is padded or repeated.

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 one-parameter read tool this covers what is returned at a high level and what input forms are accepted, which is largely sufficient with no output schema. However, it leaves the agent unable to choose between this and get_creator_profile, a meaningful gap in a 17-tool namespace.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema, including the auto-detect behavior. The description merely restates that a wallet address or alias is accepted, adding no syntax, format, or ambiguity-handling detail beyond the structured field. 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 ('Fetch a public Bopster user profile') and adds scope detail: aggregate activity broken down by creator, predictor and oracle roles. It does not distinguish itself from the sibling get_creator_profile, which an agent could easily confuse with this tool.

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 when-to-use or when-not-to-use guidance, and no mention of the obvious alternative get_creator_profile. The only framing sentence ('Accepts either a wallet address or an alias') is parameter information already present in the schema, not 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 provided, the description carries the full disclosure burden and does add real context beyond the schema: it states the return payload (YES/NO pools, total volume, end/resolve times, a pagination block with page/size/total/pages) and the USDC 6-decimal unit convention plus the added *_formatted and *_iso convenience fields. It does not mention auth requirements or caching/rate behavior, which is the main remaining gap for a non-annotated 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 sentences with zero filler, front-loaded with purpose and followed by capability, then return shape and units. Every clause conveys information an agent cannot get from the structured fields alone.

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 is doing the necessary work of describing the return shape, pagination block and unit conventions, which makes it largely complete for a 9-parameter read tool. It stops short of covering auth/access requirements or the relationship to sync_market, but nothing an agent needs to invoke it correctly is clearly missing.

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

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

Schema description coverage is 100% and three params have enums, so the schema already documents every parameter thoroughly. The description only summarizes filter families at a high level and adds nothing about title vs question search granularity, the creator address/name dual lookup, or the sort_field enum. 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 opens with a specific verb+resource: 'Search and list prediction markets on Bopster', and adds identifying context (non-custodial market on Base). It is clearly a filtered-list operation, but it never names a sibling such as get_market (single-market fetch), so the differentiation is left 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?

The sentence 'Supports filtering by status, category and text, plus sorting and pagination' implies the browsing/search use case, but there is no explicit guidance on when to use this versus get_market or sync_market, nor any stated exclusions. Usage is inferable rather than directed.

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; it implies a non-mutating read check via "read API" and "verify," but never states that it has no side effects or what a success versus failure response looks like. For a zero-parameter health probe the risk surface is small, which keeps this at adequate rather than poor.

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, zero filler, with the action front-loaded and the usage hint second. Nothing repeats the name or title.

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

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

A no-param, no-output-schema probe is nearly self-contained, and the description covers what it does and when to run it. The one remaining gap is what the result signals (boolean, status string, latency), which matters for an agent deciding whether to proceed.

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 and the baseline of 4 applies. The schema is empty and fully consistent with the 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?

States a specific verb and resource: verifying that the Bopster read API is reachable and responding. Against a sibling set made up entirely of market, position, and profile operations, a pure reachability check is unmistakably distinct, so no sibling routing is needed.

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?

"Useful before running other tools" gives a clear triggering context rather than leaving timing to inference. It stops short of any exclusion or failure-handling guidance (e.g., what to do if the check fails), so it is strong but not a full when/when-not statement.

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 behavioral burden well: it discloses the non-custodial model, says the server never holds keys or sends anything, explains the ordered transaction flow, and notes that it reports why there is nothing to claim. These are exactly the behavioral traits an agent needs before invoking a transaction-preparation 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 concise and front-loaded: it leads with the purpose, then explains transaction ordering and the non-custodial guarantee. Every sentence adds useful information without repetition.

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 claim-preparation tool with two fully documented parameters and no output schema, the description is complete enough. It covers the purpose, sequencing, edge case when there is nothing to claim, and the non-custodial safety model, leaving no critical gap for an agent 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?

Schema description coverage is 100%, so the market and wallet parameters are already fully documented in the input schema. The description does not add further parameter semantics beyond the schema's contract address and signer/position-reading explanations, making baseline 3 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?

The description states a specific action: determine what a wallet can withdraw from a Bopster market and build unsigned transactions for claim()/claimRefund(), including finalize or emergency refund when needed. This clearly distinguishes the tool's claim-focused scope from sibling preparation tools such as prepare_finalize.

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: use it to work out a wallet's claimable amount and assemble the ordered transactions, including settling first when the market is ready but un-finalized. It does not explicitly name alternatives like prepare_finalize or quote_position for previewing, so there is no explicit when-not guidance.

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

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

With no annotations, the description carries the burden and does well: it discloses permissionless settlement, resolver reward incentives, emergency refund support, and that the server is non-custodial and never holds keys or sends transactions. It stops short of describing response behavior or whether settlement is irreversible once 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?

The description is front-loaded with the core action, followed by eligibility, reward context, emergency path, and non-custodial behavior. It is efficient, though slightly more compact phrasing could improve 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?

It covers eligibility, permissionless access, reward behavior, the emergency refund path, and custody safety for a one-parameter tool. However, with no output schema and no annotations, it could do more to explain the return shape, such as readiness result versus unsigned transaction list, and any failure cases.

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 market parameter, so the schema already documents the required 0x address format. The description adds only contextual meaning that the market is on Base and is a Bopster market, which is useful but does not add syntax or semantics 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 description states a specific verb and resource: check settlement readiness and build unsigned transaction(s) for a Bopster market on Base, including the emergency refund path. It is clear without opening the schema, but does not explicitly name or differentiate from siblings such as prepare_claim or prepare_position.

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 conditions for use: after the Reality.eth answer is final for normal settlement, or via the emergency refund path when an answer never became final. It also notes that anyone can settle and that the sender may earn the resolver reward, but it does not explicitly state when to use a sibling tool 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?

With no annotations, the description carries the full burden and does well: it discloses that the tool reads a confirmed transaction, verifies exact matchup against the draft, returns an unsigned transaction, and is non-custodial ('nothing is signed or sent here'). It does not cover failure behavior on mismatch, fees, or idempotency, so it falls short of a 5.

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

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

The workflow step is front-loaded, followed by the prerequisite, verification behavior, return value, and non-custodial note. Every sentence earns its place and no space 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 7-required-parameter preparation tool with no output schema, the description explains what is returned (an unsigned createMarket transaction) and how verification works. It is nearly complete, though it could note what happens when verification fails or what the caller should do next with the returned transaction.

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 high (86%), so the baseline is 3. The description adds meaningful provenance guidance beyond the schema by instructing that `next.arguments` be passed unchanged and that the question tx hash be supplied alongside it. It reinforces the relationship between the draft token and prior tool output without restating every field.

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 ('Prepare a Bopster market launch') and precisely locates it as step 3 of the creation flow. It distinguishes itself from prepare_market_question by making clear that it only launches drafts that tool built.

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 'Only launches drafts prepare_market_question built' and tells the caller to pass that tool's `next.arguments` unchanged, plus the question tx hash. This gives a clear prerequisite and alternative routing rule with no inference required.

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

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

With no annotations, the description carries the full burden and does well: it discloses the validation layer (site, backend and factory rules), the IPFS metadata pinning side effect, the exact return artifact, and the absence of signing/broadcast. It stops short of stating failure behaviour, idempotency, or what happens if validation fails, which keeps it at a 4 rather than 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 sentences, each doing distinct work: sequence, input constraint, processing/validation, output and safety boundary. The step number and the template restriction are front-loaded before the behavioural detail, and no sentence is redundant with the title or annotations.

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 12-parameter, 9-required tool with no output schema, the description covers the essentials: what it produces (unsigned transaction), what it costs side-effect-wise (IPFS pin, nothing sent), and the hard input constraint. Authentication mechanics are delegated to the schema's wallet/nonce/signature descriptions, which is acceptable, though a sentence on ordering relative to sibling steps would close the 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 every one of the 12 parameters is already documented, including the template oneOf branches and their per-field constraints. The description adds only the framing that the template must be one of the five named shapes with site-exact wording, which is a modest gloss on what the schema already enforces.

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?

A specific verb-plus-resource statement: it names the step (2 of creating a Bopster market), the constrained input space (five templates, no free-text), and the concrete outcome (validation, IPFS pinning, unsigned Reality.eth askQuestion transaction). An agent can distinguish this from prepare_market_launch and register_market because it is the question-preparation step that produces an unsigned tx rather than launching or registering anything.

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 establishes clear sequencing ('Step 2 of creating a Bopster market') and an exclusion ('free-text questions are not accepted'), and clarifies the non-custodial boundary ('nothing is signed or sent here'). It does not name the sibling tools that come before or after (get_login_message, prepare_market_launch, register_market), so the agent must infer the workflow edges from the sibling list rather than being routed explicitly.

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

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

With no annotations, the description carries the full burden and does well: it discloses the two-step transaction structure (exact-amount approval then position), the validation checks performed, and the non-custodial model (server never holds keys, never sends; agent's wallet signs and sends in order). It stops short of describing failure modes or what the returned payload 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?

Two tight sentences, front-loaded with the action and the chain, followed by the behavioral guarantees. No filler and nothing repeated from the title or schema.

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 mutation-adjacent prepare tool with no annotations and no output schema, the description covers chain, transaction sequence, validation, and custody model. The main remaining gap is the shape of the return value (ordered list of unsigned transactions?), which an agent must infer from 'signs and sends the transactions in order'.

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 the schema already documents all four parameters including the whole-token-units amount and the wallet-vs-market address distinction. The description adds one useful nuance — the approval is for an *exact* amount rather than an unlimited allowance — but provides no further per-parameter semantics. 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 artifact ('Build the unsigned transactions') plus the exact resource and scope ('take a YES or NO position on a Bopster market on Base'). This clearly separates it from read-only siblings like get_market, quote_position, and from other prepare_* tools (claim, finalize, market_launch).

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 context for use: the agent has already chosen a market and side and needs transactions it will sign. It also states the preconditions the tool validates (market open, real Bopster market, sufficient wallet balance), which implicitly tells the agent it need not pre-check those. It does not, however, mention alternatives such as quote_position for pricing or explain ordering against prepare_claim/prepare_finalize.

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 a solid job: it declares read-only behavior, explicitly states no transaction is built, and warns that parimutuel payouts shift with every later position so the estimate is not a fixed quote. It omits any note on auth/network prerequisites and does not say what the returned estimate 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?

Three tight sentences: what it does first, then the read-only clarification, then the volatility caveat. Nothing is repeated and no sentence could be dropped 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?

No annotations and no output schema, so the description must cover the behavioral profile — and it does, covering read-only status and the moving-estimate caveat. The only gap is the shape of the returned estimate, which an agent must discover by calling it.

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 side/amount/market are already documented with enum and format details. The description only restates that size and side feed the estimate, adding no format or edge-case guidance 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?

The description opens with a specific verb ("Estimate") and a precise resource ("what a YES or NO position of a given size would pay on a Bopster market if its side wins"), and identifies the chain (Base). The phrase "builds no transaction" separates it from the prepare_* siblings without requiring a schema look.

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 context is clear — this is a pre-trade estimate, and the note that it builds no transaction tells the agent it is not the execution path. It stops short of naming prepare_position as the tool to call when the user actually wants to place the stake, leaving the alternative 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: it discloses the backend notification side effect, that the backend re-reads state from the chain, and that the operation is non-critical because the indexer would eventually catch up. Missing are failure modes (e.g., unknown or unconfirmed tx_hash) and any idempotency statement about re-registering the same market.

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 the workflow position, then the effect, then the caveat. The final sentence is justification rather than instruction but still earns its place by telling the agent the call is optional and safe to skip.

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, so the description correctly names the return ('the new market and its link'). For a single-parameter, side-effecting registration tool with no annotations, the important behavioral facts are covered; only error handling and repeat-call semantics are absent.

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 already documents the expected hash format via pattern and description. The description adds only that the transaction must be confirmed, which is marginal beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States specific verbs and resources: reads the confirmed createMarket transaction, returns the new market and its link, and notifies the Bopster backend. The 'Step 4 of creating a Bopster market' framing positions it in the workflow. It does not explicitly contrast with the sibling sync_market, which is the main residual ambiguity.

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?

'Step 4 of creating a Bopster market' clearly places it after the createMarket transaction is confirmed. The closing sentence signals it is an optional optimization ('its indexer would find it anyway; this only saves the wait'), which is real when-to-use guidance. It stops short of naming an alternative tool or an explicit when-not condition.

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 discloses that the call changes nothing on-chain, moves no funds, and that the chain remains the source of truth. It also explains the observable effect (site and other tools update immediately). It stops short of stating failure behavior when tx_hash is unconfirmed or invalid, or whether the call is idempotent.

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

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

Two sentences, front-loaded with the action and the reason, then the safety clarification. Every clause carries information; 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 three-parameter, no-output, unannotated tool, the description covers purpose, trigger timing and side-effect safety. It omits what the tool returns or does on failure, which is a modest gap since there is no output schema to fall back on.

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 market, wallet and tx_hash are already documented with types and patterns; baseline 3 applies. The description reinforces that tx_hash is a confirmed transaction and that the tool acts on that market, but adds no format or edge-case semantics 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 description gives a specific verb and resource ('Ask the Bopster backend to re-read a market from the chain') plus the exact triggering condition ('after a transaction confirms'). It is clearly a refresh trigger rather than a read, which separates it from get_market/list_markets in spirit, but it never names those siblings, so a 4 rather than 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?

It states the precise moment to call it: after a transaction confirms, instead of waiting for the next indexer pass. That is clear usage context, but there are no explicit exclusions (e.g. do not call before confirmation, do not call if the tx reverted) and no sibling tool is named as an alternative.

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