TrenchFu

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

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it creates an unsigned transaction requiring signing by specific wallets (owner/agentWallet/operator), involves a minimum 0.01 SOL bet, and requires follow-up with mark_external_hire_accepted. It doesn't mention rate limits or error conditions, but covers the essential workflow.

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

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

The description is appropriately sized and front-loaded with the core action. Each sentence adds value: first explains acceptance mechanics, second covers transaction signing, third provides discovery methods, fourth specifies next steps. Minor room for improvement in sentence flow, but overall efficient.

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

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

For a tool with 2 parameters, 100% schema coverage, and no output schema, the description provides good context about the multi-step workflow, discovery methods, and wallet requirements. It could mention what happens if the bet fails or transaction is rejected, but covers the essential process adequately given the complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some context about where intentId comes from ('from the pending-hires poll or webhook notification') and clarifies wallet requirements, but doesn't provide significant additional parameter semantics beyond what's already in the schema descriptions.

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

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

The description clearly states the tool's purpose with specific verbs ('accept', 'placing a bet') and resources ('pending hire', 'ERC-8004 agent', 'TMB market'). It distinguishes from sibling tools like 'accept_tmb_job' by specifying it's for external hires targeting ERC-8004 agents, not general TMB jobs.

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

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

The description provides explicit guidance on when to use this tool: after discovering pending hires via polling or webhook notifications. It also specifies the next step ('call mark_external_hire_accepted') and distinguishes from alternatives by focusing on ERC-8004 agent acceptance, unlike 'accept_tmb_job' which appears more general.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the workflow (staking, assignment as first non-trivial staker, delivery, settlement) and prerequisites (registered agent profile). However, it lacks details on error conditions, rate limits, or what happens if the job isn't open, leaving some behavioral aspects unclear.

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

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

The description is appropriately sized and front-loaded with the core action. It uses two sentences efficiently: one for the main action and prerequisites, and another for the workflow. However, the second sentence is somewhat lengthy and could be slightly more streamlined.

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

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

Given the complexity (a multi-step on-chain job acceptance with staking), no annotations, and no output schema, the description provides a good overview but lacks details on return values, error handling, or specific platform behaviors. It covers the workflow but leaves gaps in operational context.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain 'stake_sol' beyond mentioning staking). This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Claim a TMB on-chain job by staking SOL on the Delivered outcome') and distinguishes it from siblings by mentioning the follow-up tool 'complete_job'. It explicitly identifies the resource (TMB job) and the mechanism (staking SOL), making it distinct from tools like 'bid_on_job' or 'accept_external_hire'.

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

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

The description provides clear context for when to use this tool: when a job is 'open with a confirmed on-chain market' and the user has 'a registered agent profile'. It also mentions the alternative tool 'complete_job' for the next step. However, it doesn't explicitly state when NOT to use it or compare it to similar tools like 'bid_on_job'.

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

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

No annotations are provided, so the description carries the full burden. It mentions the outcome ('links your account') and purpose ('for fee sharing'), but lacks details on behavioral traits like whether this is a one-time operation, if it requires specific permissions, potential errors (e.g., invalid code), or side effects (e.g., irreversible linking). This is inadequate for a mutation tool with no annotation coverage.

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

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

The description is two concise sentences with zero waste, front-loading the action and outcome efficiently. Every word contributes to understanding the tool's purpose without redundancy or unnecessary elaboration.

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

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

Given the tool's complexity (a mutation with financial implications like fee sharing), lack of annotations, and no output schema, the description is incomplete. It doesn't cover error handling, return values, or important behavioral aspects like idempotency or security requirements, leaving significant gaps for an AI agent to use it correctly.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters ('code' and 'wallet'). The description adds minimal value beyond the schema by implying the code is from another user and the wallet is 'yours', but doesn't provide additional context like format examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('apply a referral code') and the resource ('from another agent/user'), with a specific outcome ('links your account to theirs for fee sharing'). It distinguishes itself from siblings like 'get_referral_code' or 'get_referral_stats' by focusing on application rather than retrieval. However, it doesn't explicitly differentiate from all sibling tools, as some may involve linking accounts in other contexts.

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

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

The description implies usage when a user wants to link accounts for fee sharing, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_referral_code' (to obtain a code) or 'get_referral_stats' (to check status). No exclusions or prerequisites are mentioned, such as whether the code must be valid or the wallet must be registered.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a paid operation requiring an acceptance bond via MPP, and it involves submitting a bid with specific components. However, it misses details like potential rate limits, error conditions, or what happens upon submission (e.g., confirmation, status changes). The description doesn't contradict annotations, as none exist.

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

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

The description is front-loaded with the core action, followed by prerequisites and key details in two efficient sentences. Every sentence adds value: the first defines the tool's purpose, and the second clarifies requirements and payment mechanism, with no wasted words.

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

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

Given the complexity of a financial transaction tool with 5 parameters and no output schema, the description is moderately complete. It covers the action, prerequisites, and payment, but lacks details on return values, error handling, or integration with sibling tools like 'get_job_detail'. Without annotations, it should do more to compensate for the missing structured data.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'price, delivery estimate, and approach', which loosely maps to 'bid_amount', 'delivery_hours', and 'approach', but doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Submit a bid') and resource ('on an open job'), with specific details like price, delivery estimate, and approach. It distinguishes from siblings like 'post_job' or 'complete_job' by focusing on bidding rather than job creation or completion. However, it doesn't explicitly differentiate from similar tools like 'place_bet' or 'place_tmb_bet', which might involve financial transactions but in different contexts.

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

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

The description provides some context with 'You must have an agent profile' and mentions payment via MPP, implying prerequisites. However, it lacks explicit guidance on when to use this tool versus alternatives like 'accept_external_hire' or 'create_hire_intent', and doesn't specify exclusions or conditions for use beyond the basic requirements.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that browsing is free while purchasing requires payment, which hints at read-only behavior, but doesn't explicitly state whether this is a read operation, what data is returned, or any limitations like pagination or rate limits. For a tool with 5 parameters and no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, efficient sentence that front-loads the purpose ('Browse marketplace listings') followed by examples and a key behavioral note. Every part earns its place, though it could be slightly more structured with bullet points for the listing types.

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

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

Given 5 parameters with full schema coverage but no annotations and no output schema, the description provides adequate purpose and some behavioral context (free browsing vs. paid purchasing). However, it lacks details on return values, error conditions, or operational constraints, making it incomplete for a tool with multiple filtering options and marketplace complexity.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters with clear descriptions. The description doesn't add any additional meaning about parameters beyond implying filtering by listing types (e.g., 'endpoints, streams'). Baseline score of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the verb ('browse') and resource ('marketplace listings') with specific examples of what can be browsed (endpoints, streams, GPU compute, etc.). It distinguishes from siblings like 'purchase_listing' by mentioning browsing vs. purchasing, though it doesn't explicitly compare to 'browse_markets' which appears to be a different sibling tool.

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

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

The description implies usage for browsing marketplace listings before purchasing, with 'Free to browse, payment required to purchase' suggesting it's for exploration. However, it doesn't explicitly state when to use this tool versus alternatives like 'browse_markets' or 'purchase_listing', nor does it provide clear exclusions or prerequisites beyond the payment note.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a 'browse' operation with filtering, implying a read-only, non-destructive action, but doesn't specify permissions, rate limits, pagination behavior (beyond the 'limit' parameter), or what happens if no filters are applied. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

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

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

The description is concise and front-loaded, starting with the core purpose ('Browse all active prediction markets') followed by details on market types and filtering. Both sentences are relevant, with no wasted words. However, it could be slightly more structured by explicitly separating purpose from usage instructions.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and basic filtering, but lacks details on output format (e.g., what fields are returned beyond 'type'), behavioral aspects like pagination or sorting, and how it differs from sibling tools. This makes it minimally viable but with clear gaps for effective agent use.

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

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

The schema description coverage is 100%, with clear documentation for all three parameters (limit, status, category). The description adds minimal value beyond the schema by mentioning 'Filter by status and category,' which restates what the schema already covers. No additional semantics, such as default behaviors or interaction effects between parameters, are provided. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Browse all active prediction markets' with specific resource types (platform-curated and user-created TMB). It distinguishes between market types and mentions the 'type field' in results. However, it doesn't explicitly differentiate from sibling tools like 'get_kalshi_markets' or 'browse_listings' which might serve similar browsing functions.

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

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

The description implies usage context by specifying 'active prediction markets' and filter options (status and category), suggesting when to use it for market exploration. However, it lacks explicit guidance on when to choose this tool over alternatives like 'get_kalshi_markets' (which might focus on a specific platform) or 'browse_listings' (which might be for different resources). No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool lists modes with constraints, implying read-only behavior, but lacks details on response format, pagination, or error handling. This is adequate but not comprehensive for a tool with no annotations.

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

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

The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place with no wasted words, making it efficient and well-structured.

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

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

Given 0 parameters, no annotations, and no output schema, the description is complete enough for a simple listing tool. It explains what the tool does and how to use it, though it could add more on behavioral aspects like response format.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the output's purpose (picking a modeId for 'create_tmb_battle'), which compensates for the lack of output schema.

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

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

The description clearly states the verb ('List') and resource ('available TMB market modes'), specifying that each mode defines constraints like fee caps, evidence requirements, and rules. It distinguishes from siblings by focusing on TMB modes, unlike tools like 'browse_markets' or 'create_tmb_battle'.

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

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

It explicitly states when to use this tool: 'Use this to pick a modeId before calling create_tmb_battle.' This provides clear context and an alternative (the sibling tool 'create_tmb_battle'), guiding the agent on the tool's role in a workflow.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns a URL with specific parameters, explains the user flow (visiting the URL, completing verification steps, redirection), and clarifies signature requirements for different wallet types (agent-provisioned vs. user-held). However, it omits details like rate limits or error handling.

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

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

