Baozi MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v5.0.1
Disambiguation5/5
Every tool targets a specific action and resource, with clear descriptions distinguishing boolean vs race markets, admin vs creator actions, and lifecycle steps (propose/resolve/finalize). No two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., build_*, get_*, validate_*). Even subcategories like intel and arena maintain the pattern, with no mixed conventions.
Tool Count1/5
76 tools is extreme, far exceeding the 50+ threshold. While the domain is broad, the massive number includes many near-duplicate variants for boolean vs race markets, making the surface overwhelming for agents.
Completeness5/5
The toolset covers the entire prediction market lifecycle: creation, betting, resolution, disputes, claims, whitelists, affiliates, intel, and arena. No significant gaps are apparent, and auxiliary features like validation and simulation round out the surface.
Average 3.7/5 across 72 of 76 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose side effects, return format, or execution requirements. It merely states the tool builds a transaction, omitting whether it requires a connected wallet, estimates fees, or returns a signed vs. unsigned payload. The '[REQUIRES BAOZI_LIVE=1]' hints at an environment flag but does not explain its implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no fluff, effectively front-loading the core purpose. However, the unexplained '[REQUIRES BAOZI_LIVE=1]' prefix is a cryptic distraction that reduces clarity, though it does not make the text lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction-building tool with no output schema and no annotations, the description is too minimal. It does not clarify what the returned transaction looks like, whether it is ready to sign, or any prerequisites (e.g., network, connected wallet). This is insufficient for an agent to invoke the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it only repeats the purpose. The schema already provides clear descriptions for display_name, creator_wallet, and creator_fee_bps, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Build', the resource 'transaction', and the object 'create on-chain creator profile', which distinguishes it from sibling tools like build_update_creator_profile_transaction or build_claim_creator_transaction. However, it lacks nuance about the exact scope of the transaction (e.g., whether it includes token creation or metadata initialization), so it is not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to update vs. create a profile). The only contextual hint is the '[REQUIRES BAOZI_LIVE=1]' prefix, which states a prerequisite but does not explain usage scenarios. This fails to help the agent choose among the many sibling transaction builders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions a prerequisite (BAOZI_LIVE=1) and implies a transaction-building side effect, but it does not explain whether the whitelist creation overwrites existing data, requires authorization, or has any mutable impact beyond building the transaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the requirement and states the action clearly. It contains no redundant information, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is terse but leaves critical gaps. It does not clarify what 'create whitelist' entails (e.g., whether it initializes a fresh whitelist or modifies an existing one), nor does it explain the distinction from the sibling add-to-whitelist tools. The absence of an output schema or description of return value further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear descriptions for both parameters ('Race market public key' and 'Market creator wallet'), giving 100% coverage. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a transaction to create a whitelist for a private race market, using a specific verb ('build') and resource ('whitelist for private race market'). However, it does not explicitly differentiate from sibling tools like build_add_to_race_whitelist_transaction, leaving some ambiguity about what 'create' means in contrast to 'add'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling whitelist-related tools. The only contextual hint is the prerequisite '[REQUIRES BAOZI_LIVE=1]', but it does not address selection criteria or exclusions, making it hard for an agent to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It only states a build operation with an environment requirement (BAOZI_LIVE=1), but does not disclose side effects, prerequisites beyond the flag, or what finalizing entails. This is insufficient for a transaction-building tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with an environment requirement in brackets. It is free of fluff, but the brevity borders on under-specification rather than structured completeness. Still, it earns its place with the finalize/resolve distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should explain the transaction construction context. It does not mention return format, sequencing, or side effects, leaving the agent with only a minimal directive and a flag. This is incomplete for a two-parameter builder in a complex domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'race_market' and 'caller_wallet', so the description adds no additional parameter meaning. Baseline of 3 applies; the tool name and description do nothing to enrich parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Build transaction to finalize race resolution' clearly states the action (build a transaction) and the specific object (finalize race resolution). It distinguishes from sibling tools like build_propose_race_resolution_transaction or build_finalize_resolution_transaction by the 'race' and 'finalize' qualifiers, though it does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs. alternatives. It only includes a prerequisite flag, no mention of sequencing relative to propose/resolve, or market eligibility. An agent would have to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It mentions the environment requirement, but does not explain whether this is a read-only transaction construction, what the output format is, or any side effects. For a 'build' operation, this is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with a requirement flag. It is concise with no wasted words, though it could be slightly more informative without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does not explain return values or side effects. It also lacks differentiation from very similar siblings (e.g., race whitelist removal), making it incomplete for an agent to understand when to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides; it only restates the overall purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Build transaction' and resource 'remove user from whitelist,' clearly stating its function. It distinguishes from the sibling 'build_add_to_whitelist_transaction' by the remove action, though it does not explicitly contrast with the race whitelist variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only provides a prerequisite environment flag [REQUIRES BAOZI_LIVE=1], but gives no guidance on when to choose this over build_remove_from_race_whitelist_transaction or other alternatives. No exclusions or scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether this tool submits the transaction or merely constructs it, what permissions or authorization are required, whether resolution is irreversible, or any side effects. The phrase 'directly resolve' is ambiguous and could imply bypassing normal dispute/confirmation steps, but this is not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the prerequisite environment flag and states the core purpose. Zero wasted words, and the formatting is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, this description is too sparse. It fails to explain the context of direct resolution versus propose/finalize flows, does not mention any required conditions beyond the environment flag, and omits any description of the return value or side effects. For a transaction builder, this level of sparsity leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters, each with a clear description (market public key, winning outcome, resolver wallet). The description adds no additional parameter semantics, but per the baseline for high schema coverage, a 3 is appropriate—the schema already handles the parameter meaning well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Build transaction to directly resolve a market' clearly states the verb (build), resource (market), and action (resolve directly). The 'directly' hints at a distinction from propose/finalize resolution flows, but it does not explicitly name or distinguish from siblings like build_propose_resolution_transaction or build_finalize_resolution_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the alternative resolution transaction builders. The only extra information is a prerequisite environment flag '[REQUIRES BAOZI_LIVE=1]', which is a precondition, not usage context. No exclusions or alternatives are mentioned, leaving the agent to infer when 'directly resolve' is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It uses 'suggested' to imply the output is non-authoritative, but it does not explicitly state whether the operation is read-only, whether it checks code availability, or what side effects may occur. This is a significant transparency gap for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words, making it very concise. It is efficiently structured, though it lacks additional supporting detail that could aid understanding, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no output schema), the description provides the core purpose but omits any explanation of the output format or behavior. Since there is no output schema, it could be clearer about what is returned, but for a simple tool it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (agentName and count) with 100% coverage. The description only reinforces that agentName is the basis and adds no new semantic meaning beyond the schema, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Generate' and the resource 'suggested affiliate codes', with the input basis 'agent name'. It is specific and understandable, though it does not explicitly distinguish it from sibling affiliate tools like 'check_affiliate_code' or 'get_affiliate_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus other affiliate-related tools, nor any prerequisites or alternatives. It only states the function, leaving the agent to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Get ... statistics,' which is essentially a restatement of the tool's name. It does not explicitly state that it's read-only, what data it aggregates, or any potential side effects or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it's almost too terse, lacking any elaboration on what 'statistics' includes. Still, for a no-parameter tool, this length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns. It merely says 'statistics,' which is vague and fails to convey the specific metrics (e.g., total affiliates, commission volume) that an agent would need to interpret the result. This is a significant gap given the lack of structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4 per rubric. The description adds minimal meaning with 'overall,' implying the statistics are aggregate and not filtered, which offers slight value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and specifies a unique resource: 'overall AI agent affiliate network statistics.' The word 'overall' hints at a network-wide scope, distinguishing it from sibling tools like get_my_affiliates or get_commission_info, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many affiliate-related siblings (e.g., get_affiliate_info, get_referrals). There are no exclusions, alternatives, or context that would help an agent choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only says 'build transaction to close betting.' It does not explain side effects, permissions, reversibility, or what the transaction does when executed. The BAOZI_LIVE=1 requirement is a behavioral condition, but the description is otherwise minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is terse to the point of lacking context, and the bracketed requirement is somewhat cryptic, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description provides minimal context. It does not explain what the built transaction does, how it relates to the betting lifecycle, or any prerequisites beyond BAOZI_LIVE=1. Given the complexity of transaction-building tools, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional meaning or context about parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a transaction to close betting on a race market. The verb 'build transaction' and resource 'close betting on a race market' are specific, and the 'race market' qualifier distinguishes it from the sibling build_close_market_transaction. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or exclusions. The only additional context is the '[REQUIRES BAOZI_LIVE=1]' prerequisite, which is a condition but not a usage guideline. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It states the intent but does not mention return type, validation behavior, side effects, or requirements, leaving important traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is maximally concise while still conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, but the description lacks information about output format and any potential caveats. Given no output schema and no annotations, it is minimally acceptable but incomplete for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described. The description adds no extra meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Format') and resource ('affiliate referral link') with a clear purpose ('for sharing'). It clearly states what the tool does, though it does not explicitly distinguish it from sibling tools like generate_share_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states the action without specifying context, prerequisites, or excluding other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only mentions the BAOZI_LIVE=1 prerequisite, but does not explain the effects of closing a market, authorization requirements, or whether it returns an unsigned transaction for signing. The description leaves major behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. The BAOZI_LIVE=1 requirement is placed clearly at the start. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and minimal description, leaving the return value and transaction format unexplained. The presence of many sibling tools further demands more context to differentiate use cases. The description is too sparse to be fully contextual for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described ('Market public key' and 'Caller wallet (creator)'). The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a transaction to close betting on a market, using a specific verb ('build') and resource ('transaction'). However, it does not explicitly distinguish this from the sibling tool 'build_close_race_market_transaction', leaving ambiguity about whether 'market' means a standard market versus a race market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to close betting on a market, but it provides no explicit guidance on when to use it versus alternatives like 'build_close_race_market_transaction'. The prerequisite 'REQUIRES BAOZI_LIVE=1' offers some conditional context, but no exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions an environment requirement and the transaction-building action, but does not disclose whether this is a read-only operation, whether it involves a financial bond cost, what the returned transaction contains, or any auth/permission requirements. This is a significant gap for a transaction-building tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the critical requirement prefix front-loaded. It is free of filler words and communicates the essential purpose and constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (2 params, no output schema, no nested objects), the absence of annotations and minimal description leaves out key context such as side effects, return format, relationship to the dispute lifecycle, and any user responsibilities around the bond. The description is insufficient for understanding the tool's full role in the system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both parameters ('Market public key' and 'Disputer wallet'), so the schema already documents their meaning. The description adds no additional parameter context, earning the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Build transaction') and the specific purpose ('challenge a proposed resolution with a bond'), distinguishing it from other transaction builders like proactive resolution or market closure. However, it does not explicitly differentiate from the sibling tool build_flag_race_dispute_transaction, relying on the tool name for that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear prerequisite ('[REQUIRES BAOZI_LIVE=1]') and implies the use case ('challenge a proposed resolution'). However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., race market disputes), nor any exclusions or conditions beyond the environment flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears full responsibility for behavioral disclosure. It states that the tool 'build[s] transaction' but does not explain whether the transaction is signed, unsigned, or what side effects (if any) this action has. It also does not mention the return value or whether this is a read-only operation. The only behavioral context is the BAOZI_LIVE requirement, which is insufficient for a transaction-building tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with the critical prerequisite placed at the front. It contains no redundant words or fluff. It is efficient, though it could benefit from a brief mention of the transaction's purpose in the broader workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three straightforward parameters and no output schema, the description provides the minimal necessary context: what it does and a prerequisite. However, it does not explain the transaction's role in the resolution lifecycle (e.g., that it is the first step before resolving or finalizing) or what the transaction object looks like. This is sufficient for a simple tool but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (market, outcome, proposer_wallet) with clear descriptions, achieving 100% schema description coverage. The tool description adds minimal semantic value, only reinforcing that the proposer is the creator (matching proposer_wallet). Since the schema already explains parameters thoroughly, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build transaction for creator to propose market outcome.' It specifies a concrete action (build transaction), an actor (creator), and a purpose (propose market outcome). This distinguishes it from siblings like build_resolve_market_transaction or build_finalize_resolution_transaction, but it doesn't explicitly exclude race-market variants (e.g., build_propose_race_resolution_transaction), so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a key prerequisite ('[REQUIRES BAOZI_LIVE=1]') and implies the use case (proposing a market outcome). However, it does not explicitly state when to use this tool versus alternatives like build_resolve_market_transaction or build_finalize_resolution_transaction, nor does it mention when not to use it. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects and behavior. It indicates the tool builds a transaction but does not clarify whether it submits, signs, or requires specific permissions. The BAOZI_LIVE flag is a prerequisite, not a description of runtime behavior, so the tool's actual effects remain opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately communicates the core purpose and includes a critical requirement. No filler words or redundant information; it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction builder with no output schema and no annotations, the description lacks essential details about return values, transaction structure, or any side effects. It does not explain what the agent can expect from the tool or how it fits into the broader transaction workflow, making it incomplete for reliable usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter has a clear description (e.g., 'Race market public key'). The tool description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Build transaction to remove user from race whitelist.' It uses a specific verb and resource, and the 'race' qualifier distinguishes it from the non-race whitelist sibling (build_remove_from_whitelist_transaction) and the add counterpart (build_add_to_race_whitelist_transaction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a prerequisite flag ([REQUIRES BAOZI_LIVE=1]) but gives no guidance on when to choose this tool over alternatives like build_remove_from_whitelist_transaction. There is no explicit context or exclusions provided, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the output contents ('earnings, referrals, status') but does not disclose whether authentication is required, how invalid codes are handled, or any side effects. As a 'get' operation, read-only is implied, but details are sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that are front-loaded and directly state purpose and key outputs. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with no output schema, the description provides a reasonable overview by listing the main data returned. It doesn't cover error cases or edge conditions, but the tool's simplicity lowers the expectation for additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'code' with description 'Affiliate code' (100% coverage). The description reinforces this by stating 'by code', but does not add additional format, constraints, or context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get affiliate account info by code' and lists the specific data shown (earnings, referrals, status). This distinguishes it from sibling tools like get_referrals or get_commission_info, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus other affiliate-related tools. The only implied context is that a code is needed, but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool retrieves commission structure and examples, but does not mention whether it requires authentication, if it has side effects (though 'Get' suggests read-only), or what the exact return format is. This is minimal behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only eight words, all essential. It is front-loaded with the action and resource, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description's brevity might be acceptable for a simple read operation. However, it could be more explicit about what 'commission structure' includes (e.g., rates, tiers) and what 'examples' refers to. The name and description together are understandable, but for a full tool in a rich ecosystem, a bit more context would help. It is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter semantics. The baseline for zero parameters is 4, and the description adds no unnecessary clutter, though it also doesn't need to. Thus a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'affiliate commission structure and examples,' clearly stating what the tool does. It is distinct from sibling tools like get_affiliate_info or get_my_affiliates, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other affiliate-related tools such as get_affiliate_info or get_my_affiliates. There are no context cues or exclusions, leaving the agent to infer based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the BAOZI_LIVE requirement but does not mention that resolving a market is an irreversible, authoritative on-chain action or what the transaction output will be. Lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with the prerequisite in brackets; it is front-loaded and without fluff. It could be considered slightly under-specified, but the brevity does not hurt the conciseness dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction builder with no output schema and no annotations, the description should explain what the transaction looks like and the context of direct resolution vs the proposal/finalize flow. It only provides the core action and a prerequisite, leaving an agent to guess at return values and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds no additional context about winning_outcome_index format or resolver_wallet requirements beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States it builds a transaction to directly resolve a race market, using a specific verb ('build') and resource ('race market'). The word 'directly' distinguishes it from propose/finalize siblings like build_propose_race_resolution_transaction and build_finalize_race_resolution_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a prerequisite condition (BAOZI_LIVE=1) but does not explicitly state when to choose this over the propose/finalize alternatives. The 'directly' phrasing implies usage for immediate resolution, but there are no clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only says 'build transaction,' without disclosing side effects, whether it signs or submits, the output format, or any on-chain implications. The BAOZI_LIVE requirement is a setup condition, not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with a key prerequisite prepended. No wasted words; it front-loads the critical requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the core action and a requirement, but for a transaction builder with no output schema, it lacks clarity on return values, error scenarios, and how it relates to the race or change-vote siblings. It is minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a clear description (market public key, vote boolean, wallet). The tool description adds no additional parameter context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Build transaction') and the specific context ('council member to vote on dispute'). It is sufficiently specific and distinguishes from the race-specific sibling, though it does not explicitly contrast with the 'change council vote' variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions the BAOZI_LIVE=1 prerequisite, which is a form of usage guidance, but it does not explain when to use this tool versus alternatives like build_vote_council_race_transaction or build_change_council_vote_transaction. The context of 'dispute' is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of explaining behavior. It only states the intent and a dev-environment requirement. It does not disclose that building a transaction typically returns an unsigned transaction that must then be signed and submitted, nor does it mention any side effects, fees, or permissions. This is a significant gap for a transaction builder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 12 words, front-loading the environment requirement before the core action. Every word contributes to conveying purpose or prerequisite; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and three parameters, this description is too sparse. It fails to tell the agent what to do with the returned transaction (e.g., sign/submit), who should sign (creator_wallet), or whether the operation has side effects. The agent may misuse the tool without additional context on the transaction lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for all three parameters (race_market, user_to_add, creator_wallet), giving it 100% schema coverage. The description adds no further parameter details beyond the general purpose, so the baseline of 3 applies. No compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description succinctly states the verb ('Build transaction') and the precise resource ('add user to race market whitelist'). It clearly distinguishes this from the generic 'build_add_to_whitelist_transaction' and from other race whitelist operations like removing or creating whitelists. No ambiguity remains about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It includes a practical prerequisite condition '[REQUIRES BAOZI_LIVE=1]', which tells the agent when the tool is callable. However, it does not explicitly state when to choose this over alternatives such as 'build_add_to_whitelist_transaction' for non-race markets or 'build_remove_from_race_whitelist_transaction' for removing. Usage context is implied by the name rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the admin-only restriction and the fact that it builds a transaction (implying it does not submit immediately). It does not explain what happens on-chain when the transaction is submitted, whether it is reversible, or any validation side effects—though for a build transaction tool, this is partially expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the critical prerequisites (env flag, admin-only) followed by the core action. It is concise and scannable, but there is minor redundancy: 'ADMIN ONLY' and 'Requires protocol admin signature' convey overlapping information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is short but covers the core purpose and admin requirement. It does not explain the return value of the built transaction or the optional new_resolution_time parameter, though the schema covers the latter. For a simple build transaction tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as all four parameters (market, caller_wallet, new_closing_time, new_resolution_time) have descriptions in the schema. The description adds no extra parameter semantics beyond what the schema already provides, aligning with the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Build' and the resource 'transaction to extend market deadline', which is specific and unambiguous. It distinguishes from siblings like build_extend_race_market_transaction by focusing on 'market' rather than 'race market', though not explicitly naming the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Prerequisites are clearly stated: '[REQUIRES BAOZI_LIVE=1] ADMIN ONLY' and 'Requires protocol admin signature', which gives strong context on when this tool is appropriate. However, it does not mention when to prefer this over other build_* tools (e.g., build_extend_race_market_transaction for race markets) or any explicit exclusions beyond admin-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only states the purpose and does not disclose whether the transaction is submitted, side effects, permissions, or return value. The word 'Build' hints at construction without execution, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a leading requirement flag, effectively communicating the core purpose without superfluous words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too minimal. It fails to explain the transaction's effect, return format, or how it integrates with the dispute process, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'race_market' and 'disputer_wallet' described in the input schema. The description adds no extra parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a transaction to dispute a race market resolution, using a specific verb ('Build transaction') and identifying the resource ('race market resolution'). This differentiates it from siblings like build_flag_dispute_transaction by the explicit 'race' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage requirement '[REQUIRES BAOZI_LIVE=1]' but does not explicitly contrast with alternatives. It implies use for race market disputes via the name and wording, yet lacks clear 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It notes that the transaction is 'unsigned', implying a preparatory step, but does not explain what the output is, whether it needs signing or submission, or any side effects. The 'REQUIRES BAOZI_LIVE=1' flag adds some context, but overall the behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the critical requirement and clearly states the action. It contains no filler or redundant information, achieving high efficiency and readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema) but the description remains incomplete for an agent. It does not explain what the 'unsigned transaction' output looks like, how to use it afterward, or any associated requirements beyond BAOZI_LIVE=1. Since no output schema exists, the description should compensate by describing the return value or next steps, which it fails to do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (code and user_wallet) including descriptive text. The tool description itself adds no extra parameter semantics beyond the schema, but since the schema already documents the parameters clearly, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build unsigned transaction to register as an affiliate with a unique code.' This is a specific verb+resource combination that distinguishes it from sibling tools like build_claim_affiliate_transaction or build_toggle_affiliate_transaction. The purpose is unambiguous and well-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite 'REQUIRES BAOZI_LIVE=1', which gives some usage context by indicating an environment requirement. However, it does not explicitly mention when to prefer this tool over alternatives, nor does it offer exclusions or conditions. Usage is largely implied by the tool's name and purpose rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own. It mentions a prerequisite (BAOZI_LIVE=1) and the action 'build transaction,' but does not state what the tool returns (e.g., an unsigned transaction object), whether it signs or submits, or any side effects. This is a significant gap for a transaction builder, leaving the agent uncertain about expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a bracketed requirement. Every word serves a purpose, and the critical pre-condition is front-loaded. No unnecessary elaboration or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage, the tool has no output schema and no annotations. The description is minimal and does not explain the return format, possible errors, or the broader dispute/race context. For a transaction builder with many siblings, this is insufficient for an agent to use it reliably without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each parameter has a description), so the schema carries the full burden of parameter semantics. The description adds no additional parameter-level context or examples, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build transaction for council to vote on race dispute.' It uses a specific verb ('build'), resource ('transaction'), and context ('council vote on race dispute'), effectively distinguishing it from siblings like build_vote_council_transaction by explicitly mentioning 'race dispute.' The requirement note adds clarity without muddying the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for building council votes on race disputes, and the requirement 'REQUIRES BAOZI_LIVE=1' indicates a prerequisite environment condition. However, it does not explicitly contrast this tool with alternatives (e.g., build_vote_council_transaction for non-race disputes) or state when not to use it. Thus, usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions a prerequisite and the claim action, but it does not disclose side effects, return format, whether the transaction is built only or also signed/submitted, or any state changes beyond 'claim.' The '[REQUIRES BAOZI_LIVE=1]' adds operational context but does not explain tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with a clearly marked prerequisite at the start. It avoids unnecessary words and is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and the core purpose is clear. However, with no output schema and no annotation coverage, the description should explain more about the transaction-building behavior, such as whether it returns a signed transaction, requires additional inputs, or has side effects. The prerequisite is noted, but the description remains minimal for a potentially state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, creator_wallet, with the description 'Creator wallet,' providing 100% schema coverage. The tool description does not elaborate on the parameter beyond this, so it adds no additional semantics. The baseline for high schema coverage is 3, and there is no extra information to raise the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build transaction to claim accumulated creator fees from sol_treasury.' It uses a specific verb ('build'), specific resource ('creator fees', 'sol_treasury'), and distinguishes itself from sibling claim tools (e.g., build_claim_winnings_transaction) by focusing on creator fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the action (claim creator fees) and includes a prerequisite ('REQUIRES BAOZI_LIVE=1'), but it does not explicitly explain when to choose this tool over alternatives like build_claim_affiliate_transaction or build_claim_winnings_transaction. The context is clear but lacks explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the transaction is 'unsigned' (implying no immediate on-chain effect) and includes a required environment flag, but does not cover preconditions like market resolution status or whether claim eligibility is checked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key requirement and clearly states the tool's purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter transaction builder with no output schema, the description covers the purpose and a constraint but misses return format details (e.g., what the built transaction looks like, how to sign/submit it). Sibling tools likely share a pattern, but the description alone is adequate yet not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions; it does not explain how the parameters relate to the claim-winnings process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Build unsigned transaction') and resource ('claim winnings from a resolved market'). It distinguishes from sibling tools like build_claim_refund_transaction and build_claim_race_winnings_transaction by implying standard market winnings, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('[REQUIRES BAOZI_LIVE=1]') and a general context ('claim winnings from a resolved market'), but lacks explicit guidance on when to use this tool over alternatives (e.g., standard vs. race markets, claims vs. refunds).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for disclosing behavioral traits. It only mentions a requirement (BAOZI_LIVE=1) and states the action, but does not explain whether the transaction is submitted immediately, what side effects it has, or what the returned data represents. For a transaction builder, this is a notable transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that immediately states the purpose and the critical requirement. There is no unnecessary wording or repetition, making it highly concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 3 parameters and no output schema, the description is adequate for understanding the basic action, but it lacks broader context about the proposal/resolution workflow (e.g., that this builds a transaction to be submitted later, or how it fits with finalize transactions). Given the existence of many sibling transaction builders, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100%, and all parameters have descriptive names and descriptions (e.g., 'winning_outcome_index' described as 'Index of winning outcome (0-based)'). The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Build transaction to propose race market outcome.' The inclusion of 'race' distinguishes it from sibling tool build_propose_resolution_transaction, and 'propose' sets it apart from resolve/finalize transaction builders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement 'REQUIRES BAOZI_LIVE=1' provides a usage prerequisite, implying this tool is only available in a specific environment. However, there is no explicit guidance on when to use this tool versus alternative tools like build_propose_resolution_transaction or build_finalize_race_resolution_transaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get detailed information', which implies a read-only operation but does not disclose side effects, required permissions, return format, or any constraints. For a tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. There is no waste or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter, the description is adequate but leaves gaps. It does not describe what 'detailed information' includes, nor does it provide return format or usage context. Unlike the high-scoring example that specifies scope and alternatives, this description lacks that extra context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, which already describes 'publicKey' as the Solana public key of the market account. The description's mention of 'by public key' adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific prediction market', and specifies the method 'by public key'. This distinguishes it from list_markets and other sibling tools that list or filter markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a public key and want details for a single market. However, it does not explicitly state when to use this tool versus alternatives like list_markets or get_race_market, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It says 'calculate', implying a read-only operation, but it does not explicitly state that no bet is placed or that there are no side effects. It mentions outputs but not safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences communicate the purpose and key outputs without waste. Front-loaded with the verb and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and some return values, but given no output schema and no annotations, it lacks details on exact return structure, market type (standard vs race), or any prerequisites. Adequate for a simple quote tool but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the 3 parameters, so the baseline is 3. The description adds no extra parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific action: 'Calculate expected payout for a potential bet' and lists key outputs ('profit, fees, and new odds'). Clear verb+resource, but doesn't explicitly differentiate from the sibling get_race_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for potential bets before placing them, but provides no explicit when-to-use vs alternatives, no exclusions, and no reference to sibling tools like get_race_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states what it returns, not behavior like read-only nature, return format, or any prerequisites. It adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, with no redundant information. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read tool, this description adequately specifies the resource and purpose. It lacks behavioral detail but is sufficient for an agent to decide whether to invoke it for timing rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty. The description doesn't need to explain parameters; baseline 4 is appropriate since there is no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'v7.2 timing rules and constraints for market creation,' using a specific verb and resource. It distinguishes the tool from sibling getters like get_parimutuel_rules by focusing on timing specifically, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use when timing rules for market creation are needed, but provides no explicit guidance on alternatives or conditions. It doesn't exclude other sibling tools, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says it lists all race markets on Solana mainnet, without mentioning whether it is read-only, how results are sorted, pagination, or whether the optional status filter defaults to all statuses. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the action. There is no filler or redundant information, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description conveys the core function adequately. However, it does not describe the return format or default filter behavior, which would help an agent fully understand the tool's behavior. It is acceptable but not exemplary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the only parameter (status) with an enum and description. The tool description adds little beyond the schema, only implying that 'all' markets are listed unless filtered. Since the schema already fully documents the parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and clearly identifies the resource as 'race markets', with a parenthetical explaining they are multi-outcome prediction markets. This distinguishes it from the sibling 'list_markets' tool, even though the alternative isn't named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no explicit guidance on when to use it versus list_markets or other market-listing tools. The distinction is implied by the name and the qualifier, but there is no direct statement about alternatives or when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It discloses the BAOZI_LIVE=1 requirement and implies that the tool only builds (not submits) a transaction. But it does not disclose wallet authorization, return value, or what happens if the creator does not exist, leaving some ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the key purpose and prerequisite. The second sentence largely duplicates schema requirements, but it is compact and does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter transaction builder with no output schema, the description states purpose, prerequisite, and required fields. However, it does not explain the return value or how it relates to transaction submission/execution, which an agent would need to invoke it correctly in a broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents all three params with constraints (max 32 chars, max 50 bps). The description adds only a repeat that display_name and default_fee_bps are required, omitting creator_wallet from that statement; this adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Build transaction to update creator profile') with a clear resource ('creator profile') and verb ('update'), distinguishing it from sibling build_create_creator_profile_transaction. The 'REQUIRES BAOZI_LIVE=1' prefix adds an environmental precondition but doesn't obscure purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an implied use case (updating creator profiles) and a clear prerequisite (BAOZI_LIVE=1), and repeats that both display_name and default_fee_bps are required. However, it does not explicitly contrast with sibling build_create_creator_profile_transaction or explain when not to use it, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' suggests read-only behavior, but no information is given about return format, pagination, paper trading implications, or any constraints beyond 'past season'. This is minimal disclosure for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose and target scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity query tool with two well-documented parameters. The description plus schema is sufficient for basic use, though it could hint at the relationship to get_arena_leaderboard or clarify what 'results' include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (season_id and paper) with 100% description coverage. The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('Agent Arena results') and scope ('specific past season by ID'). This differentiates it from sibling get_arena_leaderboard, which likely covers current standings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific past season by ID' implies historical use, but there is no explicit when-to-use/not-to-use guidance or mention of alternatives like get_arena_leaderboard. Usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but it does not mention any additional behavior like error handling, empty results, or authentication requirements. It provides minimal but not misleading transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's function. No superfluous words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description adequately covers the return value (all referred users) and the required input. It does not address error cases or edge cases, but the simplicity of the tool does not demand more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the sole parameter 'code' as 'Affiliate code', and the description does not add further semantic detail. Since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' with a specific resource ('all users referred by an affiliate code'), making its purpose unambiguous. It distinguishes itself from related tools like get_my_affiliates by explicitly referencing a code parameter rather than user context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as check_affiliate_code or get_my_affiliates. The description simply states what it does without any contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states the purpose, not what 'simulate' actually does (e.g., returns errors, gas estimates, whether it mutates anything). Missing details like output format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with the prerequisite in brackets and no extraneous words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the simulation returns or how to interpret errors. It lacks this critical information, and the operational behavior remains vague. The prerequisite and input coverage are helpful but not sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes both parameters (transaction as base64 string, user_wallet as public key). The description adds no additional semantics, so baseline score of 3 is appropriate due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Simulate') and resource ('a transaction') with a clear intent ('before signing to check for errors'). Among siblings like build_* or validate_*, this operation is clearly distinct as a pre-signing sanity check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states a required environment condition (BAOZI_LIVE=1) and contextualizes usage as before signing. It does not name alternatives, but the purpose is clear enough that an agent can infer when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action without describing side effects, return values, failure modes, or whether it is read-only. It does not clarify what happens on validation failure or what the output looks like, leaving significant ambiguity for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the main verb and resource. Every word is relevant and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, yet the description provides only a one-line summary. It does not explain how validation works for different market types (event vs measurement), what constitutes valid timing, or what the return format is. For a validation tool of this complexity, the description is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all six parameters, so the baseline is 3. The description adds no parameter-specific detail beyond saying they are validated against timing rules, which is minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('validate') and a resource ('market parameters') plus a specific scope ('v7.2 timing rules'). It distinguishes itself from sibling tools like validate_market_question, which focuses on the question text, and validate_bet, which focuses on bets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when market parameters need validation against timing rules. However, it does not explicitly mention alternatives or when-not-to-use conditions, though its specificity to timing rules provides clear context that other validation tools (e.g., validate_market_question) are for different aspects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It states "Build transaction" which implies a construction/preparation operation rather than direct execution, but it does not disclose more (e.g., whether this requires special permissions, is irreversible, or what the output format is). The behavioral transparency is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly to the point, and includes the crucial prerequisite. Every word earns its place, with no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 parameters, no output schema), and the description conveys the core action and a key condition. However, it does not explain what the returned transaction object contains or any next steps (e.g., submit via simulate_transaction). Given the lack of output schema and minimal annotations, the description is slightly under-specified but not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions), so the baseline is 3. The description itself does not add any extra parameter context beyond what is in the schema; it neither clarifies nor contradicts the parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: "Build transaction to add user to private market whitelist." It uses a specific verb+resource and explicitly distinguishes the target (private market whitelist) from similar sibling tools like build_remove_from_whitelist_transaction or build_add_to_race_whitelist_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite ("[REQUIRES BAOZI_LIVE=1]") which is useful, but it does not mention when to use this tool versus alternatives (e.g., race whitelist versions). Usage context is implied by the name and sibling list, but no explicit guidance or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that the transaction is unsigned (implying no immediate submission) and notes an environment requirement, providing some behavioral context. However, it omits details about the transaction payload, validation, or subsequent signing steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only a brief environment note and a two-part purpose statement. Every word adds value, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 2 parameters, but the lack of an output schema means the description should explain what the built unsigned transaction entails. It doesn't describe the returned format or how to use the transaction afterward, leaving gaps despite the clear core purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (code and user_wallet) are fully described in the schema (100% coverage). The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') and clearly identifies the resource ('unsigned transaction to claim affiliate earnings'). It distinguishes this tool from sibling tools like build_claim_winnings_transaction by explicitly focusing on affiliate earnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for claiming affiliate earnings and provides a prerequisite ([REQUIRES BAOZI_LIVE=1]), but it does not explicitly compare to alternatives or state when not to use this tool. No exclusionary guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the hash is 'random' but does not disclose whether the operation has side effects, requires authentication, or simply returns a string. The return format and possible constraints (length, character set) are also omitted. This is a minimal description that does not go beyond the verb 'generate'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately states the action and purpose, and contains no filler or redundant information. It is perfectly concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters) and absence of an output schema, the description should at least clarify what the tool returns (e.g., the format of the hash) or any side effects. It only says 'random invite hash,' which may leave the agent uncertain about the exact output. The description is adequate but not complete enough to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the baseline for 0 params is 4. The description does not need to add parameter-level detail because none exist. It correctly remains agnostic about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('invite hash') with a clear context ('for private market access control'). It fully distinguishes the tool from the many transaction-building and affiliate-related siblings. This is a precise and unambiguous statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context (private market access control) but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it. There are no exclusions or references to sibling tools. The usage is implied but not explicitly contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds the critical cost/fee behavior (0.001 SOL via x402), but does not disclose other traits like output format, rate limits, or consequences of omitting payment_tx. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The main purpose is front-loaded, and the cost detail is appended as a separate sentence. Every part contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must convey what is returned and any prerequisites. It lists the data components (comment sentiment, bet momentum, pool trends) and mentions the fee, but lacks details about the response structure and the payment flow (e.g., how to supply payment_tx, what happens without it), which the schema partially addresses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal param-specific meaning beyond the schema, only implicitly linking payment_tx to the SOL cost. The market parameter is already well described in the schema as a public key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Get market sentiment analysis', elaborating with the included components (comment sentiment, bet momentum, pool trends). This distinguishes it from sibling intel tools like whale moves, resolution forecast, and market alpha by the content focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for sentiment analysis but does not explicitly state when to use it over alternatives or mention any exclusions. The payment cost and protocol are mentioned, but there is no guidance on switching to other intel tools for different insights.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Get' implies a read-only operation, but there's no disclosure of return format, data structure, or any other behavioral nuance. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, no unnecessary words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Low complexity (0 params, no output schema), but the description leaves 'layers' undefined and doesn't hint at the response shape. Adequate for a simple getter, but could be more complete with a brief note on what 'layers' are or the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and an empty schema, so schema coverage is trivially complete. The description doesn't need to add parameter details, and the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' + resource 'platform fee rates' + scope 'all layers'. Clearly distinguishes from sibling get_creation_fees by focusing on platform-wide rates rather than creation-specific fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_creation_fees or get_timing_rules. The description only states what it does, not when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'calculate' suggests a read-only, non-mutating operation, but it does not disclose whether it uses current market data, accounts for fees, or if any state changes occur. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded with the primary verb and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three well-described parameters, the description is mostly complete, but it lacks usage guidance, output format expectations, or behavioral caveats. The absence of an output schema and annotations means the agent must infer details about the payout calculation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all three parameters (amount, market, outcomeIndex). The description adds no additional parameter semantics beyond what the schema specifies, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates expected payout for a race market bet on a specific outcome. It uses a specific verb ('calculate'), identifies the resource (race market bet), and the outcome scope, distinguishing it from sibling tools like get_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for race market bets, but does not explicitly mention when to use this over alternatives such as get_quote for regular markets. No exclusions or alternative scenarios are provided, leaving the context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Validate' implies a read-only check, but it does not state what happens on invalid parameters (e.g., throws an error, returns a boolean), whether it has side effects, or what the output format is. This lack of detail is a significant gap for an agent deciding how to use the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and usage timing. Every word is meaningful and there is no unnecessary repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool with fully described parameters, the description is mostly sufficient. However, with no output schema and no annotations, it would benefit from stating what the tool returns or how errors are surfaced. Still, the simplicity and clear 'before building transaction' context make it adequate for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (100% coverage), so the description does not need to repeat them. The phrase 'bet parameters' adds no additional semantic detail beyond the schema, keeping the score at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Validate bet parameters before building transaction.' It uses a specific verb ('Validate') and resource ('bet parameters'), and the 'before building transaction' phrase distinguishes it from sibling tools like 'build_bet_transaction' and 'validate_market_params'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying when to use it: 'before building transaction.' It does not explicitly name alternatives or exclusions, but the context implies it is a pre-flight check for bet creation, which adequately differentiates it from validation of market parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the key behavior (builds an unsigned transaction, not signed/submitted) and the BAOZI_LIVE=1 prerequisite. However, it does not describe output format, error conditions, or permission requirements, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the prerequisite, and contains zero redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, and the description provides no indication of return value or side effects. The BAOZI_LIVE flag is mentioned but not explained. This is insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all 5 parameters. The description adds the 'invite-only' context, which hints at the role of invite_hash, but otherwise repeats no parameter details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned transaction to create a Private (invite-only) market, using a specific verb and resource. It distinguishes from sibling creation tools (lab, race) via the 'Private' and 'invite-only' qualifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '[REQUIRES BAOZI_LIVE=1]' prerequisite provides a clear conditional for when the tool can be used, and the 'Private (invite-only)' phrasing establishes the market type context. However, it does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It states the tool builds an 'unsigned transaction' (not broadcasting) and imposes a prerequisite flag (BAOZI_LIVE=1), which are useful behavioral traits. However, it does not mention side effects, permission requirements, or what happens to the built transaction, leaving moderate gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core function and key prerequisite. Every word adds value, with no repetition of schema details or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction-building tool with well-documented parameters and no output schema, the description is concise and sufficient for an agent to understand the tool's role and main constraint. However, it does not explain the BAOZI_LIVE flag or the structure of the returned unsigned transaction, which are minor gaps given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with descriptions for all 5 parameters, so the baseline is 3. The description adds a high-level constraint ('2-10 outcomes') that reinforces the schema's outcomes description, but it does not introduce new semantic meaning beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') with a specific resource ('unsigned transaction to create a Race (multi-outcome) market') and adds a constraint (2-10 outcomes). This clearly distinguishes it from sibling tools like build_create_lab_market_transaction and build_create_private_market_transaction by naming the Race market type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating Race markets and notes a prerequisite ('REQUIRES BAOZI_LIVE=1'), but it does not explicitly mention when to choose this over alternatives or when not to use it. No alternative tools are referenced, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It states the operation is a 'Get' (implying read-only) and specifies 'all' claimable winnings and refunds, but does not disclose return structure, pagination, or any side effects (likely none). This is adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the verb and resource, containing no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description adequately conveys the tool's purpose and scope. It could optionally mention the response format, but the low complexity makes the current description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'wallet' is fully described in the schema as a 'Solana wallet address' (100% coverage). The description adds no additional semantic 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and identifies the specific resource 'all claimable winnings and refunds' scoped to 'a wallet'. This clearly distinguishes it from the many build_claim_* transaction tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to retrieve claimable amounts for a wallet, but does not explicitly state when to use it over alternatives, such as before building a claim transaction. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does disclose the cost (0.003 SOL via x402), a significant behavioral trait. However, it doesn't explicitly state that the tool is read-only or that payment_tx is required for actual data vs. pricing info, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no extraneous words. It efficiently points to the data content and the payment requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with full schema coverage, communicates the tool's purpose and cost. It provides some return-content clues via the listed signal types, though it doesn't describe the payment flow (e.g., omit payment_tx for pricing) or return shape; given the low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the baseline is 3. The description doesn't add additional parameter semantics beyond what the schema already provides for market and payment_tx.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('cross-market alpha signals'), and enumerates content (correlation analysis, category skew, alpha opportunities). This clearly distinguishes it from sibling intel tools focused on sentiment, whale moves, or resolution forecasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance about when to use this tool versus other intel tools (e.g., get_intel_sentiment). The description implies usage by naming the specific alpha signals, but does not provide exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not state any permissions needed, pagination limits, or what the return structure looks like. This is a significant gap for a tool that retrieves data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the core function ('get all betting positions') and a key feature ('including win/loss stats') without any filler or fluff. It is front-loaded and perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one simple parameter) and no output schema, the description is nearly sufficient. It covers the purpose and the wallet filter, though it does not explain the response format or any edge cases like empty results. This is acceptable for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a complete description for the single parameter ('wallet' as 'Solana wallet address'), covering 100% of the parameter meaning. The description adds no extra detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource 'all betting positions for a wallet' and adds 'including win/loss stats', which differentiates it from sibling tools that focus on transactions, leaderboards, or market details. The scope is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for retrieving positions tied to a specific wallet, providing clear context for when to use it. No explicit exclusions or alternatives are mentioned, but the wallet-specific language makes the use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses the possible return values (resolved, disputed, pending), which is helpful, but it does not mention potential outcomes like unknown/invalid markets, whether it is read-only, or any error/edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every word adds value, and it is appropriately sized for a simple getter tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description adequately explains what the tool returns by listing the possible statuses. It could be more complete by mentioning whether the status is returned as a string or whether a market not in a resolution state yields a specific value, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'market' parameter already described as 'Market public key'. The description adds minimal semantic value beyond restating 'for a market', so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('resolution status for a market') and lists the possible statuses (resolved, disputed, pending). It clearly distinguishes this single-market status lookup from sibling tools like get_disputed_markets or get_market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need the resolution status of a specific market. However, it does not explicitly state when to prefer this over alternatives such as get_market, get_disputed_markets, or get_markets_awaiting_resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns ('questions, odds, pools, status') and that it lists all markets, but it does not mention any side effects, authentication requirements, rate limits, pagination behavior, or other traits. The description is minimal and does not go beyond the obvious read-only nature of a 'list' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes return fields without any filler. Every sentence earns its place. It is concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 optional parameters, no output schema, no annotations). The description covers the key aspects: what it lists, network, type, and the fields it returns. It does not mention pagination or result structure, but for a basic list endpoint, the description is adequate. The only minor gap is that it doesn't explicitly state that filters narrow the 'all' set, but the schema clarifies the default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters ('layer' and 'status') have descriptions in the input schema. The tool description does not add any extra semantic meaning to the parameters; it simply says 'List all' without explaining how filters affect behavior. Since the schema already documents the parameters thoroughly, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all Baozi prediction markets (boolean YES/NO) on Solana mainnet.' It uses a specific verb ('List') and resource ('Baozi prediction markets'), and includes scope ('all') and network ('Solana mainnet'). It also distinguishes from the sibling 'list_race_markets' by explicitly mentioning 'Baozi' rather than 'race' markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it does not explicitly provide when/when-not guidance or mention alternatives like 'list_race_markets'. While the mention of 'Baozi' implicitly differentiates from race markets, there is no clear 'use this for X, use that for Y' guidance. The defaults for filters are only in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool builds a transaction (does not submit it) and requires the BAOZI_LIVE environment variable. However, it does not mention permissions, side effects, or what the returned transaction looks like, leaving some gaps for a mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with a notable environment prerequisite in brackets. Every word earns its place, and the most critical information is front-loaded. It is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential purpose and one requirement, but it lacks explicit guidance on prerequisites such as ensuring the council member has already voted. It also does not explain the return value, which could be helpful since there is no output schema. Overall, it is minimally complete but leaves some operational context ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all three parameters. The description adds minimal extra meaning beyond the schema, only reinforcing that the wallet is a council member and the action is a vote change on a race market. Thus the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build transaction for council member to change their vote on a race market dispute.' This specifies both the action (build/change vote) and the resource (council vote on race market), and distinguishes it from siblings like build_vote_council_race_transaction (initial vote) and build_change_council_vote_transaction (non-race).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is specifically for changing a council member's vote on a race market dispute, and it includes a prerequisite ('[REQUIRES BAOZI_LIVE=1]'). However, it does not explicitly name alternatives or state when not to use it, though the context strongly implies it is for existing votes on race markets only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses a key environment requirement and the fact that it 'builds' a transaction (implying construction rather than execution), but it does not explain return format, whether the transaction is signed/unsigned, or any side effects. This is adequate but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the critical requirement flag and immediately states the purpose. There is no wasted wording or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input schema with three parameters and no nested objects, but no output schema exists. The description covers the core purpose and context, yet it does not specify what the tool returns (e.g., a serialized transaction) or whether it submits the transaction. Given the absence of an output schema, these details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (market, new_vote_yes, voter_wallet) already described in the input schema. The description adds no additional parameter-level semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build transaction') and identifies the exact resource and action: a council member changing their vote on a boolean market dispute. This clearly distinguishes it from sibling tools like build_vote_council_transaction (initial vote) and build_change_council_vote_race_transaction (race markets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear prerequisite ('REQUIRES BAOZI_LIVE=1') and specifies the context: changing a vote on a boolean market dispute. It does not explicitly name alternatives or exclusions, but the phrasing 'change their vote' and 'boolean market' provides sufficient guidance on when to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: the transaction is unsigned, implying no submission or state change. It also mentions the environmental requirement. However, it does not elaborate on side effects, error conditions, or what happens if the market is not resolved or winnings already claimed, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential requirement and purpose immediately, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should indicate what the tool returns. It only says 'Build unsigned transaction', which implies the output is a transaction but does not specify format or serialization. The prerequisite flag adds context, but the lack of return-value information and edge-case guidance makes it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no additional meaning beyond what the schema provides; it does not explain how 'race_market', 'position', and 'user_wallet' interact or any formats beyond the schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned transaction to claim winnings from a resolved race market, using a specific verb and resource. It distinguishes itself from sibling tools like build_claim_winnings_transaction (non-race) by specifying 'race market'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for claiming winnings from a resolved race market. It also includes a prerequisite flag [REQUIRES BAOZI_LIVE=1], which is a usage condition. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It conveys key traits: the transaction is unsigned (no immediate submission) and requires BAOZI_LIVE=1, but it omits details about returned data, validation checks, or any prerequisites beyond the flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence of ~14 words, with the precondition in a leading bracket. No filler or redundancy; it's optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a build-transaction tool with three simple parameters and no output schema, the description provides core purpose and a precondition. However, it doesn't describe the return value format or differentiate explicitly from race refund/claim variants, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter descriptions in the schema already define market, position, and user_wallet. The description adds no additional parameter-level guidance, so it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Build') and resource ('unsigned transaction'), with a precise scope ('claim refund from cancelled/invalid market'). It distinguishes this from sibling claim/winnings/race transaction builders by specifying the refund source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates use for refunds from cancelled/invalid markets and flags the BAOZI_LIVE=1 precondition. However, it does not explicitly rule out alternatives like build_claim_race_refund_transaction or build_claim_winnings_transaction, leaving some exclusion implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey safety and behavior. 'Check' implies a non-mutating read, but it does not explicitly state that no state changes occur, nor does it describe edge cases like case sensitivity or what exactly constitutes 'available.' The simple wording is adequate but lacks deeper behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. Every word contributes to the meaning, and the core purpose is front-loaded in the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter, but there is no output schema and the description does not state what the check returns (e.g., a boolean). The agent can infer the likely return type, but the lack of explicit return information leaves a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the 'code' parameter is fully described with format constraints. The description adds no parameter-level semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('affiliate code') with a clear purpose ('available for registration'). It distinguishes this from sibling tools like suggest_affiliate_codes by focusing on validating a specific code rather than generating options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'available for registration' provides clear context: use this when deciding whether a proposed code can be registered. It implies the appropriate moment to invoke, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation and the resource indicates the output, but it does not disclose return structure, authentication requirements, or any side effects. For a simple getter this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One succinct sentence that front-loads the verb and resource, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but covers the core purpose. However, with no output schema or annotations, it does not explain the return format (e.g., fee amounts per layer) or disambiguate from get_platform_fees, leaving some contextual gaps for a zero-parameter getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Per the rubric, zero parameters receives a baseline of 4; the description adds no parameter semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'market creation fees' and explicitly enumerates the layers (Official, Lab, Private), making it clear what the tool does and distinguishing it from sibling tools like get_platform_fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use guidance or contrast with alternative fee-related tools such as get_platform_fees. The intended usage is implied by the name and description, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that no SOL is required and that submissions are scored on calibration accuracy, which are useful behavioral details. However, it does not mention whether the submission is on-chain/off-chain, if it is reversible, or any other side effects, leaving gaps for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and resource, and every sentence adds value. There is no fluff or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally convey what happens after submission (e.g., acknowledgment, ID, or error). It covers purpose, cost, and scoring, but omits return-value behavior and any preconditions beyond the required parameters, leaving the agent to guess the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter-level detail beyond what the schema already provides (e.g., confidence range, predicted_side enum), so no extra credit is earned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit'), the object ('a paper (simulated) prediction'), and the destination ('to the Agent Arena'). It also clarifies that no SOL is required, distinguishing it from real betting tools among its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for simulated predictions without real funds ('No SOL required'), which gives clear context. It does not explicitly name alternatives or exclusions, but the contrast with real bet builders is evident from the 'paper' and 'No SOL required' framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral context. It discloses a required feature flag (BAOZI_LIVE=1) and the batching behavior, but it does not state whether the tool submits the transaction or only builds/serializes it, nor does it mention any side effects. It's adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear prerequisite tag. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a builder tool with two well-documented parameters, the description gives the core purpose and a usage prerequisite. It doesn't describe the return value or execution semantics, but given the sibling tool family and the simple parameters, the description is reasonably complete for selection and initial understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of both parameters, so the description does not need to explain them. The description adds little beyond the schema; it reinforces that the tool batches claims, but it doesn't elaborate on the structure of the claims array or the wallet parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: building a single transaction to claim multiple positions at once. The verb 'build' plus resource 'transaction' and the batch action distinguish it from sibling single-claim transaction builders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly specifies the use case: claiming multiple positions at once in a single transaction. While it doesn't name alternatives, the contrast with sibling tools like build_claim_winnings_transaction and build_claim_refund_transaction implies when this batch tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses that the tool builds an 'unsigned transaction' (no submission) and notes an environment requirement (BAOZI_LIVE=1). However, it does not explain other behavioral aspects such as validation, affiliate handling, or what the returned transaction looks like. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly communicates the essential purpose and a critical requirement. Every word adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the lack of an output schema, and no annotations, the description covers the core function and key prerequisite. It does not explain the full lifecycle (e.g., how the unsigned transaction is used), but for a transaction builder, the missing details are not critical for selection or invocation. It is reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema—it clarifies the market type as boolean, which aligns with the 'outcome' enum, but it does not provide additional syntax or parameter-level details. It adequately supports but does not enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Build[s] unsigned transaction for placing a bet on a boolean (YES/NO) market.' It specifies the verb (build), resource (unsigned transaction), and distinct scope (boolean market), which differentiates it from siblings like build_race_bet_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it is specifically for boolean (YES/NO) markets. It also includes a prerequisite ('REQUIRES BAOZI_LIVE=1'). While it does not explicitly name alternative tools for non-boolean markets, the market type is specified, giving the agent enough context to choose appropriately among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal a notable side effect (all bettors can claim refunds), and the requirement flag adds context. But it does not mention permissions, reversibility, or what the transaction actually does beyond cancellation, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with a clear precondition and behavior. It is front-loaded with the requirement flag and avoids any filler. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple transaction builder with three parameters and no output schema, the description is mostly sufficient. It explains the core action and a key consequence. However, it does not differentiate from sibling tools like build_cancel_market_transaction or build_close_race_market_transaction, which could lead to confusion in a tool-rich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (race_market, reason, authority_wallet) already described in the schema. The description adds no parameter-specific nuances beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Build transaction to cancel a race market', which is a specific verb+resource combination. It distinguishes itself from sibling tools like build_cancel_market_transaction by specifying 'race market', and from build_close_race_market_transaction by using 'cancel' rather than 'close'. The additional clause 'All bettors can claim refunds after cancellation' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite ('REQUIRES BAOZI_LIVE=1') and explains the consequence (bettors can claim refunds), which helps an agent decide when to use this tool. However, it does not explicitly compare with alternatives or state when not to use it, so it lacks an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses admin-only access, BAOZI_LIVE requirement, and 'Build transaction' implies it constructs rather than executes. It stops short of explaining side effects or return behavior but provides meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the critical constraints. Every piece of information earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 4 parameters and no output schema. The description includes key access constraints and the 'build transaction' nature. It lacks detail about optional parameters or post-build steps but is adequate given schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters, so the schema already documents each parameter. The description adds no extra semantic meaning beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Build transaction') and resource ('race market deadline'), clearly distinguishing it from sibling tools like build_extend_market_transaction. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides important context: ADMIN ONLY and requires BAOZI_LIVE=1, plus protocol admin signature. However, it doesn't explicitly mention when to prefer this over non-race alternatives or give exclusion criteria; usage is implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden but only discloses a prerequisite (BAOZI_LIVE=1) and a timing condition. It does not mention potential errors, side effects, or authorization requirements beyond what the schema hints at, leaving room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear prerequisite notation, delivering the essential message without waste. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter transaction builder with full schema coverage and no output schema, the description provides adequate context for usage. It lacks explicit differentiation from the race-market variant, but the naming and the 'after dispute window' qualifier sufficiently guide the agent in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (market public key and caller wallet, with the note that anyone can finalize). The tool description adds no additional semantic value beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: building a transaction to finalize a resolution after the dispute window. The verb 'build' and resource 'finalize resolution' are specific and distinct from siblings like propose or resolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the timing context ('after dispute window') and requires an environment flag (BAOZI_LIVE=1), implying when to use it. However, it does not explicitly name alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It reveals the output size, content (market odds, optional position data, affiliate branding), and that it returns a URL. It does not mention error conditions, rate limits, or potential side effects, leaving some transparency gaps for a read-only generator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first stating the purpose and output, and the second adding usage scenarios. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers purpose, output format, and use cases, given the simple nature of the tool. It lacks details on error handling or URL behavior, but this is minor for a static image URL generator. The 100% parameter schema coverage helps compensate for the absent output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter clearly described (e.g., 'Market public key (Solana PDA)'). The description adds some context by linking params to card content (affiliate branding, position data), but it doesn't go beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a share card image URL for a market' and specifies the output format 'PNG URL (1200x630)'. It also distinguishes this tool from sibling transaction builders by focusing on image generation for social media, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage context is provided: 'Use this to create viral social media posts — embed the image in tweets, Telegram messages, AgentBook posts, or Discord embeds.' However, it does not mention when not to use the tool or name alternatives, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the ranking basis (calibration 40%, ROI 30%, volume 15%, consistency 15%) and that it is current/weekly, but omits details like authentication, rate limits, or return structure. For a read-only getter, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the tool's core purpose and scoring details without fluff. Highly compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full parameter coverage and no output schema, the description is complete enough. It explains what the leaderboard is, the scoring weights, and the temporal scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters (limit and paper) with descriptions. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Agent Arena weekly leaderboard'), clearly distinguishing its function. It also explains the composite score formula, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that this tool retrieves the leaderboard, but does not explicitly discuss when to use it instead of alternatives or exclusions. No conflicting sibling tools exist, so the context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It indicates a read-only operation ('List') and clearly states the resource, but it does not disclose any additional behavioral details such as pagination, authentication requirements, or output structure. This is adequate for a simple list tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys its purpose with no redundant words or filler. It is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple: no parameters, no output schema, and no annotations. The description sufficiently conveys that it lists disputed markets, but it leaves some ambiguity about what counts as 'under dispute' versus related statuses like 'awaiting resolution', and it does not clarify any relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Since there are no parameters to describe, the description does not need to add parameter-level detail, and the baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all markets currently under dispute.' It uses a specific verb ('List') and clearly identifies the resource and scope, distinguishing it from sibling tools like list_markets and get_markets_awaiting_resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used for retrieving disputed markets, but it does not explicitly state when to use it over alternatives like get_markets_awaiting_resolution. There is no mention of exclusions or comparative context, so guidance is merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the 0.005 SOL cost and x402 payment protocol, which is critical behavioral information. However, it does not describe the response format or other potential behaviors like rate limiting or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of about 14 words. It front-loads the purpose and adds cost information without any redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid tool with no output schema, the description covers the key aspects: purpose, cost, and included output fields. The payment_tx parameter description in the schema adds the omit-for-pricing behavior. It lacks details on return structure or error handling, but is largely adequate given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both 'market' and 'payment_tx' have descriptions. The tool description adds no additional parameter semantics; it only restates the purpose without detailing how the parameters are used beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'resolution forecast', listing concrete outputs (closing time, tier, implied probability, prediction). This clearly distinguishes it from siblings like get_resolution_status, which likely returns current status rather than a forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for obtaining resolution forecasts, but it does not explicitly state when to use it over alternatives such as get_intel_market_alpha or get_resolution_status. No exclusions or comparative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List' clearly implies a read-only operation, and no side effects are suggested. Still, it does not explicitly state that it is a read-only action or disclose any other behaviors like pagination or ordering, leaving some ambiguity about edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without any redundancy or filler. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides complete context for understanding its core function. It communicates the exact subset of markets returned, which is sufficient for an agent to select and invoke the tool correctly. However, it does not elaborate on the structure of the returned data, which might be useful but is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is empty. The description effectively communicates that no input is required. This matches the baseline for parameterless tools, and no further parameter details are necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the specific resource ('all closed markets awaiting resolution'), distinguishing it from sibling tools like get_market or list_markets which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description: use it when you need the list of closed markets awaiting resolution. However, it does not explicitly note when to prefer this over alternatives such as list_markets or get_disputed_markets, so there is room for more direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not elaborate on return format, edge cases, or any prerequisites beyond the wallet parameter. It does not contradict any annotations and is minimally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action and scope directly, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one well-documented parameter and no output schema, the description is largely sufficient. It could optionally mention the shape of the returned data or any filters, but the low complexity means these are not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'wallet' with its own description 'Wallet address'. The tool description adds the ownership context ('owned by a wallet'), which provides a small semantic nuance beyond the schema, but otherwise the schema already conveys the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'all affiliate accounts owned by a wallet', which distinctly defines its scope and differentiates it from sibling tools like get_affiliate_info or get_referrals. The ownership qualifier 'owned by a wallet' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the usage context: when you need all affiliate accounts associated with a specific wallet. It does not explicitly list alternatives or exclusions, but for a simple read-only list operation, the context is clear enough for an agent to choose it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly implies a read-only operation and lists the specific content returned, but it does not disclose any potential side effects, error conditions, rate limits, or auth requirements. For a simple getter, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets straight to the point, listing the key output categories. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description provides enough context about the tool's purpose and the content returned (outcome labels, pools, odds). It lacks details like return format or pagination, but the tool's simplicity makes it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter 'publicKey' described as 'Race market public key' in the schema. The tool description adds no additional meaning to the parameter beyond what is already in the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get detailed info about a race market including all outcome labels, pools, and odds.' It specifies the exact resource (race market) and the key data returned, distinguishing it from list-type siblings like list_race_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for fetching detailed information about a single race market, which is a distinct use case from listing all race markets. However, it does not explicitly mention alternatives or exclusions, such as when to use get_market for non-race markets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure. It explicitly states the transaction is 'unsigned', indicating it does not submit or execute, and the '[REQUIRES BAOZI_LIVE=1]' prefix is an environmental prerequisite. This adds meaningful context beyond the schema, though it omits further details like serialization format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. The bracketed requirement is placed at the start, and every word contributes meaning: it names the action, the target, the market type, and the unsigned nature. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must cover return behavior and prerequisites. It does cover the 'unsigned' aspect and the BAOZI_LIVE requirement, but it does not explain what the returned transaction looks like (e.g., serialized format) or whether the bet is validated before building. This is a minimum-viable description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters (market, amount_sol, user_wallet, outcome_index, affiliate_code). The description adds no additional insight into parameter semantics or relationships, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Build') and resource ('unsigned transaction for placing a bet on a race (multi-outcome) market'), which clearly distinguishes it from the sibling tool for standard bets (build_bet_transaction). The scope is precise and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for race (multi-outcome) markets and includes the prerequisite '[REQUIRES BAOZI_LIVE=1]'. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that this is an admin-only operation requiring a protocol admin signature and a specific environment flag, which are important context. It doesn't detail the transaction's contents or side effects, but as a transaction builder, this is acceptable for the agent to proceed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It places the critical environment requirement in brackets at the start, followed by the admin-only designation and the core purpose. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, but the description covers the essential conditions (admin, signature, environment flag) and the action. It does not explain what the returned transaction looks like or how it should be used, but given the simplicity of the inputs and the consistency of sibling transaction builders, the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all three parameters (code, active, user_wallet). The description adds no further parameter-level meaning beyond what the schema already states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: building a transaction to activate or deactivate an affiliate. The verb 'build' and the resource 'transaction to activate/deactivate affiliate' are specific and unambiguous, distinguishing it from sibling build_*_transaction tools that handle different actions like voting, whitelisting, or market creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides crucial usage prerequisites: it requires BAOZI_LIVE=1 and admin access, and it explicitly notes the need for a protocol admin signature. While it doesn't explicitly list alternatives or when-not-to-use conditions, the purpose is specific enough that the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the permission requirement, the refund claim outcome for bettors, and the environment prerequisite, which are meaningful behavioral details beyond the basic build intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing three short sentences that each add distinct information: environment requirement, action and refund consequence, and authorization constraint. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description provides essential operating conditions (environment, permissions, refunds) and parameter coverage from schema. It could mention the return type, but 'build transaction' implies the output is a transaction to be signed, which is common among sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context that the authority wallet must be creator/admin, but this is already stated in the param description. No further parameter-specific semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: building a transaction to cancel a boolean market. It distinguishes from siblings like build_close_market_transaction by specifying boolean market cancellation and the post-cancellation refund behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes a required environment flag (BAOZI_LIVE=1) and restricts usage to creator/admin, providing clear context for when this tool is applicable. However, it does not explicitly contrast with alternatives such as build_close_market_transaction or mention when cancellation is preferred over other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the transaction is unsigned, implying no on-chain side effects, and includes the critical environment prerequisite [REQUIRES BAOZI_LIVE=1]. This adds valuable behavioral context beyond the tool's name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the essential environment requirement, and conveys purpose and context without any unnecessary words. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction-builder tool with simple parameters and no annotated safety profile, the description provides enough context for an agent to select and invoke it correctly: what it does, when to use it, and the environment requirement. The lack of an output schema is acceptable since the return value is implied as an unsigned transaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters (position, race_market, user_wallet) with clear explanations. The tool description adds no additional parameter-specific meaning, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Build', the resource 'unsigned transaction', and the specific purpose 'to claim refund from cancelled race market'. It distinguishes itself from sibling tools like build_claim_race_winnings_transaction and build_claim_refund_transaction by specifying the race-specific and refund-after-cancellation context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a race market has been cancelled and a refund must be claimed. While it does not explicitly name alternatives or exclusions, the phrase 'from cancelled race market' provides clear contextual guidance, and the sibling naming pattern further differentiates usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the payment cost (0.002 SOL via x402) and the data threshold (positions > 1 SOL). It doesn't explicitly state read-only behavior, but 'get' strongly implies it. The cost disclosure is valuable beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant wording. It front-loads the core purpose and immediately follows with the key cost constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description hints at return content ('whale sentiment split'). It includes the essential payment context. It could be more explicit about return fields, but for a simple get tool, it's adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 itself adds no extra parameter meaning; the schema already explains 'Market public key' and 'Payment transaction signature... Omit to get pricing info' more thoroughly than the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get whale position data for a market' with a specific verb and resource. The parenthetical '(positions > 1 SOL, whale sentiment split)' adds concrete scope and helps distinguish it from sibling intel tools like get_intel_sentiment or get_intel_market_alpha.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when whale position data is needed. The mention of cost and payment protocol adds an important usage consideration. It doesn't explicitly name alternatives or exclusions, but the clear purpose is enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and discloses that the tool builds unsigned transactions, validates against v7.2 rules, and blocks creation when required fields are missing. This is rich context that helps the agent understand side effects and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the critical requirement, and every sentence adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction builder with no output schema, the description covers the essential purpose, key constraints, and validation behavior. A minor gap is that it does not explicitly describe the format of the returned unsigned transaction, but 'Build unsigned transaction' makes this implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all eight parameters, including the conditional requirement for event_time (Type A) and measurement_start (Type B). The description reiterates these requirements but does not add new parameter-level meaning beyond emphasizing the importance of the market_type/timing relationship.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build unsigned transaction to create a Lab (community) market,' using a specific verb and resource. It distinguishes itself from sibling market creation tools by explicitly mentioning 'Lab (community)' and by noting v7.2 rule validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite (BAOZI_LIVE=1) and mandatory combination of market_type with the corresponding timing field, which are essential usage conditions. However, it does not explicitly contrast with alternative market creation tools (e.g., private or race markets), though the 'Lab' label implies the intended scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important behavioral quirk: without timing parameters, validation may falsely pass invalid markets. It also states what it returns (blocked status and reason). It does not explicitly say it's read-only, but 'BEFORE attempting to create' implies that. This is useful beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear one-sentence purpose, a one-sentence return behavior, and an important usage warning. Every sentence adds value, and the 'IMPORTANT' note is appropriately highlighted without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, key behavioral caveat, and critical parameter dependencies, which is sufficient for a validation tool with a moderately complex schema. It does not describe the exact return structure, but with no output schema, this is a minor gap. Overall, it provides enough context to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful semantic context by explaining the conditional requirement between market_type, event_time, measurement_start, and closing_time, and the impact of omitting them. This goes beyond the individual field descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('validate') and resource ('market question') against 'v7.2 rules', and explicitly frames it as a pre-creation check. It also distinguishes from sibling tools like validate_market_params and preview_create_market by focusing on validation rather than parameter checking or previewing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'BEFORE attempting to create it', signaling when to use the tool. It also gives explicit guidance about required timing parameters and warns about the consequence of omission. However, it does not describe alternative tools or when not to use this one, so it lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds important context by revealing the version (v7.2), the content (blocked terms, required data sources, validation rules), and the consequence of ignoring the rules (invalid markets will be rejected). This goes beyond the tool name and provides meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with a clear purpose and followed by a critical warning. Every clause adds value: the version, the scope ('Lab market creation'), the warning to read it before creating markets, and the specific contents of the rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description is complete enough for an agent to understand what it returns and why it matters. It includes the version, the use-case, and the critical prerequisite, making it self-sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema's empty properties are 100% covered by definition. According to the rubric, 0 params yields a baseline of 4. The description does not need to explain parameters, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specic verb ('Get') and identifies the exact resource ('v7.2 parimutuel rules for Lab market creation'). It clearly distinguishes this tool from siblings like 'get_timing_rules' or 'validate_market_params' by focusing on the parimutuel rules and the Lab market creation context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'CRITICAL: Read this BEFORE creating any market.' It clearly states the prerequisite nature and the purpose of the rules. However, it does not explicitly name alternatives or mention when not to use this tool, so it falls slightly short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly states the tool does NOT build a transaction, implying non-mutating behavior, and that it validates parameters. This is valuable behavioral insight, though it could also mention error handling or return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total: first states purpose and behavior, second gives usage direction. The critical Lab market constraint is highlighted with 'IMPORTANT.' No wasted words; all information is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of a detailed schema, the description covers the key usage and behavioral aspects. It does not describe the output format (e.g., cost breakdown, validation errors), but as a preview tool this might be inferable. The Lab market note adds necessary complexity awareness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds a cross-parameter rule tying market_type to the corresponding timing field, which is not explicitly stated in any single parameter description. This extra guidance helps disambiguate the conditional requirements for Lab markets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Preview market creation' with a specific verb and resource, then clarifies 'validates params and shows costs WITHOUT building transaction,' which clearly distinguishes it from the many build_* sibling tools. It also explicitly references build_create_market_transaction as the follow-up, reinforcing its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use before build_create_market_transaction,' giving direct sequential context. The IMPORTANT note about Lab markets ('you MUST provide market_type and the corresponding timing field') offers concrete when-to-use guidance beyond generic descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![baozi-mcp MCP server](https://glama.ai/mcp/servers/bolivian-peru/baozi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bolivian-peru/baozi-mcp)

Score Badge

Copy to your README.md:

[![baozi-mcp MCP server](https://glama.ai/mcp/servers/bolivian-peru/baozi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bolivian-peru/baozi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bolivian-peru/baozi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server