VibeKast

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

Annotations already establish readOnlyHint and openWorldHint, so the bar is lower. The description adds substantial context beyond them: it returns unsigned transactions in a specific order (approve, then buy), buys more where the forecast is more confident than the crowd, and states the budget range and fee inclusion.

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 and return behavior, then moves cleanly through input alternatives, sizing logic, and budget constraints. Every sentence carries useful information and there is 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?

For a complex trade-construction tool with five parameters and no output schema, the description covers what is returned (unsigned approve and buy transactions to sign and send in order), input alternatives, and budget semantics. It leaves some minor gaps around return value structure and prerequisites, but it is largely sufficient 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 coverage is 100%, so the baseline is 3. The description still adds value by making the either/or choice between quantiles and probs explicit, labeling quantiles as easiest, and specifying that budget is in tUSDC including the fee and must be between 1 and 10000, details not present in the schema for budget.

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: it turns a BTC settlement-price forecast into a trade and returns unsigned approve/buy transactions. This is clearly distinct from the sibling reader/faucet tools, and an agent knows exactly what the tool produces without opening the schema.

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

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

It gives clear input guidance (use EITHER quantiles OR probs, with quantiles easiest) and context that the trade is on this week's market. However, it does not explicitly say when to use this tool versus alternatives or that get_market must be called first to obtain the price ranges needed for probs.

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 establish readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context about what the standings include: humans plus registered AI agents, ranking by total points, and separate skill points, though it does not discuss pagination or return ordering beyond rank.

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

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

The description is a single efficient sentence, front-loading the key resource and scope with no wasted 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 simple read-only standings tool with fully documented parameters and safety annotations, the description covers the important content well. It could say more about the returned fields or season definition, but it is sufficient 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 both parameters are already documented in the schema. The description mentions registered AI agents, which loosely corresponds to agentsOnly, but it adds no parameter syntax or defaults 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 clearly identifies the resource as current Season standings for humans and registered AI agents, ranked by total points with skill points separate. It lacks an explicit verb like 'get' or 'list', but the purpose is still unambiguous and no sibling tool overlaps.

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 by 'Current Season standings' and the sibling set does not include a competing leaderboard tool, but there is no explicit when-to-use or when-not-to-use 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real content by enumerating the returned fields, including the oracle price and per-range crowd probabilities, which tells the agent this is a live read, not a cached snapshot. It says nothing about freshness or rate limits, so it is not exhaustive.

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

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

One dense sentence plus a four-word instruction. The control-flow hint ('Call this first') is placed at the end where it reads as an action, and no clause is filler.

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

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

With no output schema, the description carries the return-value burden and does so by listing every field an agent would need to reason about a market. A one-parameter, one-resource read tool is fully specified by what is given.

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

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

Schema description coverage is 100% and the single parameter is fully documented with its pattern and default. The description only echoes the 'this week's or past' distinction, so it adds little beyond the schema — baseline 3.

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

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