The description is well-structured and front-loaded with the core purpose. Each sentence adds value: URL format, user flow, and signature ownership details. It could be slightly more concise by combining some details, but overall it avoids redundancy and wastes no space.

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

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

Given the tool's complexity (KYC verification with cryptographic signatures) and lack of annotations or output schema, the description does a good job covering the essential context: purpose, usage flow, and key behavioral aspects. It explains the verification process and ownership requirements, though it could benefit from mentioning response formats or error cases.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema, only implicitly referencing 'wallet', 'signature', 'timestamp', and 'redirect_uri' in the URL example. It does not provide additional syntax or usage context for parameters.

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

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

The description explicitly states the tool's purpose: 'Build a DFlow Proof KYC deep-link URL for a wallet owner to complete verification.' It specifies the verb ('Build'), resource ('DFlow Proof KYC deep-link URL'), and distinguishes it from sibling tools like 'check_kyc_status' by focusing on URL generation rather than status checking.

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

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

The description provides clear context on when to use this tool: for wallet owners to complete KYC verification via a generated URL. It implicitly distinguishes from alternatives by not mentioning other KYC methods, but lacks explicit exclusions or named alternatives (e.g., compared to 'check_kyc_status').

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool proxies a public GET endpoint, implying it's a read-only operation. It explains the context of KYC requirements and the tool's role in pre-checking, adding useful behavioral context beyond basic functionality. However, it doesn't detail potential errors, rate limits, or response formats.

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

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

The description is efficiently structured in two sentences. The first sentence states the purpose, and the second provides usage guidelines and context. Every sentence adds value without redundancy, making it front-loaded and concise.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is largely complete. It explains the tool's purpose, usage, and behavioral context. However, without an output schema, it doesn't specify what the return value indicates (e.g., boolean status or detailed verification data), leaving a minor gap.

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

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

The input schema has 100% description coverage, with the 'wallet' parameter documented as 'Solana wallet address (base58).' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. Baseline 3 is appropriate given the schema's comprehensive coverage.

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

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

The description clearly states the tool's purpose: 'Check whether a Solana wallet has completed DFlow Proof KYC verification.' It specifies the verb ('Check'), resource ('Solana wallet'), and scope ('DFlow Proof KYC verification'), distinguishing it from sibling tools that handle different operations like buying, selling, or browsing.

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

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

The description provides explicit guidance on when to use this tool: 'Use this before attempting a Kalshi buy to fail-fast rather than get rejected at order time with PROOF_NOT_VERIFIED.' It also clarifies when KYC is not required (e.g., selling, redeeming, viewing markets), offering clear alternatives and exclusions.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what information is returned but doesn't describe important behavioral aspects like whether this is a read-only operation, what happens with invalid inputs, whether it requires authentication, or any rate limits. The description provides basic output information but lacks critical operational context.

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

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

The description is efficiently structured in a single sentence that states the purpose and return values. It's appropriately sized for a simple lookup tool, though it could potentially benefit from slightly more context about when to use it.

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

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

For a simple 2-parameter lookup tool with no output schema, the description provides basic information about what the tool does and what it returns. However, it lacks important context about behavioral aspects, usage guidelines, and doesn't fully compensate for the absence of annotations. The description is adequate but has clear gaps in completeness.

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

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

Schema description coverage is 100%, with both parameters ('promoId' and 'wallet') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting for parameter documentation.

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

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

The description clearly states the tool's purpose: checking access status from a promotional pass, including what information is returned (access status, expiry, tiers). It specifies the verb 'check' and resource 'promotional pass access', but doesn't differentiate from sibling tools like 'view_promo' or 'purchase_promo' which might have related functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this check is needed, or how it differs from sibling tools like 'view_promo' or tools for checking other statuses like 'check_kyc_status' or 'wallet_status'.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns an unsigned transaction to sign, which is useful context, but fails to cover critical aspects like required permissions, error conditions, rate limits, or what happens if winnings are already claimed. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single, efficient sentence that front-loads the core action and outcome with zero waste. It is appropriately sized for the tool's complexity, making it easy to parse quickly.

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

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

Given the tool's mutation nature (claiming winnings), no annotations, and no output schema, the description is incomplete. It lacks details on return values beyond 'unsigned transaction,' error handling, prerequisites (e.g., resolved market), and differentiation from sibling tools like 'claim_winnings,' leaving gaps for effective agent use.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (marketId, authToken, walletAddress) with descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as format details or usage examples, resulting in a baseline score of 3.

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

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

The description clearly states the verb ('Claim') and resource ('winnings from a resolved TMB market'), making the purpose specific. However, it doesn't distinguish this tool from 'claim_winnings' (a sibling tool), which appears to be a similar or related function, leaving some ambiguity about differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as 'claim_winnings' or other sibling tools. It mentions prerequisites implicitly (e.g., a resolved market), but lacks explicit when-to-use or when-not-to-use instructions, leaving usage context unclear.

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

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

With no annotations provided, the description carries full burden. It mentions wallet signing and settlement modes, which adds some behavioral context. However, it doesn't disclose critical details like whether this is a read-only or mutating operation, potential side effects, authentication requirements beyond the authToken parameter, or error conditions.

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

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

The description is extremely concise with just two sentences that efficiently convey the core purpose and key features. Every word earns its place with no wasted text, making it easy to parse quickly.

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

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

For a financial transaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'claiming winnings' entails operationally, what the expected outcome is, error handling, or how the different settlement modes affect behavior. The context signals show this is a 3-parameter tool with potential complexity that isn't adequately addressed.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline score of 3 reflects adequate but minimal value addition.

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

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

The description clearly states the action ('Claim winnings') and resource ('from a settled market'), with a specific verb and target. It distinguishes from some siblings like 'claim_tmb_winnings' by mentioning settlement modes, but doesn't explicitly differentiate from all similar tools in the list.

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

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

The description implies usage context ('from a settled market') and mentions three settlement modes, providing some guidance on when the tool applies. However, it doesn't specify when to use this versus alternatives like 'claim_tmb_winnings' or prerequisites beyond wallet signing.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it triggers 'platform resolver review', involves on-chain storage for 'tribunal review', and 'Triggers refund of acceptance bond via MPP'. However, it lacks details on error conditions, permissions needed, or rate limits, preventing a perfect score.

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

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

The description is front-loaded with the core action, uses two efficient sentences with zero waste, and every part (e.g., 'Queues for platform resolver review', 'Triggers refund') adds necessary context without redundancy. It's appropriately sized for the tool's complexity.

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

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

Given the complexity (on-chain job completion with 5 parameters, no output schema, and no annotations), the description is mostly complete: it covers purpose, usage, key behaviors, and references sibling tools. However, it doesn't explain the return values or potential errors, which could be helpful given the lack of output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some context by mentioning 'deliverables + IPFS evidence hash' and referencing 'pin_evidence tool', but it doesn't provide additional syntax, format, or constraints beyond what the schema already documents for the 5 parameters.

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

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

The description clearly states the specific action ('Mark a job as completed'), resources involved ('submitting deliverables + IPFS evidence hash'), and distinguishes it from siblings like 'create_tmb_job' by focusing on completion rather than creation. It explicitly references a sibling tool ('create_tmb_job') for context.

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

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

It provides explicit usage context: 'required for TMB on-chain jobs created via create_tmb_job' specifies when to use it, and it implies alternatives by distinguishing from other job-related tools like 'accept_tmb_job' or 'get_job_detail'. The mention of 'platform resolves the market based on evidence' adds further guidance on its role.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a mutation ('confirm', 'finalize'), implying a write operation, but doesn't specify permissions, side effects, or response format. For a tool that likely changes state on a blockchain, this is a significant gap in transparency, leaving the agent with incomplete behavioral understanding.

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

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

The description is a single, efficient sentence that front-loads the purpose and usage context without waste. Every word contributes to understanding the tool's role, making it appropriately sized and well-structured for quick comprehension.

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

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

Given the complexity of a blockchain transaction finalization tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., irreversible changes, network requirements), error handling, and return values. For a mutation tool in this context, more information is needed to ensure safe and effective use.

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

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

The schema description coverage is 100%, with both parameters ('signature', 'creator_wallet') well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'transaction signature' and 'creator wallet', but doesn't provide additional context like format examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('confirm a token launch') and the resource ('token launch'), specifying it's a finalization step after signing from 'launch_token'. It distinguishes from siblings by referencing 'launch_token' as a prerequisite, though it doesn't explicitly differentiate from all other tools. The purpose is specific but could be more distinct from unrelated siblings.

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

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

The description provides clear context by stating 'after signing the transaction from launch_token', indicating when to use this tool relative to a sibling. It implies usage as a follow-up step but doesn't explicitly state when not to use it or name alternatives beyond the prerequisite. This is helpful but lacks exclusions or broader alternatives.

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

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

No annotations are provided, so the description carries the full burden. It mentions mapping to create_permissionless_market and data feeds, but lacks details on permissions, side effects, or response behavior. For a creation tool with no annotations, this is a moderate gap in 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.

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

The description is two sentences with zero waste, front-loaded with the core action and efficiently covering usage guidelines. Every sentence earns its place by adding critical context.

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

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

Given no annotations and no output schema, the description provides good purpose and usage clarity but lacks details on behavioral traits like permissions or response format. It's mostly complete for a creation tool but could benefit from more operational context.

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

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

Schema description coverage is 100%, so the schema documents all parameters. The description implies the suggestion parameter's source but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool creates a structured battle from a suggestion, specifying the source (get_battle_suggestions) and the mapping target (create_permissionless_market with data feeds). It distinguishes from sibling create_tmb_battle for freeform claims, making the purpose specific and differentiated.

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

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

It explicitly states when to use this tool (from suggestions returned by get_battle_suggestions) and when not to (for freeform claim-based predictions, use create_tmb_battle instead). This provides clear alternatives and context for usage.

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

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

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses the 0.5 SOL seed requirement (cost implication), mentions platform resolves via on-chain data (resolution mechanism), and distinguishes duration rules (fixed vs. user-set). However, it doesn't cover error conditions, response format, or authentication details beyond the authToken parameter.

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

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

The description is efficiently structured in two sentences: first explains the battle types/categories, second covers resolution mechanism and cost. Every element earns its place, though the battle type listing is somewhat dense. It's appropriately sized for the tool's complexity.

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

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

For a creation tool with 6 parameters, no annotations, and no output schema, the description provides good foundational context (battle types, categories, cost, resolution) but leaves gaps: no information about return values, error handling, or how the created battle integrates with the platform. It's adequate but not fully complete for a tool that creates financial instruments with monetary cost.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds marginal value by grouping battle types into categories (epoch-boundary, validator, mev) which helps understand the battleType enum, but doesn't provide additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate when schema does heavy lifting.

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

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

The description clearly states the specific action ('Create a structured epoch battle') and resource ('epoch battle'), with detailed differentiation from siblings by specifying 7 battle types across 3 categories. It goes beyond the tool name to explain what constitutes an epoch battle.

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

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

The description implies usage context by categorizing battle types (epoch-boundary vs. validator vs. mev) and mentioning platform resolution via on-chain data, but doesn't explicitly state when to use this tool versus alternatives like 'create_validator_battle' or 'create_network_battle' from the sibling list. No explicit exclusions or prerequisites are provided.

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

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

No annotations are provided, so the description carries full burden. It discloses key behavioral traits: cost ('0.5 SOL seed'), duration range ('Duration: 15-120 min'), and resolution method ('Platform resolves via on-chain governance data'). However, it misses critical details like permissions needed, whether the operation is reversible, error handling, or what happens after creation (e.g., market visibility). For a tool with financial implications and no annotations, this is insufficient.

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

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

The description is front-loaded with the core action and resource, followed by key operational details (resolution, cost, duration). It uses two sentences efficiently, with no redundant information. However, it could be slightly more structured by separating cost and duration into bullet points for clarity.

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

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

Given the complexity (financial tool with no annotations and no output schema), the description is incomplete. It covers purpose and some behavioral aspects but lacks details on permissions, error cases, return values, or how the market integrates with sibling tools like 'place_bet'. For a tool involving SOL transactions and governance data, more context is needed to ensure safe and correct usage.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between 'bettingDurationSeconds' and 'eventDurationSeconds' or format details for 'proposalId'). Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Create a structured governance proposal outcome market') and resource ('governance proposal'), distinguishing it from sibling tools like 'create_epoch_battle' or 'create_network_battle' by specifying governance context. It also mentions the resolution mechanism ('Platform resolves via on-chain governance data'), making the purpose explicit and differentiated.

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

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

The description implies usage context by mentioning 'governance proposal' and 'on-chain governance data', suggesting it's for betting on governance outcomes. However, it lacks explicit guidance on when to use this tool versus alternatives like 'create_permissionless_market' or 'create_tmb_battle', and does not specify prerequisites or exclusions beyond the seed cost.

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

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

With no annotations provided, the description carries full burden and does well: it explains the two-phase process (intent storage vs. on-chain job), mentions persistence (30 days), outlines security features (escrow, fraud prevention, dispute window), and specifies prerequisites. It doesn't detail rate limits or error conditions, but covers key behavioral aspects for a complex tool.

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

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

The description is appropriately sized and front-loaded with core purpose, followed by process details and prerequisites. Every sentence adds value, though it could be slightly more streamlined by integrating the prerequisite note more seamlessly.

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

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

For a complex tool with no annotations and no output schema, the description does well: it explains the multi-phase process, security context, prerequisites, and persistence. It doesn't describe the return value (intentId) format or error cases, but given the detailed behavioral explanation, it's largely complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics: it implies 'agentId' comes from 'get_external_agent' and mentions 'service' choices relate to engagement paths, but doesn't elaborate beyond what the schema provides. No additional syntax or format details are given.

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

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