Names a specific verb and resource ('this week's Bitcoin market (or any past one)') and enumerates exactly what the payload contains: question, close time, settlement rule, result, Chainlink price, and range probabilities. That is concrete enough to separate it from list_markets and get_trades without opening a 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?

'Call this first' gives an explicit ordering instruction, and the schema-plus-description pairing routes the agent to list_markets when it needs an address. It stops short of stating when NOT to use it, but the sequencing guidance is unusually direct.

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 new behavioral context: the message must be signed within 10 minutes via EIP-191 personal_sign and consumed by register_agent, and it explains the downstream benefit (Season points with an AI tag). It does not describe what the returned message contains or the failure mode on expiry.

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, front-loaded with the core action and signing standard, then the expiry constraint and the next tool to call. No filler or 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 no-output-schema tool, the description implies the return value (the message to sign) and names the follow-up call (register_agent), which is enough for correct invocation. Minor gap: it never explicitly states the shape of the returned message or what an agent should do if the window expires.

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 all four parameters (name, wallet, optional url, optional description) are already documented in the schema with patterns and length limits. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 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 ('Builds the exact message an agent's wallet signs') plus the precise signing scheme (EIP-191 personal_sign), which no sibling tool does. An agent can immediately distinguish this from register_agent (the step that consumes the message) and from other get_* siblings.

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?

Explicit sequencing is given: 'Sign within 10 minutes, then call register_agent,' which tells the agent exactly when this tool fits in the flow and what to do next. It stops short of stating when-not to use it or what happens if the 10-minute window lapses, but the 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 and openWorldHint, so the description's job is to add context, which it does by disclosing ordering, pagination fields (hasMore, complete, nextFromBlock), and completion semantics. It does not mention rate limits or error conditions, but the pagination contract is well covered.

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 wasted words. Core behavior and pagination loop are front-loaded and immediately actionable.

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?

Without an output schema, the description supplies the critical pagination contract (hasMore, complete, nextFromBlock) needed to consume results correctly. It does not describe the shape or fields of individual trade objects, which is a minor remaining gap for a data-returning tool.

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 three parameters are already documented. The description adds only modest guidance on fromBlock usage (pass nextFromBlock while hasMore) and does not meaningfully elaborate on market or limit beyond the schema, so a baseline 3 is appropriate.

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

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

States a specific resource ('Trades in a market') with ordering ('oldest first') and pagination ('paged by block'), so the agent knows exactly what is returned. It does not explicitly contrast with siblings like get_market or list_markets, leaving a small gap in differentiation.

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?

Provides a concrete call pattern: start without fromBlock, then pass nextFromBlock while hasMore is true, and treat complete as final. It lacks explicit when-not-to-use guidance or alternative routing, which keeps it below a 5.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description goes beyond that by disclosing the returned payload (balances, positions, registration status, next steps), which is meaningful since no output schema exists. It stops short of noting rate limits, whether it fails for unregistered wallets, or freshness of the data.

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 that enumerates the payload with no filler or redundancy. It is efficiently sized for a one-parameter read tool, though the list-style phrasing is slightly dense.

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 carries the burden of describing return content and does so thoroughly for a simple read-only, single-parameter tool. Gaps are minor: no failure modes for invalid/unregistered wallets and no note on data freshness.

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%: the single 'wallet' parameter is documented with its format pattern. The description adds nothing about the parameter, so the baseline 3 applies — the schema does the work and the description neither helps nor hurts.

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 (a wallet) and enumerates exactly what is returned: test ETH/gas balance, tUSDC balance, open positions in this week's market, registration status, and next-step hints. That is concrete and distinctive, though it never states the verb explicitly and does not call out how it differs from siblings like get_leaderboard or get_registration_message.

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 mention of 'registration status' and 'suggested next steps' implies this is a status/entry-point call in the onboarding flow, which is useful implied usage. But there is no explicit when-to-use statement, no prerequisite (e.g., call before register_agent or build_order), and no exclusion relative to the seven sibling tools.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description adds useful context by disclosing ordering ('newest first') and return contents including conditional settlement fields. It does not mention pagination or result limits, which is the main remaining 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?

It is a single dense sentence with the resource and ordering front-loaded, and every clause adds information about scope or returned fields. There is 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 usefully explains returned fields including settlement price and winning range. It is nearly complete for a simple list tool, though it does not clarify pagination or whether the full market history is 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?

Schema description coverage is 100% and the single status parameter has an enum, so the schema already carries the parameter meaning. The description does not add filtering semantics beyond what the schema provides, 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 the exact resource ('every weekly market') and scope ('newest first'), which clearly distinguishes it from the singular get_market sibling. It also states what the listing contains.

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 by 'Every weekly market' and the optional status filter, but the description gives no explicit when-to-use guidance or alternatives such as get_market for a single market. It is adequate but leaves routing 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 give readOnlyHint and openWorldHint, so the description carries the real burden and does well: it discloses the exact amount (10,000 tUSDC), that it has no cash value, that the recipient is the sending wallet, and crucially that it returns an unsigned transaction rather than performing a mint. It does not say whether the mint is rate-limited or one-per-wallet.

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 wasted words; the key fact (unsigned transaction) comes first and the qualifiers are parenthetical.

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, no-output-schema tool the description covers what is produced (an unsigned tx), the amount, and the recipient. It could note that the caller must sign and submit the transaction and any per-wallet limit, but nothing essential is missing.

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

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

The tool takes zero parameters and the schema defines no properties, so there is nothing for the description to clarify. Baseline of 4 applies.

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

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

States a specific verb and resource: 'Builds the unsigned transaction that mints 10,000 tUSDC'. It is clearly distinguishable from the sibling request_test_eth (different asset) without naming it explicitly, which keeps it short of a 5.

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

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

Usage is only implied – 'this week's test collateral' signals a testing/faucet context, but the description never says when to call this versus request_test_eth or what prerequisites apply. No exclusions or alternatives are named.

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 it is a non-read-only, non-idempotent, open-world write. The description adds genuinely new context beyond that: the operation is permanent and only one name is allowed per wallet, which materially affects an agent's decision to call it. It does not mention failure modes or signature expiry handling.

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 filler; the permanence and uniqueness constraints are front-loaded where they will be read.

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

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

For a 6-parameter mutation tool with no output schema and low schema coverage, the description covers the core flow and safety-critical traits but omits what the optional url/description fields do and what happens on duplicate-name or invalid-signature failures. Adequate but with clear gaps.

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 33%, so the description must compensate, and it partially does by tying signature/name/wallet to the registration flow. However, the optional url and description parameters get no explanation in either the schema or the description, leaving gaps.

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 (registers) and resource (a wallet as a named AI trading agent), plus the mechanism (signature of the message from get_registration_message). This clearly separates it from read-only siblings like get_wallet and get_leaderboard.

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 embeds the prerequisite workflow by naming get_registration_message as the source of the signature, which tells the agent this is a follow-up step, not a standalone call. It stops short of stating exclusions or what to do if the wallet is already registered.

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 cover the safety profile (mutating, open-world, non-idempotent, non-destructive), and the description adds real behavioral context: exact amount sent, the low-balance precondition, a 24-hour per-wallet rate limit, and that the asset is valueless testnet ETH. It does not say what happens on rejection (already funded, rate-limited), which is the remaining behavioral 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?

Three short sentences, zero waste, and the core action plus amount is front-loaded. Everything stated earns 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?

For a single-parameter faucet call with no output schema, the description covers action, amount, precondition, and rate limit. The only omission is failure/return behavior and an explicit nod to the sibling faucet for a different asset.

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?

Only one parameter and schema coverage is 100%, so the schema already documents 'wallet' with a regex pattern. The description adds the eligibility nuance (recipient must hold less than the amount), which is marginally useful but does not change invocation syntax; 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 ('Sends 0.0001 Base Sepolia ETH'), names the amount, the network, and the recipient condition. An agent can distinguish this faucet call from sibling mint_test_usdc purely on the asset and chain stated.

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

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

Gives clear eligibility ('to a wallet holding less than that') and a frequency rule ('Once per wallet per 24 hours'), which functions as when-to-use context. It stops short of naming alternatives such as mint_test_usdc for the USDC counterpart or saying what to do when the rate limit is hit.

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