The description clearly states the specific action ('Log an intent to hire'), the resource ('external ERC-8004 agent'), and the mechanism ('via TrenchFu's TMB-escrow flow'). It distinguishes this from sibling tools like 'create_tmb_job' by explaining this is Phase 1 intent logging versus actual job creation, and from 'get_external_agent' by specifying this tool requires prior verification from that sibling.

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

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

Explicit guidance is provided: use 'get_external_agent' first to confirm endpoint availability, and agents without mcpEndpoint or a2aEndpoint cannot be hired here. It also distinguishes when to use this (Phase 1 intent) versus Phase 2 job creation, though it doesn't name a specific alternative tool for Phase 2.

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

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

No annotations are provided, so the description carries the full burden. It effectively discloses key behavioral traits: it's a creation/mutation tool (implied by 'List'), involves financial terms (10% commission, free to list), has a prerequisite (agent profile), and mentions the marketplace context. However, it doesn't cover aspects like response format, error handling, or idempotency, leaving some gaps for a tool with 13 parameters.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by essential context (pricing, commission, prerequisites) in compact clauses. Every sentence earns its place by adding critical information without redundancy, making it appropriately sized and efficient for understanding the tool's use.

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

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

Given the complexity (13 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose, key constraints, and prerequisites, but lacks details on behavioral aspects like response format, error cases, or idempotency. For a creation tool with many parameters, more context on what happens post-creation would be beneficial, though the schema handles parameter documentation well.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no specific parameter semantics beyond implying general usage (e.g., 'You set the price' relates to 'price_usdc', but no extra details). With high schema coverage, the baseline is 3, as the description doesn't compensate with additional insights into parameter meaning or usage.

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

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

The description clearly states the verb ('List') and resource ('any product or service on the marketplace'), with specific examples of what can be listed (endpoints, streams, GPU compute, etc.). It distinguishes this from sibling tools like 'browse_listings' (which likely views listings) and 'purchase_listing' (which buys them), making the purpose specific and differentiated.

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

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

The description provides clear context for when to use this tool: to create a listing on the marketplace. It mentions prerequisites ('Requires agent profile (8004)') and key constraints ('Free to list', 'Platform takes 10% commission'), but does not explicitly state when not to use it or name alternatives (e.g., 'update_agent_profile' for profile setup). This gives solid guidance but lacks explicit exclusions.

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

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: creates a market that resolves via live network data, requires 0.5 SOL seed, and has 5-15 minute duration. However, it doesn't mention permission requirements, rate limits, or what happens to the seed funds, leaving gaps for a mutation tool.

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

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

The description is appropriately sized with three concise sentences that front-load the core purpose. Every sentence adds value: market creation, resolution mechanism, and operational constraints. Minor improvement possible by integrating duration range with parameter info.

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

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

For a mutation tool with no annotations and no output schema, the description provides good purpose and some behavioral context but lacks details on permissions, error cases, return values, or how the 0.5 SOL seed is handled. It's adequate but has clear gaps given the tool's complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the metric options (TPS, success rate, priority fees, block time) beyond just 'network metric' in the schema, and clarifies duration range (5-15 min) beyond 'duration in minutes.' However, it doesn't explain threshold semantics or creatorWallet purpose.

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

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

The description clearly states the tool creates a structured over/under market on specific Solana network metrics (TPS, success rate, priority fees, block time), specifying the platform resolves via live network data. It distinguishes from sibling tools like create_epoch_battle or create_validator_battle by focusing on network metrics rather than other battle types.

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

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

The description implies usage for creating prediction markets on Solana metrics with a 0.5 SOL seed and 5-15 minute duration, but doesn't explicitly state when to use this versus alternatives like create_permissionless_market or create_tmb_battle. No exclusions or prerequisites are mentioned beyond the seed requirement.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the 0.5 SOL seed requirement, creator fee tiers (NEW 25%, PROVEN 35%, ELITE 50%), and automated data resolution. However, it doesn't mention potential side effects like transaction costs beyond the seed, error handling, or what happens if market creation fails, leaving some gaps.

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

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

The description is efficiently structured in two sentences: the first explains the tool's purpose and key features, and the second provides a clear alternative with contrasting details. Every sentence adds critical value without redundancy, making it front-loaded and waste-free.

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

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

For a tool with 8 parameters, no annotations, and no output schema, the description does a good job covering essential context: purpose, usage guidelines, fee structure, and sibling differentiation. It lacks details on return values or error cases, but given the schema's full coverage and the description's focus on operational context, it's mostly complete.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter-specific information beyond what's in the schema—it mentions metric types and fee tiers contextually but doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.

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

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

The description clearly states the verb ('Create') and resource ('structured prediction market') with specific details about what it compares (two competitors on a specific metric) and how it differs from its sibling tool. It explicitly distinguishes from 'create_tmb_battle' for freeform claim-based markets, making the purpose highly specific and differentiated.

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

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

The description provides explicit guidance on when to use this tool (for structured prediction markets on specific metrics) and when not to use it, naming the alternative tool 'create_tmb_battle' for freeform claim-based markets. It also mentions key operational details like seed cost and fee tiers, which help inform usage decisions.

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

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

With no annotations provided, the description carries full burden and does well: it discloses that the creator becomes the resolver with sole settlement authority, mentions transaction rejection risks if mode constraints aren't met, and references evidence attachment via another tool. It doesn't cover rate limits or error handling specifics, but provides substantial operational context.

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

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

The description is efficiently structured with zero waste: first sentence states purpose, second explains resolver role, third covers evidence, fourth provides critical prerequisite, and fifth distinguishes from alternative. Every sentence adds essential information.

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

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

For a complex 13-parameter tool with no annotations and no output schema, the description provides good context about the tool's purpose, usage, behavioral constraints, and relationships with other tools. It doesn't explain return values or error responses, but covers most operational aspects adequately.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some context about mode constraints affecting seed, duration, share, and bet sizes, but doesn't provide additional parameter semantics beyond what's already documented in the schema descriptions.

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

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

The description clearly states the tool's purpose with specific verbs ('Create a claim-based prediction market'), resource ('Trust Me Bro'), and scope ('Write any claim, set two outcomes, fund seed'). It explicitly distinguishes from sibling tool 'create_permissionless_market' for structured data-driven markets.

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

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

The description provides explicit usage guidelines: when to use ('Create a claim-based prediction market'), when not to use ('For structured data-driven markets use create_permissionless_market instead'), prerequisites ('Call browse_tmb_modes first to pick a modeId'), and alternative tool ('create_permissionless_market').

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: budget is escrowed on-chain, platform resolver prevents fraud, dispute window protects workers, and evidence must be pinned first. It explains the transactional nature and security mechanisms, though it could mention response format or error conditions for a perfect score.

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

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

The description is perfectly front-loaded with the core purpose in the first sentence, followed by supporting details about escrow, fraud protection, and prerequisites. Every sentence earns its place with zero wasted words, making it highly efficient despite the complex subject matter.

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

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

For a complex 10-parameter tool with no annotations and no output schema, the description does well by explaining the on-chain nature, escrow mechanism, fraud protection, and prerequisites. However, it doesn't describe what the tool returns or potential error cases, which would be helpful given the absence of output schema and annotations.

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

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

With 100% schema description coverage, the baseline is 3. The description adds minimal parameter semantics beyond the schema - it only explicitly mentions 'evidence_hash' and implies budget handling. It doesn't provide additional context about parameter relationships, validation rules, or usage patterns that aren't already in the comprehensive schema descriptions.

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

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

The description clearly states the specific action ('Create an on-chain TMB job contract') and resource ('TMB job'), distinguishing it from siblings like 'create_listing' or 'post_job' by specifying it's for TMB market with escrow in PDA (Job mode #2). It provides a precise verb+resource combination that avoids tautology.

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

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

The description provides clear context on when to use this tool by mentioning prerequisites ('Requires evidence_hash (use pin_evidence first)') and explaining the platform's fraud protection mechanisms. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, which prevents a perfect score.

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

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: requires 0.5 SOL seed, has duration constraints (15-120 min), and platform resolves via on-chain data. However, it doesn't mention permissions needed, whether the operation is reversible, rate limits, or what happens after creation. The description adds value but doesn't fully compensate for the lack of annotations.

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

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

The description is appropriately sized (two sentences) and front-loaded with the core purpose. Every sentence adds value: first states what the tool does, second provides key constraints. No wasted words, though it could be slightly more structured.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the basic operation, seed requirement, and duration constraints, but doesn't explain return values, error conditions, or how the battle results are determined. Given the complexity and lack of structured metadata, more completeness would be beneficial.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters. The description mentions 'metric' options and 'duration' range, which aligns with but doesn't add significant meaning beyond what the schema provides. It doesn't explain parameter interactions or provide additional context about validator selection or wallet requirements.

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

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

The description clearly states the tool creates a structured validator vs validator battle comparing specific metrics (performance, stake, skip rate, credits) using on-chain data. It specifies the verb 'create' and resource 'battle' with scope details, though it doesn't explicitly differentiate from sibling battle creation tools like create_epoch_battle or create_governance_battle.

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

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

The description provides some context about platform resolution and seed requirements, but offers no guidance on when to use this tool versus the many other battle creation tools (create_epoch_battle, create_governance_battle, create_network_battle, create_tmb_battle, create_battle_from_suggestion). No explicit alternatives or exclusions are mentioned.

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

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

With no annotations, the description provides some behavioral info (seller-only restriction) but lacks details on side effects like whether removal is permanent or reversible.

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

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

Two sentences, no filler, highly efficient. Every word contributes to the tool's purpose and constraint.

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

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

No output schema, and description omits return values or error scenarios. While acceptable for a simple mutation, it could mention success indication or error conditions.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description reinforces the seller_wallet constraint but does not add significant new semantic value beyond the schema.

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

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

Clearly states the action 'remove your listing' and the resource 'marketplace'. Distinguishes from siblings like 'create_listing' and 'purchase_listing' by specifying it is for sellers only.

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

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

Indicates when to use (seller removing own listing) but does not explicitly state when not to use or suggest alternatives like editing.

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

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

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses payment requirements ('Paid — per-call via MPP'), job tracking ('Records a job receipt with status tracking'), and execution routing ('Route execution to a registered service operator'). It doesn't cover error handling, response format, or rate limits, but provides more than basic functional description.

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

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

Three concise sentences with zero waste: first states core function, second adds tracking behavior, third specifies payment model. Each sentence earns its place by adding distinct, essential information. The description is appropriately sized and front-loaded with the primary action.

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

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

For a 3-parameter tool with no annotations and no output schema, the description provides good functional and behavioral context (payment, tracking) but lacks details about response format, error cases, or execution guarantees. It's adequate for basic understanding but incomplete for robust agent usage without additional documentation.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add meaning beyond what's in the schema (e.g., it doesn't explain 'service_name' format or 'operator_wallet' validation). Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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

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

The description clearly states the action ('Route execution to a registered service operator') and resource ('service operator'), with specific details about job receipt recording and payment. It distinguishes from siblings like 'register_service' (setup) or 'list_services' (discovery), but doesn't explicitly contrast with all execution-related tools like 'complete_job' or 'post_job'.

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

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

The description implies usage context by mentioning 'registered service operator' and 'Paid — per-call via MPP', suggesting prerequisites (service registration, payment setup). However, it lacks explicit when-to-use guidance versus alternatives like 'complete_job' or 'post_job', and doesn't specify exclusions or complementary tools.

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

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

With no annotations provided, the description bears full burden. It honestly discloses that the tool exports a private key (a sensitive operation) and explicitly states the wallet remains functional, indicating non-destructiveness. Security implications are implied but not expanded upon.

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

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

Two sentences, no fluff. Every word adds value: specifies target wallets and reassures about wallet continuity. Ideal conciseness for a simple tool.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is complete enough. It covers purpose, effect, and compatibility. It omits the return format (raw private key string) but that is a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's 'Your agent ID' description. It could have clarified how to obtain or identify the agentId, but the schema already handles the parameter.

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

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

The description explicitly states the tool's purpose: retrieving the wallet's private key for export to popular Solana wallets like Phantom and Solflare. It distinguishes from siblings such as provision_wallet (create wallet) and wallet_status (check status), making the action clear.

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

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

The description clearly indicates the tool is used for exporting private keys to external wallets. It reassures the user that the wallet continues to work after export, but does not provide explicit when-not-to-use guidance or name alternative tools. Context is sufficient for most use cases.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a read operation (implied by 'Get'), returns specific structured data, and handles the fallback to upcoming seasons. It lacks details on error conditions or rate limits, but covers essential behavior adequately.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and efficiently lists all returned data points. Every word adds value without redundancy or unnecessary elaboration.

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

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

For a tool with 0 parameters and no output schema, the description is highly complete: it explains what the tool does, what data it returns, and handles a key edge case. It could slightly improve by mentioning the return format or error handling, but it's sufficient given the low complexity.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing on the tool's purpose and output semantics instead.

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

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

The description clearly states the verb 'Get' and the resource 'currently active competitive season', specifying what information is retrieved (name, reward pool, time remaining, etc.). It distinguishes from sibling tools like 'get_season_leaderboard' by focusing on the active season's details rather than rankings.

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

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

The description provides clear context for when to use this tool: to retrieve details about the active season, including handling the edge case where 'Returns upcoming season if none active.' However, it does not explicitly mention when not to use it or name specific alternatives among siblings.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is 'Paid — per-call via MPP,' which adds important context about cost and billing. However, it lacks details on rate limits, authentication needs, or error handling, leaving behavioral gaps.

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

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

The description is front-loaded with the core purpose, followed by return details and cost information in two concise sentences. Every sentence adds value without waste, making it efficient and well-structured.

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

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

Given no annotations and no output schema, the description provides basic purpose and cost info but lacks details on return format, error cases, or operational constraints. It is minimally adequate for a read-only tool but incomplete for full contextual understanding.

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

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

Schema description coverage is 100%, so the schema already documents both parameters fully. The description does not add any meaning beyond what the schema provides, such as explaining how 'category' or 'min_edge' affect the results, resulting in a baseline score of 3.

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

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

The description explicitly states the verb ('Get') and resource ('current arbitrage opportunities across prediction markets'), making the purpose specific and clear. It distinguishes from siblings by focusing on arbitrage opportunities, unlike other tools that handle jobs, battles, or market data.

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

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

No guidance is provided on when to use this tool versus alternatives. The description mentions it returns edge %, confidence, and position size, but does not specify scenarios, prerequisites, or exclusions, leaving usage context unclear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool returns ('curated battle suggestions with pre-filled parameters' including details like title and reasoning) and hints at its read-only nature by stating it 'gets' data. However, it lacks details on permissions, rate limits, or error handling, leaving gaps in 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.

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

The description is appropriately sized and front-loaded, with the first sentence stating the core purpose. Each subsequent sentence adds necessary context without waste, covering data sources, content details, and usage intent efficiently in a few clear statements.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It explains what the tool does, what data it includes, and its purpose. However, without an output schema, it could benefit from more detail on return values or structure, though the mention of 'title, reasoning, competitors with metrics, and suggested duration' partially compensates.

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

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

The input schema has 100% description coverage, clearly documenting both parameters ('limit' and 'category') with defaults and options. The description adds value by mentioning 'pre-filled parameters' and listing categories like 'DEX token matchups', which aligns with the schema but does not provide additional syntax or format details beyond what the schema already covers.

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

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

The description clearly states the tool's purpose with specific verbs ('Get curated battle suggestions') and resources ('DEX token matchups, validator battles, MEV warfare, network metrics, and governance votes'). It distinguishes itself from sibling tools by focusing on pre-filled battle suggestions from the Solana Arena page, unlike other tools that handle jobs, markets, or battles directly.

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

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

The description provides clear context for when to use this tool: 'to find opportunities for creating permissionless markets.' It implies usage by linking suggestions to market creation, but does not explicitly state when not to use it or name specific alternatives among the many sibling tools, such as 'create_battle_from_suggestion' or 'browse_markets'.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions analysis outputs but doesn't describe whether this is a read-only operation, requires authentication, has rate limits, returns real-time vs historical data, or what format the analysis comes in. The phrase 'analysis' is vague about actual behavior.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Maritime and aviation chokepoint analysis') followed by specific examples. Every word earns its place with no redundancy or wasted phrasing.

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

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

For a zero-parameter tool with no output schema, the description provides adequate basic context about what intelligence is gathered but lacks completeness regarding return format, data freshness, scope limitations, or how this differs from other intel tools. The absence of annotations means the description should do more to explain behavioral aspects.

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

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

The tool has 0 parameters with 100% schema description coverage, so the description doesn't need to compensate for missing parameter documentation. The description appropriately doesn't discuss parameters since none exist, earning a baseline score of 4 for not creating confusion about non-existent inputs.

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

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

The description clearly states the tool performs 'analysis' on 'maritime and aviation chokepoints' with specific examples (Suez, Hormuz, etc.), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_defense_intel' or 'get_force_posture' that might overlap in military/geopolitical intelligence domains.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'congestion scores, military presence, traffic anomalies' but doesn't indicate whether this is for real-time monitoring, historical analysis, or comparison with other intel tools in the sibling list.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the update frequency, which is useful context, but does not cover critical aspects such as whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. For a tool with zero annotation coverage, this is a significant gap 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.

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

The description is highly concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and key behavioral trait (update frequency). There is no wasted text, and every sentence adds meaningful information, making it easy for an agent to parse quickly.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It explains what CII scores are and their update cadence, but lacks details on return format, error handling, or usage context. For a tool with no structured metadata, more behavioral and output information would enhance completeness.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not discuss parameters, which is appropriate. It adds value by explaining what CII scores represent ('aggregated intelligence scores across all 16 domains') and their update frequency, providing semantic context beyond the schema.

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

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

The description clearly states the tool retrieves 'Compound Intelligence Index — aggregated intelligence scores across all 16 domains', specifying the resource (CII scores) and what they represent. It distinguishes itself from siblings by focusing on aggregated scores rather than specific intel types (e.g., get_defense_intel, get_narrative_intel). However, it lacks a specific verb like 'retrieve' or 'fetch', slightly reducing precision.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the update frequency ('Updated every 30 seconds'), which implies timeliness but does not specify use cases, prerequisites, or comparisons to other intel tools like get_chokepoint_intel or get_weather_intel. This leaves the agent without clear contextual direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns a list with payout amounts, which is useful, but lacks details on permissions needed, rate limits, error conditions, or whether it's a read-only operation (implied by 'check' but not explicit). For a tool with no annotations, this is insufficient.

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

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

The description is two sentences with zero waste: the first defines the purpose and scope, and the second specifies the return format. It is front-loaded with key information and appropriately sized for the tool's complexity.

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

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

Given no annotations and no output schema, the description provides basic purpose and return format but lacks details on behavioral aspects like authentication needs or error handling. It is adequate for a simple read operation but could be more complete to compensate for missing structured data.

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

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

The input schema has 100% description coverage, with the 'wallet' parameter documented as 'Your wallet address'. The description does not add any parameter-specific information beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with a specific verb ('check') and resource ('your bets'), specifying it targets 'won bets on settled markets' and returns 'list of claimable positions with payout amounts'. This distinguishes it from sibling tools like 'claim_winnings' (which likely executes claims) and 'get_my_positions' (which may show all positions).

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

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

The description implies usage context by stating it checks 'which of your bets are claimable (won bets on settled markets)', suggesting it should be used when looking for winnings ready to be claimed. However, it does not explicitly mention when not to use it or name alternatives like 'get_my_positions' for a broader view, leaving some guidance gaps.

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

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

With no annotations provided, the description carries the full burden. It discloses the auth requirement and references another tool for token acquisition, which is useful. However, it lacks details on rate limits, error handling, or response format, leaving gaps in behavioral context for a financial data tool.

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

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

The description is front-loaded with the core purpose, followed by specific data points and auth details in two efficient sentences. Every element adds value without redundancy, 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.

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, the description adequately covers the purpose and auth needs but lacks details on return values, error cases, or operational limits. For a tool with financial data and auth requirements, this leaves room for improvement in completeness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, but does not contradict it either.

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

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

The description clearly states the specific action ('Get') and resource ('creator earnings'), listing the exact data returned: total fees earned, creator tier, share percentage, and per-market breakdown. It distinguishes itself from siblings by focusing on creator-specific financial data, unlike other tools that handle jobs, battles, markets, or user profiles.

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

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

The description provides clear context for when to use it—when needing creator earnings data—and mentions an auth requirement. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as tools for general user data or market analytics.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It states the tool 'gets' data, implying a read-only operation, but does not clarify aspects like authentication requirements, rate limits, data freshness, or potential side effects. The mention of 'compound intelligence' hints at aggregated data but lacks specifics on processing or output format, leaving significant gaps in transparency for a tool with no structured safety hints.

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

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

The description is concise and front-loaded, using two sentences to convey the core purpose and scope. It avoids redundancy and wastes no words, though it could be slightly more structured by explicitly stating the lack of parameters or output details. Overall, it is efficient and clear, earning a high score for brevity and directness.

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

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

Given the tool's complexity (involving cross-domain correlations) and the lack of annotations and output schema, the description is moderately complete. It specifies the domains and intelligence type but omits details on data format, update frequency, or error handling. For a tool with no structured safety or output information, it provides a basic understanding but leaves gaps in operational context, making it adequate but not fully comprehensive.

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

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

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add parameter details, which is appropriate since there are none to explain. It implies the tool retrieves broad correlation data without filtering, but without parameters, this is acceptable. The baseline for 0 parameters is 4, as the description need not compensate for missing param info.

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

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

The description clearly states the tool's purpose: retrieving cross-domain correlation signals between specific domains like weather→energy and maritime→oil. It specifies the scope ('16 domains') and the type of intelligence ('compound intelligence'), making the verb+resource explicit. However, it does not distinguish this tool from its many siblings, which include other 'get_' tools like get_market_signals or get_weather_intel, so it falls short of a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the domains covered but does not specify use cases, prerequisites, or exclusions. With many sibling tools available (e.g., get_market_signals, get_weather_intel), there is no indication of how this tool differs in context or applicability, leaving the agent without clear usage instructions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying the paid nature ('per-call via MPP'), which hints at rate limits or access costs, and lists intelligence types. However, it doesn't cover critical aspects like response format, data freshness, error handling, or authentication needs, leaving gaps for a tool with no annotation support.

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

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

The description is front-loaded with the core purpose and efficiently lists intelligence types in a comma-separated format, followed by a concise note on payment. It avoids redundancy and uses two clear sentences, though it could be slightly more structured by separating categories from operational details for even better readability.

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

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

Given the tool's complexity (defense intelligence with paid access), no annotations, and no output schema, the description is moderately complete. It covers the purpose and payment model but lacks details on output structure, error cases, or integration context. This leaves the agent with insufficient information to fully understand behavioral expectations, especially for a paid service with potential data sensitivity.

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

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

The input schema has 100% description coverage, with the 'category' parameter well-documented in the schema (including default and allowed values). The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining category implications or usage examples. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

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

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

The description clearly states the tool's purpose with specific verbs ('Get defense and military intelligence') and resources (military movements, aviation traffic patterns, etc.), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_force_posture' or 'get_formation_intel' that might overlap in military intelligence domains, preventing a perfect score.

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

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

The description implies usage context by listing intelligence categories (military movements, conflict zone monitoring, etc.) and notes it's 'Paid — per-call via MPP,' which suggests cost considerations. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_chokepoint_intel' or 'get_formation_intel,' leaving usage somewhat inferred rather than clearly defined.

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

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

No annotations provided, so description carries full burden. It does not disclose any behavioral traits (e.g., read-only, authentication needs, rate limits). Only states the output content.

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

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

Single sentence, directly lists stats, no wasted words. Front-loaded with the main action and resource.

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

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

Covers the basic output categories but lacks details like refresh rate, time range for volume, or confirmation that no filters apply. Acceptable given no parameters or output schema.

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

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

No parameters exist, so baseline is 4. The description is not required to add parameter meaning.

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

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

Clearly states the action 'Get' and the resource 'DFlow prediction market stats', listing specific metrics. Distinguishes from sibling tools like browse_markets or get_market_pools.

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

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

No explicit guidance on when to use versus alternatives, but the purpose is implied by the nature of the stats. Lacks explicit context for selection among many sibling market tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool provides 'enrichment data' but lacks details on what that entails (e.g., real-time vs. historical data, format, rate limits, or authentication needs). This is insufficient for a tool with potential complexity across multiple categories.

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

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

The description is brief and front-loaded with the core purpose ('Per-category enrichment data.'), followed by a list of categories. It avoids unnecessary words, but the list could be more structured (e.g., using bullet points or clearer grouping) for better readability, slightly impacting structure.

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

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the enrichment data includes (e.g., fields, format), how it's returned, or any behavioral traits like error handling. For a tool with diverse categories and no structured output, this leaves significant gaps for an AI agent.

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

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

The input schema has 100% description coverage, with the 'category' parameter documented as 'Enrichment category name'. The description adds value by listing example categories (e.g., weather, crypto prices), which helps clarify valid inputs beyond the schema. However, it doesn't specify if these are exhaustive or if other categories exist, so it meets the baseline for high schema coverage.

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

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

The description clearly states the tool retrieves 'enrichment data' and provides specific categories (weather, market signals, etc.), making the purpose evident. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_weather_intel' or 'get_market_signals', which appear to serve similar purposes for specific categories, so it falls short of a perfect score.

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

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

The description lists categories but offers no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this is a general-purpose tool for all categories or if sibling tools like 'get_weather_intel' should be preferred for specific ones, leaving usage ambiguous.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a read operation (fetching data) and mentions external data sources (on-chain, IPFS, 8004market.io), but does not specify behavioral traits like rate limits, error conditions, or response format. It adds context about TrenchFu reading but not indexing reputation locally, which is useful but not comprehensive.

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

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

The description is appropriately sized and front-loaded, starting with the core action ('fetch full detail') and listing key data points. It uses two sentences efficiently, though the second sentence about 8004 marketplace context could be slightly more concise. Overall, it avoids unnecessary repetition and stays focused.

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

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

Given the tool's complexity (fetching detailed agent data from multiple sources) and lack of annotations or output schema, the description is moderately complete. It covers what data is retrieved and the external context, but does not explain the return structure, potential errors, or performance considerations, leaving gaps for an AI agent to infer behavior.

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

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

The input schema has 100% description coverage, with the 'id' parameter clearly documented as an agent asset address. The description does not add any additional semantic meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 for high schema coverage.

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

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

The description explicitly states the verb 'fetch' and the resource 'external ERC-8004 agent', detailing specific data retrieved (on-chain record, IPFS metadata, reputation metrics, explorer link). It clearly distinguishes from sibling tools like 'list_external_agents' and 'search_external_agents' by focusing on detailed retrieval for a single agent rather than listing or searching multiple agents.

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

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

The description provides clear context for when to use this tool: to get full details for a specific external agent, including metadata and reputation from the 8004 marketplace. It implies usage when detailed agent information is needed, though it does not explicitly state when not to use it or name specific alternatives like 'list_external_agents' for broader queries.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool retrieves 'time-sensitive opportunities' and lists categories, it doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions are required, how results are returned (format, pagination), rate limits, or error conditions. The description provides some context but leaves significant gaps for a tool with no annotation coverage.

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

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

The description is appropriately concise with two sentences that each serve a clear purpose. The first sentence states what the tool does and lists opportunity categories. The second sentence provides usage context. There's no wasted language, though it could be slightly more structured with clearer separation between functionality and usage guidance.

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

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

Given that there are no annotations and no output schema, the description provides basic functionality information but lacks important contextual details. For a tool that presumably returns time-sensitive data, the description doesn't explain what format the opportunities are returned in, whether the data is real-time or cached, or what happens when no opportunities match the criteria. The description is minimally adequate but has clear gaps in completeness.

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

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

The input schema has 100% description coverage, with both parameters ('type' and 'limit') clearly documented in the schema. The description doesn't add any additional parameter information beyond what's already in the schema descriptions. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

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

The description clearly states the tool retrieves time-sensitive opportunities across specific categories (markets about to expire, validator flash candidates, governance votes closing soon). It uses specific verbs like 'Get' and identifies the resource as 'opportunities'. However, it doesn't explicitly distinguish this tool from similar sibling tools like 'get_arb_opportunities' or 'get_market_status', which reduces it from a perfect score.

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

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

The description provides implied usage context by mentioning 'Great for creating short-duration TMB or permissionless markets', which suggests when this tool might be useful. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_arb_opportunities' or 'get_governance_proposals', nor does it provide any exclusion criteria or prerequisites for usage.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it calculates a scoring system (10pts/aircraft + 15pts/vessel) and tracks temporal changes (buildup and drawdown). However, it does not cover other important aspects like data freshness, source reliability, error handling, or output format, which are critical 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.

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

The description is highly concise and front-loaded, consisting of only three clauses that efficiently convey purpose, scoring method, and tracking capability. Every sentence earns its place with no wasted words, making it easy to parse quickly.

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

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

Given the complexity (military force analysis), lack of annotations, and no output schema, the description is partially complete. It explains what the tool does and its scoring system but omits details on output structure, data granularity, or reliability. This leaves gaps for an AI agent to understand how to interpret results, though the core functionality is clear.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter-specific information, which is appropriate. It provides context on what the tool computes (force composition and scoring), but this relates to output semantics rather than inputs. Baseline is 4 for zero parameters.

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

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

The description clearly states the tool's purpose with specific verbs and resources: 'Regional military force composition — combined air+naval presence per geographic region.' It distinguishes itself from siblings by focusing on military force data, unlike other tools that handle jobs, markets, battles, or user profiles. The description is not a tautology of the name and provides meaningful context.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific contexts for usage. While it implies a military/intelligence context, it lacks explicit instructions for distinguishing it from other intel-related tools like 'get_defense_intel' or 'get_formation_intel'.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the detection method (ADS-B and AIS analysis) but lacks critical details like whether this is a read-only operation, data freshness, rate limits, authentication needs, or what the output looks like. For a tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Military formation detection') and adds necessary context about methods and scope. Every word earns its place with zero waste.

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

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

Given the tool's complexity (military intelligence analysis), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the output contains (e.g., data format, timestamps, confidence scores) or operational constraints, leaving significant gaps for an agent to use it effectively.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any. A baseline of 4 is applied since no parameters exist.

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

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

The description clearly states the tool's purpose: detecting military formations via coordinated air/naval movements, deployment patterns, and force posture changes using ADS-B and AIS analysis. It specifies both the action ('detection') and the resource ('military formations'), though it doesn't explicitly differentiate from siblings like 'get_force_posture' or 'get_chokepoint_intel'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools (e.g., 'get_force_posture' or 'get_chokepoint_intel'), leaving the agent with no context for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves 'active' proposals and hints at a 'close deadlines' aspect, but lacks details on permissions, rate limits, data freshness, or response format. This leaves significant gaps for a tool that likely interacts with external data sources.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a contextual hint in the second. Both sentences earn their place by adding value—no wasted words or redundancy.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and some usage context but lacks behavioral details (e.g., error handling, data scope) and output information, which are needed for full understanding.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain 'status' values like 'flash' in more detail), but it implies a focus on 'active' proposals and 'close deadlines,' which aligns with the schema's 'status' parameter.

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

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('active Solana DAO governance proposals'), and distinguishes it from siblings by specifying it covers 'all Realms DAOs'—no other sibling tools mention governance proposals, making this distinction explicit.

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

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

The description provides clear context for when to use this tool by stating it 'covers all Realms DAOs' and that 'proposals with close deadlines make great prediction markets,' which implies usage for market analysis. However, it does not explicitly mention when not to use it or name alternative tools for similar purposes.

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

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

No annotations are provided, so the description carries full burden. It implies a read-only operation ('Get'), but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or data freshness. For a tool fetching job details (potentially sensitive info like bids and settlement), this lack of transparency is a significant gap, warranting a 2.

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

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

The description is a single, efficient sentence that front-loads the core purpose. Every word contributes meaning (e.g., 'full details' specifies scope, 'including bids, status, and settlement info' enumerates key data). It avoids fluff, but could be slightly more structured (e.g., separating purpose from data details), so it scores a 4.

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

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

Given no annotations, no output schema, and a simple input schema, the description is minimally adequate. It states what the tool does and hints at output content, but lacks behavioral context (e.g., safety, errors) and doesn't fully compensate for missing structured data. For a read operation with potential complexity (bids, settlement), it's incomplete, scoring a 3.

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

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

The input schema has 100% description coverage (job_id is documented), so the baseline is 3. The description adds no parameter-specific semantics beyond implying job_id identifies 'a specific job'. It doesn't clarify format (e.g., numeric vs. string) or sourcing, so it meets but doesn't exceed the baseline.

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

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

The description clearly states the verb ('Get') and resource ('full details of a specific job'), specifying what information is included (bids, status, settlement info). It distinguishes itself from sibling 'get_jobs' which likely lists multiple jobs rather than details of one. However, it doesn't explicitly contrast with other job-related tools like 'complete_job' or 'bid_on_job', keeping it at a 4 rather than 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a job ID), exclusions, or comparisons to siblings like 'get_jobs' (for listings) or 'get_my_positions' (for user-specific job data). Without any usage context, it scores a 2.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Free tier — browse the job board', which hints at accessibility and cost, but lacks details on permissions, rate limits, pagination, or response format. For a read operation with no annotations, this is insufficient to inform an agent about behavioral traits beyond basic functionality.

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

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

The description is appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second adds filtering and tier context. There's minimal waste, though the 'budget range' mention could be confusing. It's efficient but not perfectly structured due to the schema mismatch.

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

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

Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects like permissions or response format, and the 'budget range' mention doesn't align with the schema, creating ambiguity. For a tool with no output schema and full parameter coverage but missing behavioral context, it should do more to be fully helpful.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (limit, status, category) with descriptions. The description adds marginal value by mentioning 'Filter by status, category, or budget range', but 'budget range' is not in the schema, creating a minor inconsistency. It doesn't provide additional syntax or format details beyond what the schema offers, meeting the baseline for high coverage.

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

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

The description clearly states the tool's purpose: 'List open jobs on the marketplace' specifies the verb (list) and resource (open jobs). It distinguishes from siblings like 'get_job_detail' (singular detail) and 'post_job' (create), but doesn't explicitly differentiate from 'browse_listings' which might be similar. The mention of 'marketplace' provides context, making it clear but not fully sibling-differentiated.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions filtering capabilities but doesn't specify scenarios or prerequisites, such as when to use 'get_jobs' vs 'browse_listings' or 'get_job_detail'. There's no explicit when/when-not or alternative tool references, leaving usage context implied at best.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only operation for browsing (not trading) and highlights the KYC limitation, which is crucial context. However, it lacks details on rate limits, error handling, or what the output looks like (e.g., format, pagination), leaving gaps for an agent to understand full behavior.

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

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

The description is concise and well-structured in three sentences: it states the purpose, specifies the use case, and provides a critical limitation. Each sentence adds value without redundancy, and the information is front-loaded with the core function. There is no wasted text, making it efficient for an agent to parse.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose, usage context, and key limitations well, but lacks details on output format, error cases, or integration with sibling tools. Without an output schema, the agent must infer return values, which is a gap in completeness for effective tool invocation.

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

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

The input schema has 100% description coverage, with clear documentation for 'limit', 'status', and 'category' parameters. The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage tips. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

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

The description clearly states the tool's purpose: 'Browse Kalshi prediction markets for inspiration' and 'See what real-world events have active markets.' It specifies the verb ('browse') and resource ('Kalshi prediction markets'), and distinguishes it from direct trading by noting KYC limitations. However, it doesn't explicitly differentiate from sibling tools like 'browse_markets' or 'browse_listings' beyond the Kalshi-specific focus.

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

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

The description provides clear context for when to use this tool: for browsing Kalshi markets to inspire creation of equivalent markets on TMB or TrenchFu. It explicitly states when not to use it ('Direct Kalshi trading requires KYC (not available here)'), which is helpful guidance. However, it doesn't mention alternatives among sibling tools (e.g., 'browse_markets' might be for other platforms), leaving some ambiguity.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Works for all market types (platform + TMB),' which adds useful context about compatibility. However, it doesn't describe key behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., structured data or raw values). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is highly concise and well-structured, consisting of two sentences that efficiently convey purpose and usage without any wasted words. It front-loads the core functionality and follows with practical advice, making it easy to parse and understand quickly.

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

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

Given the tool's complexity (involves financial calculations like odds and payouts), no annotations, and no output schema, the description is somewhat incomplete. It covers the basic purpose and usage but lacks details on behavioral aspects (e.g., safety, output format) that are crucial for an AI agent to use it correctly. However, it does provide enough to understand when and why to call the tool, so it's minimally adequate but with clear gaps.

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

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

The input schema has 100% description coverage, so the schema already documents all parameters ('marketId', 'outcome', 'amountSol') with clear descriptions. The description adds some semantic context by implying that parameters are used for simulation ('simulated payout'), but it doesn't provide additional details beyond what the schema states, such as default behaviors or interactions between parameters. Thus, it meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Get current pool sizes, implied odds, and simulated payout for a market.' It specifies the verb ('Get') and resources ('pool sizes, implied odds, and simulated payout'), making it easy to understand. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_market_predictions' or 'get_market_status', which might have overlapping functions, so it doesn't reach a perfect score.

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

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

The description provides clear context on when to use the tool: 'Call before betting to understand the risk/reward at current pool ratios.' This gives practical guidance for usage timing. However, it doesn't specify when not to use it or name alternatives among siblings (e.g., 'get_market_predictions' for different data), so it lacks explicit exclusions or comparisons.

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

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

No annotations are provided, so the description carries the full burden. It mentions the return content (outcome, confidence, evidence chain) and sources (multiple predictor models), but lacks details on permissions, rate limits, error handling, or whether it's a read-only operation. For a tool with no annotations, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence that front-loads the core purpose and includes essential details about returns and sources without any wasted words. Every part earns its place.

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

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

Given no annotations and no output schema, the description provides basic purpose and return content but lacks behavioral context (e.g., safety, limits) and detailed output structure. It's minimally adequate for a simple read operation but incomplete for full agent understanding.

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

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

Schema description coverage is 100%, with the parameter 'ticker' well-documented in the schema. The description adds no additional parameter details beyond implying it's for market predictions, so it meets the baseline of 3 where the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Get settlement predictions') and resource ('for a specific market ticker'), distinguishing it from sibling tools like 'get_market_status' or 'get_market_signals' by focusing on predictions rather than current data or signals.

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

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

No guidance is provided on when to use this tool versus alternatives like 'get_market_status' or 'browse_markets'. The description implies usage for prediction retrieval but lacks explicit context, prerequisites, or exclusions.

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

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

With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses that this is a paid service requiring payment per call, returns HTTP 402 with an MPP URL, and describes the return format (signal strength, direction, confidence, source intelligence). It does not cover rate limits or authentication needs, but provides key operational details.

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

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

The description is appropriately sized and front-loaded, with the first sentence stating the core purpose and the second providing critical behavioral details (paid service, HTTP response). Every sentence earns its place without redundancy.

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

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

Given the complexity (real-time market signals with payment requirements) and lack of annotations or output schema, the description is fairly complete: it explains the purpose, return values, and payment mechanism. However, it could improve by detailing error handling or authentication, but it covers essential aspects adequately.

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

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

The schema description coverage is 100%, so the schema already documents both parameters (ticker and window). The description does not add meaning beyond what the schema provides, such as explaining the significance of the window parameter or ticker format, but meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose with specific verbs ('Get real-time prediction market signals') and resources ('for a ticker'), distinguishing it from sibling tools like 'get_market_predictions' or 'get_market_status' by focusing on signals rather than predictions or status.

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

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

The description implies usage for real-time market signals but does not explicitly state when to use this tool versus alternatives like 'query_alpha_signals' or 'get_market_predictions'. It provides some context (paid service) but lacks clear exclusions or comparative guidance.

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

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

No annotations are provided, so the description carries the full burden. It describes what information is returned (pool sizes, odds, etc.) but lacks behavioral details such as error conditions, rate limits, authentication requirements, or whether it's a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Get detailed status of a specific market') and lists key return details without unnecessary words. Every part of the sentence adds value, making it appropriately concise and well-structured.

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

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

Given the tool's complexity (a read operation with one parameter) and no annotations or output schema, the description covers the basic purpose and return details adequately. However, it lacks information on error handling, response format, or usage context, which would be needed for full completeness in a production environment.

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

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

Schema description coverage is 100%, with the single parameter 'marketId' documented as 'Market ID or PDA.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. With high schema coverage, 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.

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

The description clearly states the tool's purpose: 'Get detailed status of a specific market' with specific details like 'pool sizes, odds, bet count, settlement status, time remaining.' It uses a specific verb ('Get') and resource ('market'), but doesn't explicitly differentiate from sibling tools like 'get_market_pools' or 'get_market_signals' beyond the 'detailed status' phrasing.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'browse_markets' (for listing) or other market-related tools, nor does it specify prerequisites or contextual constraints for usage.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('portfolio summary with unrealized gains'), which adds some value. However, it lacks details on permissions, rate limits, error handling, or whether this is a read-only operation (implied by 'Get' but not confirmed). For a tool with zero annotation coverage, this is insufficient for safe and effective use.

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

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

The description is concise and front-loaded, stating the core purpose in the first sentence and adding return details in the second. There's no wasted verbiage, and it efficiently communicates key information. A perfect score is withheld as it could slightly improve by integrating usage hints without sacrificing brevity.

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

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

Given the tool's complexity (involving financial data across markets), lack of annotations, and no output schema, the description is minimally adequate. It covers the purpose and return value but misses behavioral traits like data freshness, pagination, or error scenarios. Without annotations or output schema, more context would help an AI agent use it correctly, but it meets the basic threshold.

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

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

The input schema has 100% description coverage, with the 'wallet' parameter documented as 'Your wallet address'. The description doesn't add any additional semantic context beyond this, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

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

The description clearly states the tool's purpose: 'Get all your open positions, bets, and P&L across all markets.' It specifies the verb ('Get') and resources ('open positions, bets, and P&L'), and mentions the return value ('portfolio summary with unrealized gains'). However, it doesn't explicitly differentiate from sibling tools like 'get_portfolio_detail' or 'get_claimable', which might offer overlapping functionality, preventing a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., wallet setup), exclusions, or compare it to sibling tools like 'get_portfolio_detail' or 'get_claimable'. Usage is implied by the description but not explicitly stated, leaving gaps for an AI 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.

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. While it mentions what data is returned (purchase records and active leases), it doesn't describe authentication requirements, rate limits, pagination behavior, error conditions, or whether this is a read-only operation (though 'Get' implies read-only). For a tool with no annotation coverage, this is a significant gap.

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

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

The description is extremely concise and well-structured: a single sentence that efficiently communicates the core purpose and return values. Every word earns its place with zero wasted text.

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

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

Given that there's no output schema and no annotations, the description provides basic but incomplete context. It mentions what data is returned but doesn't describe the structure, format, or potential limitations. For a data retrieval tool with no structured output documentation, the description should ideally provide more detail about the return format.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

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

The description clearly states the tool's purpose: 'Get your purchase history' with specific resources listed (listings bought, provisioning status, lease details). It distinguishes from siblings like 'get_my_positions' or 'get_portfolio_detail' by focusing on purchases rather than positions or portfolio details. However, it doesn't explicitly differentiate from 'purchase_listing' (which appears to be a write operation).

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_my_purchases' versus 'get_my_positions', 'get_portfolio_detail', or other data retrieval tools. There are no prerequisites, exclusions, or comparative context provided.

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

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

No annotations are provided, so the description carries full burden. It implies a read-only operation ('Get') but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or response format. The description adds value by specifying the scope (current season) and data points returned, but lacks details on how the data is structured or accessed.

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

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

The description is efficiently structured in two sentences: the first states the purpose and enumerates specific stats, and the second provides crucial usage guidance. Every sentence adds value with zero wasted words, making it front-loaded and easy to parse.

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

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

Given no annotations and no output schema, the description does well by specifying the data points returned and usage prerequisites. However, it doesn't explain the return format or structure, leaving gaps in understanding the full behavior. For a tool with 2 parameters and 100% schema coverage, it's mostly complete but could benefit from output details.

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

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

Schema description coverage is 100%, with both parameters (seasonId, wallet) clearly documented in the schema. The description adds minimal semantic context by mentioning seasonId comes from 'get_active_season' and wallet is 'Your wallet address,' but doesn't provide additional syntax or format details beyond what the schema already states.

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

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

The description clearly states the specific action ('Get your rank and stats') and resource ('in the current season'), listing concrete data points like points, XP, bets, wins, losses, win rate, volume, qualification status, and rank change. It distinguishes from sibling tools like 'get_season_leaderboard' (which likely shows broader rankings) by focusing on the user's personal stats.

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

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

The description explicitly provides when-to-use guidance by stating 'Use get_active_season first to get the season ID,' naming the alternative tool and specifying a prerequisite step. This gives clear context for proper invocation sequence.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function but lacks details on behavioral traits such as whether it's read-only or mutative, any rate limits, authentication needs, or what the output format might be. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves operationally.

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

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

The description is a single, efficient sentence that conveys the core functionality without unnecessary words. It is front-loaded with key terms like 'narrative intelligence' and lists specific capabilities concisely. However, it could be slightly more structured by separating different aspects for clarity, but overall it avoids waste.

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

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

Given the complexity implied by terms like 'causal chain detection' and the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the output looks like, how the intelligence is presented, or any limitations or scope of the analysis. For a tool that seems to provide analytical insights, more context is needed to guide effective use.

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

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

The input schema has no parameters (parameter count: 0), and schema description coverage is 100%, meaning the schema fully documents the absence of inputs. The description doesn't need to add parameter details, as there are none to explain. This meets the baseline for tools with zero parameters, where minimal additional information is required.

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

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

The description states the tool provides 'narrative intelligence' with specific capabilities like 'priming signals, causal chain detection, market-event narrative matching' and shows 'how events propagate through markets.' This is more specific than just restating the name, but it remains somewhat abstract and doesn't clearly differentiate from sibling tools like 'get_chokepoint_intel' or 'get_force_posture' that might also provide market intelligence. The purpose is described but lacks concrete differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, contexts, or exclusions, nor does it reference sibling tools for comparison. The agent must infer usage based on the abstract description alone, which offers minimal practical direction.

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

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

No annotations are provided, so the description carries the full burden. It states the tool retrieves information, implying it's a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, or response format. For a tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single, efficient sentence that front-loads the purpose and includes usage guidance. Every word earns its place with no redundancy or waste.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but lacks details on behavioral aspects like response format or error handling. It's complete enough for a basic info tool but could be more informative.

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

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

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, a baseline of 4 is appropriate as it doesn't need to compensate for gaps.

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

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

The description clearly states the tool's purpose: 'Get TrenchFu platform info' with specific resources listed (arenas, SDK endpoints, market creation URLs, documentation). It distinguishes itself from siblings by being an informational starting point, though it doesn't explicitly contrast with similar tools like 'get_active_season' or 'get_solana_network'.

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

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

The description provides clear context for usage with 'Start here,' indicating this is an entry point for platform exploration. It doesn't explicitly state when not to use it or name alternatives, but the 'Start here' guidance is strong enough for a 4.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions that it retrieves 'full portfolio with individual positions' and various position types, which implies a read-only operation. However, it doesn't disclose important behavioral aspects like whether this requires authentication, rate limits, or how data is sourced (real-time vs cached). The 'refresh' parameter in the schema hints at caching behavior, but the description doesn't explain this.

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

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

The description is efficiently structured in two sentences. The first sentence clearly states the purpose and scope, while the second provides crucial comparative guidance. Every sentence earns its place, though it could be slightly more concise by combining the two sentences.

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

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

Given that there's no output schema and no annotations, the description should do more to explain what the tool returns. While it lists the types of positions included, it doesn't describe the structure or format of the response data. For a tool that retrieves complex portfolio data with multiple position types, more information about the return format would be helpful despite the good purpose and usage guidance.

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

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

The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (like explaining why 'sessionWallets' might be needed or what 'refresh' actually does). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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

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

The description clearly states the tool's purpose with specific verbs ('Get full portfolio with individual positions') and resources ('Solana prediction bets, Kalshi/DFlow positions, synthetic positions, spot trades, claimable amounts'). It explicitly distinguishes this tool from its sibling 'get_my_positions' by noting it provides more detailed information than the summary-only sibling.

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

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

The description provides explicit guidance on when to use this tool versus alternatives by stating 'More detailed than get_my_positions (which returns summary only).' This clearly indicates that this tool should be used when detailed position data is needed, while the sibling should be used for summary information.

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

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

No annotations provided, so description carries full burden. It states it 'gets' prices, implying read-only, but does not disclose any behavioral traits like idempotency, auth requirements, rate limits, or safety guarantees. Minimal disclosure beyond the obvious.

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

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

Two sentences, front-loaded with purpose. No extraneous words. Every sentence adds value. Efficient and clear.

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

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

For a simple tool with one optional parameter and no output schema, the description is adequate but lacks details about return format or limitations (e.g., number of symbols). It achieves minimum viability but could be slightly more complete.

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

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

Schema description coverage is 100% with clear parameter description. Tool description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: fetching current Pyth oracle prices for major crypto assets. It names specific examples (SOL, BTC, ETH) and indicates real-time on-chain price feeds. No ambiguity or tautology. Sibling tools do not overlap in function.

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

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

The description implies usage context (real-time prices), but provides no explicit when-to-use or when-not-to-use guidance. The parameter description offers optional symbols hint, but no comparison with alternatives or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It mentions that the tool can 'get or generate' a referral code and describes the incentive (earning from trading fees), but it doesn't disclose critical behavioral traits such as whether generation is automatic, if it requires specific permissions, rate limits, or what the output format looks like. This is a significant gap for a tool with potential financial implications.

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

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

The description is front-loaded and efficient: it states the core action in the first phrase and adds context in a second sentence. Every sentence earns its place by clarifying purpose and incentives without unnecessary details, making it appropriately sized and well-structured.

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

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

Given the complexity (a tool with financial incentives and no annotations) and lack of an output schema, the description is incomplete. It doesn't explain what the referral code looks like, how it's generated, or what the return values are. For a tool that could involve generation logic and earnings, more context is needed to fully guide an AI agent.

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

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

The input schema has 100% description coverage, with the 'wallet' parameter clearly documented as 'Your wallet address.' The description doesn't add any additional meaning beyond this, such as format requirements or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Get or generate your referral code.' It specifies the action (get/generate) and resource (referral code), and adds context about sharing and earning from trading fees. However, it doesn't explicitly differentiate from sibling tools like 'get_referral_stats' or 'apply_referral', which keeps it from a perfect score.

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

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

The description implies usage by stating 'Share this code with other agents — you earn a percentage of their trading fees,' suggesting it's for referral purposes. However, it lacks explicit guidance on when to use this tool versus alternatives like 'apply_referral' or 'get_referral_stats', and doesn't mention prerequisites or exclusions, leaving some ambiguity.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but does not specify authentication needs, rate limits, data freshness, or response format. This is a significant gap for a tool that likely involves user-specific data access.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Get your referral statistics') and lists specific data points without unnecessary elaboration. Every word contributes to understanding the tool's function, with zero wasted content.

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

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

Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves user-specific referral data. It does not address behavioral aspects like permissions, error handling, or return structure, leaving gaps that could hinder an AI agent's ability to use the tool effectively in context.

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

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

The input schema has 100% description coverage, with the 'wallet' parameter clearly documented as 'Your wallet address'. The description does not add any additional meaning or context beyond this, such as format requirements or validation rules, so it meets the baseline for high schema coverage without compensation.

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

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

The description clearly states the tool's purpose with specific verbs ('Get') and resources ('referral statistics'), listing key data points like earnings, referral tree, number of referrals, and total volume. It distinguishes itself from siblings by focusing on referral metrics, but does not explicitly differentiate from tools like 'get_creator_earnings' or 'get_user_profile' that might overlap in user data retrieval.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., having a referral code), exclusions, or comparisons to sibling tools like 'get_referral_code' or 'get_user_profile', leaving usage context implied rather than explicit.

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

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

No annotations provided; description discloses return content and tier-gated access but omits behavioral traits such as read-only nature, error handling for uncompleted tasks, or rate limits.

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

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

Two sentences, front-loaded with purpose and key details, no wasted words.

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

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

Given no output schema, description adequately covers return fields and special case for whale holders; could briefly mention error cases or prerequisites.

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

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

Schema coverage is 100%; description adds no additional meaning beyond what the schema already provides for taskId and wallet.

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

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

Description clearly states 'Retrieve a completed research dossier by taskId' and lists specific return contents (conviction score, synthesis, settlement tracking). Distinct from sibling tools like submit_research.

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

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

Description implies usage after submit_research but does not explicitly state when to use vs alternatives or conditions like requiring a completed task.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool is paginated with default and max limits (50 and 100), and it returns specific data fields (ranked players with points, wins, etc.). However, it doesn't mention error conditions, rate limits, or authentication needs, leaving some gaps in 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.

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

The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose, data fields, pagination details, and usage prerequisites. Every sentence earns its place without redundancy or unnecessary information.

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

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

Given no annotations and no output schema, the description does well by covering purpose, usage, and key behavioral traits (pagination, data fields). However, it lacks details on output format (e.g., structure of returned data) and error handling, which would enhance completeness for a tool with no structured output documentation.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (seasonId, limit, offset) with their types and descriptions. The description adds minimal value beyond the schema by implying seasonId comes from 'get_active_season,' but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.

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