TrenchFu

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

No annotations are provided, so the description carries the burden. It discloses key behavioral traits: placing a stake on the Delivered side (minimum 0.01 SOL) and automatic signing of provisioned wallets. It does not mention failure modes or reversibility, but the core financial and signing behaviors are transparent.

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 three sentences, front-loaded with the purpose, and every sentence adds value: the first states the action, the second notes the financial stake, and the third clarifies wallet handling. No filler 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?

For a two-parameter transactional tool, the description is fairly complete: it explains the core action, the stake requirement, and automatic wallet signing. Without an output schema, it omits the return format, but the essential usage context is covered. A slightly richer mention of post-acceptance behavior would push it higher.

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 both parameters described. The description adds no additional meaning beyond the schema; it mentions automatic wallet signing but does not elaborate on parameter syntax or new constraints. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Accept a pending hire') and the specific resource ('your ERC-8004 agent'), and distinguishes it from sibling tools like accept_tmb_job by referencing the TMB market and Delivered side. The verb+resource structure is unambiguous.

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

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

The description provides clear context: use when there is a pending hire targeting your ERC-8004 agent. It does not explicitly list alternatives or exclusions, but the context strongly implies the trigger scenario, making it easy to decide when to invoke.

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

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

With no annotations, the description carries the transparency burden. It discloses the staking of SOL, the refundable bond, and the requirement for a registered agent profile. However, it does not detail risks, reversal conditions, or what happens on failure (e.g., if the outcome is not delivered), leaving some financial risk unaddressed.

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 three sentences, each earning its place: the action, the key prerequisite (bond payment), and the necessary conditions. No redundant or filler 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?

For a financial transaction with multiple prerequisites and no output schema, the description covers the essential context: what to do, the sequence (bond first), and required conditions. It could be more complete by specifying outcome states or error handling, but it effectively covers the main 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 baseline is 3. The main description adds value by linking fee_payment_sig to the acceptance bond and clarifying that stake_sol is a commitment on the Delivered outcome, but it doesn't add substantial new semantics beyond what parameter descriptions already provide.

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: 'Accept a TMB on-chain job by staking SOL on the Delivered outcome.' This is a specific verb+resource+mechanism, and it distinguishes from sibling tools like accept_external_hire or bid_on_job by focusing on TMB on-chain jobs and the stake-on-Delivered mechanism.

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 prerequisites: a refundable acceptance bond must be paid first via /mpp/v1/jobs/:jobId/accept and the signature passed as fee_payment_sig. It also states conditions: job must be open with a confirmed on-chain market and requires a registered agent profile (8004). It doesn't name alternative tools explicitly, but the usage context is strongly implied.

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 the key behavior: linking the account to the referrer for fee sharing. However, it does not mention potential side effects like irreversibility, one-time application, or prerequisites, leaving some uncertainty.

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, front-loaded with the action and resource. Every word adds value, and it avoids redundancy. Highly 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?

For a simple two-parameter tool with no output schema, the description sufficiently covers what the tool does and its effect. It explains the purpose and outcome, though it could add minor details like reversibility or account-linking constraints. Still largely complete for 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 the baseline is 3. The description does not add extra meaning about parameters beyond what the schema already states ('code' and 'wallet'). It is adequate but not enhanced.

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

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

The description uses a specific verb ('Apply') and identifies the resource ('referral code') with a clear scope ('from another agent/user'). It also explains the consequence (linking accounts for fee sharing), which distinguishes it from siblings like get_referral_code and get_referral_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 implies when to use the tool: when you have a referral code from another agent/user. It does not explicitly state alternatives or exclusions, but the context is fairly clear. Lacks explicit 'when not to use' guidance compared to best practices.

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 must disclose behavioral traits, but it only mentions the requirement of an agent profile and the contents of the bid. It does not explain whether the bid is binding, whether any funds are moved, or what the response indicates. This is a significant gap for a mutation-like action.

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

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

The description is three short sentences with no redundant or extra words. It front-loads the primary action first and provides additional context efficiently.

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

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

The tool has a straightforward schema, and the description covers the primary purpose and the key inputs. However, without annotations or an output schema, it lacks details on what happens after submission, potential errors, or any side effects, leaving the agent partially uninformed.

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 has full 100% description coverage, so the baseline is 3. The description adds marginal value by grouping price, delivery estimate, and approach (mapping to bid_amount, delivery_hours, approach), but does not provide new details 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 begins with the specific action 'Submit a bid on an open job', using a clear verb (submit) and resource (bid). This distinguishes it from sibling tools like post_job, get_jobs, and accept_tmb_job by focusing on the bidding action.

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: it is used when bidding on an open job, and it mentions a prerequisite ('Requires a registered agent profile'). However, it does not explicitly contrast with alternatives or state when not to use it, so it falls short of a 5.

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

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 browsing is free and purchases require per-call payment, adding behavioral context. However, it does not mention whether browsing has side effects, authentication requirements, or what exactly is returned, so it's a 3.

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, immediately identifies the tool's purpose and includes only essential additional context (scale, chains, filtering, pricing). No wasted words, so 5.

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 browse tool with 5 parameters fully documented in the schema, the description covers the core function, filter options, and pricing model. It doesn't describe the return format or pagination behavior, but that's not critical given the schema. With no annotations, the description does enough to be actionable, though not exhaustive, so 4.

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 a concise summary of the main filter dimensions (category, type, price) which maps to the schema parameters, but it doesn't provide additional semantics beyond the schema, so 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 identifies a specific verb ('browse') and resource (the marketplace of intelligence endpoints/bundles across Solana and Base), and distinguishes itself from sibling 'browse_markets' by focusing on this particular marketplace with 230+ items and a payment model.

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?

States that browsing is free and payment occurs on purchase, and mentions filtering by category, type, price, giving clear context for when to use this tool. However, it does not explicitly mention alternatives like browse_markets or exclusions, so it's 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 full responsibility for disclosing behavioral traits. The only behavioral detail it adds is that each result includes a type field. It does not mention whether the tool is read-only, requires authentication, has rate limits, or any side effects. This is a significant gap given the lack of 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 concise, consisting of two sentences that front-load the core purpose. It efficiently conveys the scope, types of markets, return field, and filtering options without extraneous words. Every sentence earns its place.

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

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

For a simple browse tool with three optional parameters and no output schema, the description covers the essential context: what does it list, what is included in results, and that filtering is available. It lacks some details like pagination or full result structure, but these are not critical for a basic browse operation. Given the tool's simplicity, the description is complete enough.

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 only restates the filter capabilities ('Filter by status and category') without providing additional meaning or examples beyond what the schema already documents. It does not compensate with extra semantic detail about parameter values 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 tool's function: browsing all active prediction markets. It distinguishes between platform-curated (Solana Arena, F1, Kalshi) and user-created TMB markets, and notes that each result includes a type field. This specificity differentiates it from sibling tools like browse_listings or get_kalshi_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 clear context that this is a general-purpose browse tool for all prediction markets, not limited to a specific source. However, it does not explicitly mention when to prefer other tools (e.g., get_kalshi_markets for Kalshi-only) or any exclusions. Thus it is clear but lacks explicit alternative 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 is the only source of behavioral information. The verb 'List' implies a read-only, non-destructive operation, and the description clarifies what the returned modes contain, but it does not disclose potential pagination, ordering, or any side effects. This is adequate but not rich.

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

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

Two sentences, front-loaded with the core action ('List available TMB market modes'), and every sentence earns its place: the first defines the resource, the second explains how to use the result. No filler 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?

For a zero-parameter, no-output-schema tool, the description is complete: it explains what the tool does, what the modes represent, and how to use the output in the context of create_tmb_battle. It lacks detailed return formatting, but that is not essential for such a simple listing operation.

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 zero parameters, so the baseline is 4. The description adds no parameter-specific info but does explain the significance of the modeId that will be used later, which helps the agent understand the output's purpose. No additional parameter semantics are needed.

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

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

The description uses a specific verb ('List') and resource ('TMB market modes'), and explains exactly what these modes define (fee caps, evidence requirements, swap/withdrawal rules, duration limits). It clearly distinguishes itself from sibling tools like browse_markets by scoping to TMB modes and explicitly mentions the modeId selection purpose.

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 states when to use this tool: 'Use this to pick a modeId before calling create_tmb_battle.' This provides a clear context and a sequential dependency. It does not mention alternatives or exclusions, but for a simple listing tool this is sufficient.

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 responsibility for behavioral disclosure. It clearly explains that the wallet owner must visit the URL in a browser, that the signature must be produced by the wallet being verified, and includes security details such as timestamp anti-replay and redirect_uri restrictions. This goes well beyond a simple action statement.

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 with the primary purpose, followed by URL format and key behavioral constraints. Each sentence contributes meaningful information without redundancy or bloat.

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?

Despite lacking an output schema and annotations, the description provides sufficient context: it describes the returned URL format, the user flow, signature requirements, and redirect_uri defaults. This is complete for a link-builder tool, especially given the 100% schema coverage for parameters.

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 already provides 100% coverage with detailed param descriptions, so the baseline is 3. The description adds value beyond the schema by explaining the signature ownership nuance (agents can sign for provisioned wallets; users must sign from their own browser) and clarifying the default redirect_uri behavior. This additional context elevates the score.

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

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

The description states a specific action ('Build a DFlow Proof verification deep-link URL') and the resource (wallet owner verification). It also specifies the URL format, distinguishing this from sibling tools like check_kyc_status or verify_agent, which are about status checking or agent verification rather than link generation.

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 implies when to use the tool: to generate a verification link for a wallet owner. It also provides guidance on who should sign based on wallet ownership. However, it does not explicitly name alternative tools or state 'use this instead of X', leaving room for a clearer decision boundary versus 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 of behavioral disclosure. It reveals that the tool is a read-only proxy for a public GET endpoint, is non-mutating, and provides context about the PROOF_NOT_VERIFIED error. It doesn't detail response structure or rate limits, but for a simple status check this is adequate.

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: the first states the core purpose, the second provides critical usage context. Every word earns its place; no filler or repetition of schema information.

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

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

For a simple tool with one parameter, no output schema, and no annotations, the description covers purpose, usage conditions, and rationale. It is complete enough for an agent to select and invoke correctly without further information.

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

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

Schema description coverage is 100%: the only parameter 'wallet' is described as 'Solana wallet address (base58)'. The description adds no additional semantic detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb+resource: "Check whether a Solana wallet has completed DFlow Proof verification." It clearly distinguishes the tool from siblings like build_kyc_verification_link and verify_agent by focusing on status checking. The mention of the proxied endpoint further clarifies its exact 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 explicitly states when verification is required (only when buying Kalshi/DFlow outcome tokens) and lists scenarios that do not require it. It also instructs to use this tool before a Kalshi buy to fail fast, providing a clear decision rule and consequence avoidance.

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 burden. It discloses what the tool returns (access status, expiry, tiers), which is useful. However, it does not mention whether the operation is read-only, requires authentication, or has any side effects. The return-value disclosure adds some transparency, but not deep 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?

Two sentences, front-loaded with the primary purpose, and no wasted words. Efficiently conveys what the tool does and what it returns.

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

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

This is a simple check tool with only two parameters and no output schema. The description compensates well by listing the return values (status, expiry, tiers). It could mention read-only behavior or prerequisites (e.g., wallet ownership), but it is adequate for the tool's simplicity.

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% (wallet: 'Your wallet address', promoId: 'Promo ID'), so the schema fully documents both parameters. The description adds no additional parameter-level context, so the baseline of 3 applies.

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

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

The description uses a specific verb ('check if') and identifies the resource ('active access from a promotional pass'). It also distinguishes from siblings like view_promo (which likely shows general promo details) and purchase_promo, by focusing on the user's access status, expiry, and included tiers.

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 when to use the tool (when you need to verify active promotional access), but it does not provide explicit guidance on alternatives or when not to use it. No sibling tools are referenced for differentiation.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: the tool returns an unsigned transaction instead of directly executing the claim. This is critical for agent expectations. It does not elaborate on failure modes (e.g., already claimed, invalid market), but the core behavior is clearly stated.

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

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

Two sentences, each directly informative. Front-loaded with the main action, then a concise statement of the return type. No filler, redundancy, or irrelevant details.

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 well-specified schema and no output schema, the description covers the core purpose and critical return behavior. It lacks details on edge cases (e.g., prerequisites beyond resolved market, error handling), but that is not essential given the tool's simplicity. The 'resolved TMB market' condition provides context, and the return type is noted.

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?

Input schema provides descriptions for all three parameters (100% coverage), so the description adds no extra meaning to parameters. The baseline of 3 applies since the schema already documents the parameters adequately. The mention of 'unsigned transaction' is about output, not 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?

Description states a specific verb ('Claim'), a clear resource ('winnings from a resolved TMB market'), and distinguishes from the sibling 'claim_winnings' by specifying TMB market context. It also notes the output type ('unsigned transaction'), leaving no ambiguity about the tool's function.

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

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

The phrase 'from a resolved TMB market' implies a precondition for use, giving some context. However, it does not explicitly mention when not to use it or point to alternatives like the generic 'claim_winnings' for non-TMB markets. Usage guidance is inferred 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?

With no annotations provided, the description carries the full burden. It discloses a behavioral requirement (wallet signing) and the various settlement modes, which adds useful context. Still, it omits potential side effects, prerequisites beyond settlement, or permissions needed for AdminPayout or MerkleAirdrop modes, leaving gaps in behavioral 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 extremely concise—two sentences that front-load the core purpose and then add practical details (signing, settlement modes). Every word earns its place, with no fluff or repetition.

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

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

Given the tool's moderate complexity (three parameters, multiple settlement modes, no output schema), the description covers the essential context: the action, the condition (settled market), the authentication requirement, and the modes. It does not detail return values or error cases, but for a straightforward claim action, this is reasonably 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 each parameter already having a concise description. The tool description adds minimal extra meaning beyond reinforcing that walletAddress is tied to the signing action and that authToken may be auto-resolved. No additional syntax or format details are provided, so it stays at the baseline for complete 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 ('Claim winnings'), the resource ('a settled market'), and includes the distinguishing detail of signing with a wallet. This effectively differentiates it from siblings like claim_tmb_winnings, which targets TMB-specific winnings.

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 (after a market has settled) and mentions the supported settlement modes. However, it does not explicitly name alternatives or exclusions, such as when to prefer get_claimable or claim_tmb_winnings, so it lacks direct guidance for alternative 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. It discloses side effects: queues for platform resolver review and triggers an async refund of acceptance bond via MPP. It also notes the prerequisite of calling pin_evidence first. This is more transparent than typical descriptions, though it could detail failure modes or reversibility.

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 three sentences, front-loaded with the primary action, followed by conditional requirements and side effects. Every sentence adds essential information with no filler. It is concise and well-structured for quick parsing.

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 has 5 parameters, a nested object, and no output schema, the description covers the core workflow, prerequisite (pin_evidence), and post-completion effects (queue and refund). It doesn't explain result_data structure, but the schema includes a type. Overall, it provides sufficient context for an agent to use the tool 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 coverage is 100%, so descriptions already exist for each parameter. The tool description adds value by clarifying that evidence_hash is required for TMB on-chain jobs and must come from pin_evidence, and that deliverables are part of the submission. This goes beyond the basic schema descriptions, especially for evidence_hash.

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: "Mark a job as completed by submitting deliverables + IPFS evidence hash." It identifies the specific resource (job) and the required inputs, distinguishing it from related sibling tools like accept_job or bid_on_job. It also adds context about TMB on-chain jobs, making the purpose unambiguous.

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

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

The description provides conditional usage guidance: for TMB on-chain jobs, evidence_hash is required and pin_evidence must be called first. It implies this tool is for finalizing jobs, not for other actions like bidding or accepting. While it doesn't explicitly name alternatives, it gives enough context for an agent to decide when to invoke it.

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 must carry the full burden of behavioral disclosure. It indicates the action finalizes the launch but provides no details on side effects, reversibility, permission requirements, error cases, or what the output will be. For a mutation tool, 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 two sentences, directly states the action and required input, and contains no redundant or vague wording. Every word earns its place, making it highly concise and 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?

Given the simplicity of the tool (two well-documented parameters, no output schema), the description sufficiently covers the essential context: the purpose, the trigger step, and the required input. It could add info about the post-confirmation state or potential errors, but for this simple two-step flow, it is 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?

The input schema already provides 100% coverage with clear descriptions for both parameters ('Solana transaction signature from signing the launch_token tx' and 'Creator wallet that signed the tx'). The description only mentions 'Pass the transaction signature', adding no meaningful semantic information beyond the schema. Baseline 3 applies.

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

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

The description uses a specific verb 'Confirm' with a clear resource 'token launch' and ties it directly to the sibling tool 'launch_token' ('from launch_token'). This distinguishes it as the next step in the token launch process, making its purpose unmistakable.

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 states when to use it: after signing the transaction from launch_token, and it instructs to pass the transaction signature to finalize the launch. It clearly implies the usage context and prerequisite, though it does not explicitly name alternatives or exclusions.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool maps suggestions to create_permissionless_market and enumerates the domains (tokens, validators, MEV, governance, network, epoch), giving insight into how the battle is structured. However, it omits side effects such as irreversibility, auth requirements, or cost, which would matter for a creation 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?

Two sentences, front-loaded with purpose, no filler. Every word is useful, and the alternative tool instruction is packed into the second sentence.

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 no output schema and no annotations, the description gives enough context for selection: it identifies the prerequisite input (suggestion), the mapping target, and a clear alternative. It could mention return values or auth requirements, but the schema covers authToken and the workflow 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?

All 4 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds little beyond the schema—the key clarification that 'suggestion' comes from get_battle_suggestions is already in the schema's property description. No additional parameter nuances are provided.

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 it creates a structured data-driven battle from a suggestion returned by get_battle_suggestions, using a specific verb and resource. It distinguishes itself from create_tmb_battle by noting the alternative for freeform predictions and referencing create_permissionless_market as the mapping target.

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?

Explicitly instructs to use create_tmb_battle for freeform claim-based predictions, providing a clear when-not-to-use scenario. The reference to get_battle_suggestions as the source implies the intended workflow (get suggestion first, then create). This directly guides tool selection 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 of behavioral disclosure. It states that the platform resolves via on-chain data and mentions the 0.5 SOL seed cost, which are important behavioral traits. However, it does not mention post-creation behavior, reversibility, or any side effects beyond cost, 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 concise, using three sentences to cover purpose, types, categories, duration rules, resolution, and cost. It is front-loaded with the core action and contains no redundant or filler 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 tool has 6 parameters, no output schema, and no annotations, the description covers key aspects: battle type categories, duration constraints, resolution mechanism, and seed cost. It omits details like the response shape or explicit success behavior, but for a creation tool, the description is reasonably complete for an agent to understand the tool's function and constraints.

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 already covers all parameters with descriptions, so baseline is 3. The description adds categorical context and reinforces duration behavior (e.g., 'duration fixed to epoch end' for epoch-boundary types), but the schema already states 'Ignored for epoch-boundary types.' Thus the description adds marginal 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?

The description clearly states the action ('Create a structured epoch battle') and the specific resource type, differentiating it from sibling battle creation tools. It enumerates the 7 battle types across 3 categories, making the tool's scope unambiguous and distinct from tools like create_governance_battle or create_validator_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 clear context for when to use this tool: for epoch battles with specific battle types. It clarifies duration constraints (epoch-boundary types fixed to epoch end, others user-set), which is helpful for parameter selection. However, it does not explicitly mention alternatives or when not to use this tool, lowering it from a 5.

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

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

With no annotations, the description carries the burden. It discloses the resolution mechanism ('Platform resolves via on-chain governance data') and mentions a 0.5 SOL seed, implying a financial requirement. However, it omits other behavioral traits such as what exactly happens on creation (e.g., whether the battle is immediately active, funds escrowed, or a market ID returned), and it doesn't clarify the authToken requirement beyond the schema.

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

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

The description is two sentences, front-loaded with the core action, and every word adds value. It efficiently communicates the purpose, resolution mechanism, cost, and duration constraint 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?

For a tool with 6 parameters and no output schema or annotations, the description gives key constraints (seed, duration) and resolution context, but it lacks guidance on the creation flow (e.g., what inputs are required for a valid governance proposal, how the durations interrelate, or what the user should expect as a response). It is minimally complete but leaves gaps.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a duration range ('15-120 min') but doesn't explicitly map it to bettingDurationSeconds or eventDurationSeconds, and it doesn't add meaning beyond the schema's per-property descriptions. No extra parameter guidance is provided.

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 function: creating a structured governance proposal outcome market, distinguishing it from other battle creation tools. It specifies the resource (governance proposal), the question ('will it pass or fail?'), and adds context about resolution via on-chain data.

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

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

The description provides clear context on when to use this tool: for governance proposal outcome markets, with specific parameters like 0.5 SOL seed and duration limits. While it doesn't explicitly name alternatives or exclusions, the specificity makes the use case evident among the many create_*_battle 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, the description carries the full burden. It discloses key behaviors: Phase 1 returns intentId and persists for 30 days; Phase 2 graduates to an on-chain job with budget escrow and fraud protections. It also mentions the persistence duration and return value, giving the agent a clear picture of side effects without needing 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 front-loaded with a clear purpose sentence and then structured logically: flow, phases, prerequisites. Every sentence contributes value, but it is slightly longer than necessary. For example, the TMB-escrow flow details could be condensed. Still, it is well-organized and readable.

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

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

Given the tool's complexity (5 params, no output schema, no annotations), the description covers essential context: what the tool does, the two-phase model, prerequisites, return value, and persistence. It lacks explicit error handling or expiration behavior after 30d, but it provides enough for an agent to invoke the tool correctly and understand its role in the larger workflow.

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 covers 100% of parameters with detailed descriptions, so the baseline is 3. The tool description adds minimal parameter-specific meaning beyond what the schema already provides. It mentions the service path prerequisite (mcpEndpoint/a2aEndpoint) and that budgetUsdc can be left unset for pre-quote intent, but those details are also in the schema. Thus, it doesn't significantly elevate 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 opens with a specific verb and resource: 'Log an intent to hire an external ERC-8004 agent via TrenchFu's TMB-escrow flow.' It clearly separates the tool from siblings like create_tmb_job by explaining it is Phase 1 (storing intent) versus Phase 2 (graduation to real job). This distinguishes it from related tools.

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

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

The description gives an explicit prerequisite: 'first call get_external_agent to confirm the target exposes mcpEndpoint or a2aEndpoint — agents without either cannot be TMB-escrow-hired here.' It also explains the two-phase flow, implying when to use this tool (before actual job creation). However, it does not explicitly name a sibling tool as an alternative for Phase 2 (like create_tmb_job), so it lacks a full when-not-to-use statement.

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

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

With no annotations, the description carries the burden of disclosing behavior. It substantively covers the 10% commission on purchases, the auto-approval vs. review workflow based on 8004 registration, and the agent profile requirement. It omits response/status details but still provides meaningful behavioral context beyond the schema.

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

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

Three sentences, front-loaded with the core purpose, then pricing, then approval/prerequisite. Every sentence delivers operational value with no redundancy or fluff.

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 13-parameter tool with no output schema and no annotations, the description provides essential business logic: the 10% fee, the review/auto-approval distinction, and the required agent profile. It does not describe return values or post-submission status, but the given context is sufficient for basic selection and invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds commission context, but the seller_wallet schema already states 'receives payment minus commission', and the product-type examples mirror the listing_type enum. The description supplies minimal additional parameter-level 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?

The description opens with 'List a product or service on the marketplace', a specific verb with a clear resource, and gives examples (endpoints, bundles, tools, datasets). This clearly distinguishes create_listing from siblings like browse_listings, delist_listing, and purchase_listing.

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 implies when to use the tool: to sell a product or service. It adds prerequisites ('Requires agent profile (8004)') and approval conditions. However, it does not explicitly name alternative tools or when-not-to-use scenarios, though the verb and marketplace context make the main usage clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses key side effects: a 0.5 SOL seed requirement, a 5-15 minute duration constraint, and automatic resolution via live network data. It omits details like auth token requirements (present in schema) and return format, but covers the most critical behavioral expectations for a market creation 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 three sentences and under 60 words. Each sentence contributes distinct information: purpose, resolution mechanism, and cost/duration. There is no fluff, repetition, or ambiguous phrasing beyond the slight ambiguity of 'Duration' (likely battle duration, given the parameter).

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 exists, the description could benefit from specifying return values (e.g., market ID or transaction hash). It does adequately cover creation constraints, metric types, resolution mechanism, and cost, making it sufficient for an agent to invoke the tool correctly. The short length leaves minor gaps (e.g., unclear whether '5-15 min' is a battle duration or creation time), but overall it is complete for a creation tool with moderate complexity.

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

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

Schema coverage is 100%, providing a baseline of 3. The description adds value beyond the schema by constraining durationMinutes to a 5-15 minute range (schema only says 'Duration in minutes') and by enumerating the metric options in prose, reinforcing the enum values. It does not rename or obscure any parameters, so it fully complements 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 action ('Create') and the specific resource ('structured over/under market on Solana network metrics') with enumerated metrics (TPS, success rate, priority fees, block time). This distinguishes it from sibling battle-creation tools like create_governance_battle or create_validator_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 gives clear context by specifying the exact use case (creating over/under markets on network metrics) and how the platform resolves them (via live network data). It does not explicitly name alternatives or exclusions, but its specificity implies when this tool should be selected over other battle types.

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

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

With no annotations, the description carries the full burden and does well by disclosing the 0.5 SOL seed requirement, creator fee tier percentages, and automated data resolution (no tribunal). It does not detail failure responses or post-creation behavior, but the disclosed traits go beyond a generic create statement.

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 concise sentences front-load the core purpose, then add cost, fee tiers, resolution mechanism, and a clear alternative. Every clause provides information without redundant wording or filler.

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

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

For an 8-parameter creation tool without a return schema, the description effectively covers the market type, cost, fee structure, resolution method, and alternative tool. It does not explicitly state what the API returns (e.g., market ID) or prerequisites like wallet funding, but the seed cost implies funding, making it nearly complete for an agent's decision-making.

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 baseline is 3, but the description adds valuable context by linking creator fee tiers (NEW 25%, PROVEN 35%, ELITE 50%) to the creatorShareBp cap described in the schema. It also clarifies that tokenA/tokenB are competitors and explains automated resolution, which gives meaning to metricType and the overall market structure.

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 prediction market comparing two competitors on a specific metric, listing volume, trades, price, and unique_traders. It distinguishes itself from the sibling create_tmb_battle by contrasting structured metrics with freeform claim-based markets, making the purpose unambiguous.

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

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

Explicitly states when to use this tool (structured metric comparison) and when not to, directing users to create_tmb_battle for freeform claim-based markets. Also provides cost and fee tier context (0.5 SOL seed, creator fee tiers) that helps decide if this tool fits the use case.

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 clearly reveals a key behavioral trait: the creator becomes the resolver ('only you can settle the outcome'), and it warns about transaction rejection when constraints are not met. While it doesn't cover every behavioral aspect (e.g., return value, post-creation lifecycle), the most impactful traits are disclosed.

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

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

The description is a compact five-sentence paragraph, front-loaded with the core purpose and followed by essential preconditions and differentiators. Every sentence adds value with no filler, 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 complex tool with 13 parameters and no output schema, the description covers the essential workflow: pick a mode, write a claim, set outcomes, fund seed, attach evidence, and create the market. It also warns about constraints and suggests an alternative. It omits post-creation details like what response to expect, but the schema covers parameter-level specifics.

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 baseline is 3. The description adds meaningful context: modeId determines constraints on seed, duration, share, and bet sizes; evidenceHash is tied to the pin_evidence tool; creatorWallet becomes the resolver. This goes beyond simply restating the schema and helps the agent understand how the parameters interact.

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 begins with 'Create a claim-based prediction market (Trust Me Bro)', a specific verb+resource combination that clearly states what the tool does. It further distinguishes itself by explicitly directing structured data-driven markets to a sibling tool (create_permissionless_market), which separates it from alternatives.

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 gives an explicit prerequisite: 'Call browse_tmb_modes first to pick a modeId'. It also states the consequences of not meeting mode constraints ('transaction will be rejected') and names an alternative tool for different use cases. Additionally, it references the complementary tool pin_evidence for attaching evidence.

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 burden of behavioral disclosure. It explains that the budget is escrowed in the TMB market PDA, that a platform resolver prevents poster fraud, and that a dispute window protects workers—disclosing key on-chain behaviors. It does not mention irreversibility or potential fees, but the disclosed details exceed minimal expectations.

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 contain all essential information: purpose, mode, escrow, security mechanisms, and prerequisite. It is front-loaded with the core action and every clause earns its place.

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

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

For a tool with 10 parameters, no annotations, and no output schema, the description covers the core workflow but omits return-value expectations and fee enforcement conditions (e.g., when fee_payment_sig is required). The schema helps, but the description alone would leave an agent uncertain about post-creation tracking or server-side requirements.

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 covers 100% of parameters with meaningful descriptions, so the baseline is 3. The tool description adds value by explaining the evidence_hash workflow, but it does not provide significant extra semantics for other parameters beyond what the schema already has.

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

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

The description opens with a specific verb+resource: 'Create an on-chain TMB job contract.' It distinguishes this tool from siblings like create_tmb_battle and create_hire_intent by mentioning 'Job mode #2' and the escrow/dispute context. Purpose is unambiguous.

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

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

The description explicitly instructs to 'use pin_evidence first' to obtain the evidence_hash, providing a clear prerequisite and pointing to a sibling tool. It does not explicitly contrast with post_job or other alternatives, but the guidance is sufficient for a first-time user.

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?

Since no annotations are provided, the description carries the burden of behavioral disclosure. It adds useful context: on-chain resolution, 0.5 SOL seed cost, and duration range. However, it does not disclose side effects like whether a transaction is created, what happens on failure, or prerequisites such as wallet balance or validator validity.

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 short and front-loaded with the primary action. It contains no filler and communicates key constraints (cost, duration) in a compact way. However, the fragmented sentence structure and the duration discrepancy reduce clarity slightly.

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 no output schema and no annotations, the description provides some critical context (cost, resolution mechanism, metric choices) but omits important workflow details: what a successful response looks like, whether authToken is required beyond the listed params, and how the seed SOL is handled. The completeness is moderate.

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 baseline is 3, but the description introduces a conflicting duration range: schema says 5-120 minutes while description says 15-120 minutes. This inconsistency undermines trust. The description adds the seed cost and metric types, but the duration contradiction is a clear negative.

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 'validator vs validator battle' with specific metrics (performance, stake, skip rate, credits), distinguishing it from sibling battle tools like epoch, governance, network, and TMB battles. The verb 'create' and resource 'validator battle' are specific and unambiguous.

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

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

The description implies the use case (creating validator comparison battles) and provides context (on-chain resolution, cost, duration), but it does not explicitly explain when to use this tool over similar sibling tools or any exclusions. No alternatives 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 burden. It discloses the authorization requirement (seller-only) and the fact that the listing is removed. However, it does not state whether removal is permanent/irreversible, what happens on failure, or any side effects. It is adequate for a simple mutation but lacks some consequential detail.

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

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

Two short, front-loaded sentences with no filler. The first sentence states the action and resource, and the second sentence adds a necessary eligibility constraint. Every word earns its place.

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

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

For a simple 2-parameter tool with no output schema, the description plus schema provides sufficient information for selection and invocation. It could mention the result or success/failure behavior, but this is not a major gap for a straightforward delist operation.

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 already provides 100% coverage, including the seller_wallet description 'must match listing seller'. The description reinforces the seller-ownership rule but does not add materially new parameter-level information beyond what the schema provides. Baseline 3 is appropriate given 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 opens with the specific verb 'Remove' and clearly identifies the resource ('your listing from the marketplace'). This distinguishes it from siblings like create_listing, purchase_listing, and browse_listings. The additional constraint 'Only the seller can delist their own listing' further clarifies scope.

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 states when to use the tool: only the seller can delist their own listing. This implies the caller must be the seller and should not attempt to delist others' listings. It does not explicitly name alternatives, but the purpose is clear enough in the context of sibling tools.

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

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

No annotations are provided, so the description must carry the full burden of behavior disclosure. It adds the side effect of recording a job receipt with status tracking, but omits whether the operation is a read, write, or mutation, what happens on failure, or if it requires specific permissions beyond a registered profile. This is insufficient for a routing/execution 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?

Two concise sentences, front-loaded with the primary verb and resource, followed by the key side effect and prerequisite. 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?

With no output schema, the description vaguely mentions a 'job receipt' but does not explain the return value shape or whether it's synchronous. The tool involves routing to an operator, which adds complexity that could benefit from more context (e.g., error handling, async behavior). The prerequisite about agent profile helps, but overall completeness is moderate.

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% (all three parameters have descriptions), so the baseline is 3. The description does not add additional meaning beyond the schema for parameters like service_name or operator_wallet, but it does introduce the concept of passing 'params' object, which is present in the schema but not elaborated further.

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 uses specific verbs ('route', 'records') and resource ('service operator', 'job receipt'), clearly distinguishing it from sibling tools like list_services or register_service. It names the core action and outcome, though it doesn't explicitly contrast with alternatives.

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?

States the prerequisite that a registered agent profile is required, which gives some usage context. However, it doesn't specify when to use this tool versus alternatives like 'register_service' or 'list_services', nor does it mention any exclusions or fallback 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?

The description discloses one important behavioral trait: the wallet continues to work normally after export, indicating the operation is non-destructive. However, it does not warn about the sensitivity of exposing a private key or any security implications. With no annotations, the description carries the full burden, and while some context is added, more could be said about the risks.

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 no wasted words. It front-loads the purpose and adds a relevant behavioral note. Every part of the description 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?

This is a simple tool with one parameter and no output schema, so the description does not need to explain return values in detail. The purpose, use case, and a key behavioral trait are covered. It is slightly incomplete because it does not mention the format of the returned private key, but this is a minor gap given the simplicity.

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 has full coverage for the single parameter agentId, which includes a description. The tool description does not add any additional parameter semantics beyond what the schema already provides. The baseline 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 specific verb 'Get' and the resource 'your wallet's private key', and it explicitly mentions the use case of importing into Phantom, Solflare, or any Solana wallet. This distinguishes it from related sibling tools like provision_wallet or wallet_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 provides a clear context for when to use the tool: when the user wants to import their wallet into another wallet application. It also reassures that the wallet continues to work normally after export, which implies non-destructive usage. However, it does not explicitly mention when not to use it or recommend 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?

With no annotations provided, the description carries the full transparency burden. It explicitly discloses the return payload (reward pool, time remaining, progress, etc.) and the fallback behavior when no active season exists, which is strong behavioral disclosure for a read-only getter.

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 action ('Get...') and uses a dash-enumerated list to convey detailed return fields without any wasted words. Every element adds value.

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

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

For a zero-parameter read tool with no output schema, this description is self-sufficient. It specifies exactly what will be returned and covers the primary edge case (no active season) by stating the upcoming season is returned. No significant information is missing.

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

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

The tool has zero parameters and schema coverage is trivially complete, so the baseline for zero-param tools applies. The description appropriately adds no parameter semantics since there are none to describe.

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 the currently active competitive season and enumerates the key data fields (name, reward pool, time remaining, progress, participants, qualification). The specific scope 'currently active' and fallback to upcoming season make it distinct from season-related sibling tools like leaderboard or rank.

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 the tool is used when you need the active season's details, and the fallback behavior is noted. However, it does not explicitly mention when to choose this over sibling season-related tools or provide alternative guidance, leaving usage to inference.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses useful behavioral context: the return fields (edge %, confidence, recommended position size) and that it is a premium per-call service that deducts from wallet balance. It does not mention rate limits, auth requirements, or behavior on insufficient balance, but the disclosed cost and return info give a reasonable picture.

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: a single purpose sentence, a return-field sentence, and a premium/cost note. It is front-loaded with the most important info and contains zero filler. Every sentence earns its place.

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

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

For a tool with only 2 optional parameters, no output schema, and no annotations, the description provides a solid overview: what it does, what it returns, and the cost implication. It does not elaborate on the meaning of 'edge %' or 'confidence', nor the format of returns, but given the simplicity of the parameters and the inclusion of return field names, it is sufficiently 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% for both parameters, so the baseline is 3. The description does not add any extra meaning beyond the schema—it mentions edge % and min_edge only in passing, but the schema already defines 'Minimum edge percentage to include' and the valid categories. No additional semantic context is provided.

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 a specific verb and resource: 'Get current arbitrage opportunities across prediction markets.' It also mentions the key return fields, making the purpose unmistakable. However, it does not explicitly distinguish itself from sibling opportunity-focused tools like get_flash_opportunities or get_market_signals, so it falls just short of a 5.

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

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

The description implies usage (use this when looking for arbitrage opportunities across prediction markets) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. There is no mention of prerequisites or when not to use it, so it only meets the level of implied 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, the description carries the full burden of behavioral disclosure. It explains that suggestions are 'curated' and 'pre-filled', describes the return structure ('title, reasoning, competitors with metrics, and suggested duration'), and notes the data authenticity ('same data humans see'). While it doesn't explicitly state read-only behavior, the verb 'Get' and the overall context strongly imply it. No contradictions.

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 category examples, return structure, and usage guidance. Every sentence adds value, and there is no fluff or repetition. It is concise yet comprehensive.

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 absence of an output schema, the description adequately covers the return values by specifying the fields included in each suggestion. It also explains categories and provides a usage scenario. For a simple read-only tool with two optional parameters, this description is 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 coverage is 100% for both parameters. The description adds no significant parameter-level detail beyond the schema; it reiterates the categories already listed in the 'category' parameter description. Therefore, baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Get curated battle suggestions with pre-filled parameters'. It specifies the data source ('the same data humans see on the Solana Arena page') and enumerates content categories, distinguishing it from sibling tools like create_battle_from_suggestion and get_arb_opportunities. The verb 'Get' plus a specific resource makes the purpose unambiguous.

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

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

The description provides a clear usage context: 'Use this to find opportunities for creating permissionless markets.' This indicates when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, though the use case is well 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?

With no annotations, the description carries the full burden. It lists the intelligence content (congestion scores, military presence, anomalies) but does not disclose side effects, data freshness, permissions, or return behavior. For a read tool, it's minimally adequate but lacks depth.

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

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

A single, dense sentence that front-loads the core concept and lists concrete details. No wasted words, and the em dash structure is 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 0-parameter tool with no output schema, the description names specific chokepoints and data categories, giving reasonable coverage. However, it does not indicate the response format or how the results should be interpreted, and it doesn't help differentiate usage among the many sibling intel tools.

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 zero parameters, so the baseline is 4. The description does not need to elaborate on parameters since there are none, and the schema coverage is trivially 100%.

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

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

The description clearly identifies the tool's focus on maritime and aviation chokepoints, listing specific locations and data types (congestion, military presence, traffic anomalies). This distinguishes it from many siblings, though it doesn't explicitly contrast with other Intel tools.

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

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

No guidance is given on when to use this tool versus alternative intel tools like get_defense_intel or get_formation_intel. The description states what it does but provides no selection criteria 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, the description carries the behavioral disclosure burden. It adds useful context beyond the name: 'Higher CII = more actionable intelligence detected' explains interpretation, and 'Updated every 30 seconds' discloses freshness. It could mention output format or any access restrictions, but for a simple index getter, this is solid.

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 tightly written sentences. The first states the purpose, the second adds interpretive and freshness details. No redundant words, no repetition of the tool name. Every sentence earns its place.

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

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

For a tool with no parameters and no output schema, the description provides the essential semantics (what CII means), domain coverage (16 domains), and update cadence. It lacks a concrete example of output or score range, but given the simplicity, this is adequate. The only minor gap is not stating units or possible values.

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

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

The tool has zero parameters, so parameter semantics are trivially satisfied. The description adds no parameter details (none exist), and the baseline for 0 params is 4. It correctly omits irrelevant parameter information.

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: it provides 'Compound Intelligence Index — aggregated intelligence scores across all 16 domains.' This is a specific resource ('CII') with a clear domain scope, distinguishing it from sibling get_* tools like get_market_signals or get_arb_opportunities.

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 this tool versus alternatives. While it is a simple read-only retrieval with no parameters, the description does not mention cases where a user might prefer other intelligence-related tools or exclude certain contexts. This is a basic lack of usage 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?

With no annotations, the description must carry the burden of behavioral disclosure. It states that it returns a list of claimable positions with payout amounts, implying a read-only operation, but does not explicitly state that no side effects occur or that it requires no special authentication beyond wallet address. It is adequate but not rich.

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

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

The description is two sentences, front-loaded with the primary purpose, and includes the key output detail (list with payout amounts). Every word earns its place with no 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?

For a simple one-parameter read tool with no output schema, the description explains what the tool does and what it returns. It does not cover error conditions or edge cases, but given the simplicity and the clear schema, it is sufficiently complete for an agent to select and invoke the tool 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?

The input schema already describes the only parameter 'wallet' as 'Your wallet address' with 100% coverage. The description adds no additional meaning or constraints beyond what the schema provides, so it meets the baseline score.

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

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

The description uses the specific verb 'Check' with the resource 'your bets that are claimable', and clarifies with 'won bets on settled markets'. This clearly distinguishes it from sibling tools like claim_winnings (which claims) and place_bet (which places bets).

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 the tool (when you need to see claimable bets), and the read-only nature is implied by 'Check' and 'Returns list'. However, it does not explicitly mention alternatives or when not to use it, so it doesn't reach a 5.

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

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

With no annotations, the description carries the full burden. It discloses the auth token prerequisite and the data returned, which is useful. However, it does not cover potential errors, edge cases, or whether the tool is read-only (though 'get' implies that), leaving some behavioral ambiguity.

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 compact and information-dense: two sentences covering purpose, output fields, and auth requirement. No filler or repetition, though the run-on first sentence slightly reduces 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?

For a simple two-parameter tool with no output schema, the description adequately covers what the tool returns and the auth prerequisite. It does not elaborate on the meaning of tiers or the per-market breakdown structure, but that is beyond what is necessary for basic invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only the note that the auth token is 'same as create_permissionless_market', which is redundant given the schema already specifies 'from provision_wallet or refresh_token'. Thus, it adds no meaningful 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?

The description clearly states the tool's function: 'Get your creator earnings' and specifies the exact outputs (total fees, creator tier, share percentage, per-market breakdown). This distinguishes it from sibling getters like get_my_positions and get_referral_stats by focusing on creator-specific earnings.

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 checking creator earnings ('Get your creator earnings') and notes the auth token requirement, but it does not explicitly compare with alternative tools or state when not to use it. There is no mention of excluding other getters, so guidance is 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 are provided, so the description carries the full burden. It mentions aggregating from 16 domains but does not disclose whether this is a read-only operation, return format, or any side effects. For a 'get' tool, this is a notable gap.

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

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

The description is a single, well-structured sentence. It is concise, front-loaded with the main action, and every phrase adds value, including the examples and domain count.

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 has no parameters and no output schema, the description provides sufficient context for basic usage. It explains what the tool returns and gives concrete examples. Some behavioral details are missing, but they are covered under transparency.

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

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

The tool has zero parameters, so the schema is trivially covered. The description does not need to add parameter semantics; baseline for 0 params is 4.

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 gets cross-domain correlation signals, with specific examples (weather→energy, maritime→oil) that distinguish it from sibling single-domain intel tools. The verb 'Get' plus resource 'cross-domain correlation signals' is specific and unambiguous.

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

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

Usage context is implied: use when you need correlations across domains rather than single-domain intel. However, no explicit alternatives or exclusions are mentioned, so the guidance is not fully developed.

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

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

With no annotations, the description does some work by disclosing the return format ('Returns structured intel with timestamps and source attribution'). However, it does not mention potential latency, empty results, or any side effects, leaving some behavioral aspects undisclosed.

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

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

The description is three concise sentences. It front-loads the core purpose, then covers usage, then output format. Every sentence adds value and there is no filler.

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

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

For a simple single-parameter get tool, the description covers what the tool does, how to filter, and what it returns. It would benefit from clarifying the distinction between categories (e.g., does 'defense' include ACARS?) and from differentiating against the many sibling intel tools, but overall it is adequate.

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 already fully describes the category parameter with its options and default, so baseline is 3. The description adds the meaning of 'all' as 'everything' and reorders the categories, but this is marginal added 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?

The description clearly identifies the tool as providing defense and military intelligence, specifically naming ACARS military traffic, exercises, and conflict zone data. This distinguishes it from other intel tools to some degree, though no sibling tool is explicitly named.

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 guidance on how to use the category parameter ('Use category "all" for everything, or specific categories'), but does not explain when to choose this tool over related intel tools like get_force_posture or get_chokepoint_intel. No 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?

No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation, and the listed metrics clarify the return content. However, it does not explicitly disclose potential behaviors like authentication requirements, rate limits, or whether the data is live or cached.

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, front-loaded sentence that immediately states the verb and resource, followed by a concise list of metrics. No extraneous 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 low complexity (no parameters, no output schema), the description adequately lists the specific data points returned, making the tool's purpose and output clear. It does not specify units or formatting, but for a simple stats tool this is sufficient.

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

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

The tool has zero parameters, so the description need not explain parameter usage. Baseline of 4 applies since there is nothing to add beyond the schema.

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

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

The description clearly identifies the tool's purpose: retrieving DFlow prediction market stats. It lists specific metrics (TVL, 24h volume, open interest, active markets), distinguishing it from sibling tools like get_market_status or get_platform_info.

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 about when to use this tool versus alternatives. The description simply states what it does without mentioning exclusions or alternative tools for other types of market statistics.

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?

There are no annotations, so the description carries the burden. It adds the behavioral trait 'signal-processed data' and 'returns', implying read-only access, but lacks details on permissions, rate limits, or response structure.

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 concise sentences. The first states the core purpose, and the second provides the necessary category enumeration and output behavior. No 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?

With no output schema, the description says only 'signal-processed data specific to the domain', which is vague. It does not describe the structure, pagination, or error behavior, leaving the agent uncertain about the return format for a generic enrichment tool.

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

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

The input schema only says 'Enrichment category name' with no enum, but the description enumerates all 16 valid categories. This is essential information that fully compensates for the schema's lack of enumeration, adding critical semantic value.

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 returns per-category enrichment data and explicitly lists valid categories, making the purpose clear. However, it does not distinguish itself from sibling tools like get_weather_intel or get_defense_intel that specialize in specific categories.

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 category list implies usage for those domains, but no explicit guidance is provided on when to use this tool versus the more specialized sibling tools, nor any exclusions or 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?

With no annotations provided, the description must carry the burden of behavioral disclosure. It does disclose meaningful behaviors: it resolves IPFS metadata, fetches reputation from an external marketplace, and notes that reputation is not indexed locally. This goes beyond a simple read operation and informs the agent about external dependencies and data sourcing.

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: two sentences that front-load the purpose and then enumerate the return payload. Every sentence adds value, and there is no redundant or filler 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 that there is no output schema, the description does a good job of explaining the return structure (on-chain record, IPFS metadata fields, reputation, explorer link) and providing useful marketplace context. It could be slightly more explicit about the response format or potential errors, but for a single-parameter tool this is sufficient.

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 the single required 'id' parameter described as 'Agent asset address (base58 Solana pubkey)'. The description doesn't add any additional meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description uses the specific verb 'Fetch' with a clear resource ('full detail for an external ERC-8004 agent') and enumerates exactly what will be returned (on-chain record, IPFS metadata, reputation, explorer link). This clearly distinguishes it from siblings like list_external_agents and search_external_agents, which are for listing or searching rather than fetching a single record.

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: 8004 is a separate marketplace and TrenchFu only reads it for discovery, implying when this tool is appropriate. However, it does not explicitly name alternative tools (e.g., search_external_agents) or state when not to use it, so it earns a 4 rather than a 5.

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

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

No annotations are provided, so the description must disclose behavioral traits itself. It conveys that the tool filters for 'time-sensitive' opportunities and mentions categories, offering some behavioral context. However, it doesn't explicitly state that this is a read-only operation or describe what happens on execution (e.g., no side effects, no auth requirements). The 'get' verb implies read, but the burden isn't fully met.

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 no fluff. The first sentence front-loads the core purpose, and the second adds a practical use case. Every word earns its place, making it both concise and 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 simplicity (2 optional params, no output schema), the description covers purpose, examples, and a use case. It doesn't describe the return format or ordering, but the core functionality is well-explained. The lack of an output schema is somewhat mitigated by the straightforward nature of a 'get opportunities' tool.

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

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

The input schema already provides 100% coverage for both parameters (type and limit), including values and defaults. The description adds no additional parameter-level detail beyond mentioning the categories that mirror the type filter. Baseline of 3 applies given the 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 time-sensitive opportunities, listing specific examples (markets about to expire, validator flash candidates, governance votes closing soon). This distinguishes it from sibling tools like get_kalshi_markets or get_validators which likely return broader listings.

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 gives a clear use case: 'Great for creating short-duration TMB or permissionless markets.' This implies when to use it, but doesn't explicitly exclude alternatives or name specific competing tools. The context is clear, though not exhaustive.

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

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

With no annotations, the description carries the full burden. It transparently discloses the scoring calculation, the scope (air and naval only), and the regional/temporal focus. It does not disclose data freshness, output format, or how regions are defined, but for a simple getter this is relatively transparent.

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 concise sentences. The first front-loads the purpose, and the second details the scoring formula and tracking function. No redundancy or filler.

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

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

For a zero-parameter, no-output-schema tool, the description covers the key aspects: purpose, computation, and tracking. Minor ambiguities around 'region' definitions and output shape prevent a 5, but it is complete enough for a simple read operation.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics because there are none, but it does explain what the tool computes, which is sufficient.

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 it provides 'Regional military force composition — combined air+naval presence per geographic region' with a specific scoring formula. This distinguishes it from sibling intel tools like get_defense_intel or get_chokepoint_intel by its focus on force posture and scoring.

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

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

No explicit when-to-use or alternative guidance is provided. However, the phrase 'Tracks buildup and drawdown' implies the tool is useful for monitoring changes over time, which serves as a weak usage hint. It does not name alternatives or exclusions.

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

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

With no annotations, the description carries the full burden. It mentions the analysis approach (ADS-B/AIS) but does not disclose read-only behavior, potential rate limits, or what the returned data looks like. The lack of such context makes it hard for an agent to anticipate side effects or output complexity.

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, compact sentence that quickly conveys the core purpose and data sources. Every word adds value, and it is well structured with a topic phrase followed by explanatory detail.

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

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

With no output schema and no annotations, the description should clarify what the agent will receive from the tool (e.g., a report, list, or signals) and give scenario-based guidance. It lacks both, and it also does not differentiate from the many sibling intel tools, leaving the agent without enough information to judge if this tool fits the task.

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

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

The tool has zero parameters, so the schema imposes no burden. The description does not need to explain parameter meaning, and the baseline for no parameters is 4.

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

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

The description clearly identifies the tool as detecting military formations via ADS-B and AIS data, with specific examples like coordinated movements and force posture changes. While it distinguishes from some siblings by the specific detection focus, it does not explicitly differentiate from related intel tools like get_defense_intel or get_force_posture.

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 alternative intel tools. It does not mention conditions, prerequisites, or alternative tools, leaving the agent without a clear selection strategy among many similar sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It states coverage ('Covers all Realms DAOs') and hints at behavior via status filter, but it doesn't disclose return format, pagination, or explicitly confirm read-only nature (though 'Get' implies it). It adds some context but lacks richer behavioral detail.

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 exactly two sentences: the first states the core function, the second adds a compelling use case and scope. No filler or redundant information. It's front-loaded and 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 simple get tool with optional params and no output schema, the description covers the essential scope and use case. It doesn't describe the return value structure, but that's not critical for a list operation. Given the schema fills in parameter details, the description is 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 both parameters (limit and status) are documented structurally. The description adds marginal value by linking 'close deadlines' to the 'flash' status value, but it doesn't explain limit or go beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get active Solana DAO governance proposals.' It clearly distinguishes from siblings by specifying 'Solana DAO' and adds scope with 'Covers all Realms DAOs.' This makes the tool's function obvious and unique among the many get_* tools.

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

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

The description provides clear context on when to use the tool: 'Proposals with close deadlines make great prediction markets (will it pass?)' This implies a predication-market use case. However, it doesn't explicitly state when not to use it or mention alternatives like browse_markets, so it falls short of a full 5.

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

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

No annotations are provided, so the description carries full burden. It implicitly indicates a read operation but does not disclose any behavioral traits like auth requirements, error handling, or return format. For a getter this is a notable gap.

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

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

The description is one concise sentence that immediately states purpose and included fields. No filler or redundant information.

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

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

For a simple one-parameter read tool with no output schema, the description sufficiently conveys what is returned (bids, status, settlement info). It is reasonably complete, though it could mention return structure.

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 'Job ID' for job_id. The tool description adds no extra meaning beyond 'specific job', so the baseline score of 3 is appropriate.

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

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', listing key contents (bids, status, settlement info). This distinguishes it from listing tools like get_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 implies use when a specific job_id is known, but provides no explicit when-to-use vs alternatives, such as mentioning get_jobs for listing all jobs. No exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a safe read operation and 'Free tier' adds cost context, but it doesn't disclose pagination behavior, return format, or rate limits. It provides some value but not rich behavioral detail.

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, with the primary purpose in the first sentence. The second sentence adds useful context, though the erroneous 'budget range' reference wastes a few 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?

For a simple listing tool with no output schema, the description covers the core purpose and filters, but the misleading budget-range mention and lack of note about default limit/pagination leave minor gaps. It's adequate but not exemplary.

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 covers all parameters with descriptions (100% coverage), so the baseline is 3. However, the description mentions a 'budget range' filter that does not exist in the schema, and it omits the 'limit' parameter entirely. This misleading extra and omission reduce clarity.

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

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

The description states a specific action ('List open jobs') and resource, which distinguishes it from single-job lookups like get_job_detail. However, it doesn't explicitly differentiate from similar browsing tools like browse_listings, so it doesn't fully earn a 5.

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

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

The phrase 'Free tier — browse the job board' gives clear context that this is a no-cost browsing operation. It doesn't provide explicit when-not-to-use or alternatives, but the context is sufficient for a straightforward listing tool.

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 burden of behavioral transparency. It explicitly states the read-only nature ('Browse') and clarifies that direct Kalshi trading is unavailable due to DFlow Proof verification. This is valuable context about what the tool can and cannot do, though it doesn't go into details like rate limits or pagination.

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 exceptionally concise: two sentences plus a terse note. The first sentence immediately states the verb and resource, the second adds the use case, and the note covers a critical limitation. 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 simplicity (read-only browse, 3 optional params, no output schema), the description adequately covers the core purpose, the type of data visible ('real-world events with active markets'), and a key limitation (no trading). It could have hinted at response format, but the phrase 'See what real-world events have active markets' implies a list of markets, which is sufficient for this 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 already documents all three parameters (limit, status, category) with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides. It simply frames the overall purpose, so baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Browse Kalshi prediction markets for inspiration.' It names a specific resource (Kalshi prediction markets) and a specific verb (browse), and distinguishes itself from sibling tools like browse_markets by focusing on external Kalshi data. The purpose is further reinforced by stating the intended downstream use: create equivalent TMB or permissionless markets on TrenchFu.

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: it is for browsing Kalshi markets to inspire the creation of TMB/permissionless markets on TrenchFu. It also warns that direct Kalshi trading is not available. However, it does not explicitly mention alternative tools for browsing TrenchFu's own markets, so there's a slight gap in direct 'when vs. alternatives' 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 burden. Though the name and phrasing imply a safe read-only operation, it never explicitly states there are no side effects, nor does it mention edge cases like closed markets. This leaves behavioral transparency minimal.

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 with no unnecessary words. The first sentence states the action and outputs, and the second provides immediate usage context. Every phrase earns its place.

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

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

For a simple getter, the description adequately conveys the main output categories (pool sizes, implied odds, simulated payout) and scope (all market types). It does not detail return format or error handling, but given the lack of output schema and the tool's simplicity, it remains complete enough.

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?

All three parameters have schema descriptions, giving a baseline of 3. The description adds context by framing outcome and amountSol as simulation parameters ('simulate payout'), but this largely reinforces the schema rather than adding new 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?

The description uses a specific verb 'Get' and clearly defines the resource: 'current pool sizes, implied odds, and simulated payout for a market.' It also distinguishes itself from siblings by emphasizing the pre-betting simulation use case and supporting 'all market types (platform + TMB).'

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

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

Provides explicit timing context: 'Call before betting to understand the risk/reward at current pool ratios.' This is clear when-to-use guidance, but it does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses the tool's behavior: it returns a specific set of fields, operates on a 15-minute settlement timeframe, and accepts a crypto asset ticker. It doesn't state side effects (e.g., read-only), but 'Get' implies introspection, and the listed return values provide meaningful behavioral context.

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

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

Two sentences, front-loaded with the core purpose, followed by low-noise details (valid assets, alternative tool). Every phrase earns its place; no 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?

For a single-parameter tool with no output schema, the description is fairly comprehensive: it names the data source, the return fields, the valid inputs, and the alternative for a different use case. Could add response format details or error behavior, but for the complexity level it is nearly 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?

The input schema already provides 100% coverage with a description and enum for 'ticker'. The description repeats the valid assets exactly, adding no new parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description opens with a specific verb+resource: 'Get 15-minute settlement predictions for a crypto asset from the density engine.' It clearly states what is returned (predicted price, actual price, confidence, accuracy stats, calibration) and explicitly distinguishes from a sibling by directing Kalshi market-level signals to get_market_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?

The description provides explicit usage context: valid asset list (BTC, ETH, SOL, XRP) and a clear 'when not to use' with an alternative tool: 'For Kalshi market-level signals (KXBTCD, KXHIGHCHI-*), use get_market_signals instead.' This perfectly guides the agent.

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 that the tool returns multiple real-time data points (prediction, accuracy, DFlow price, WebSocket price) and implies read-only behavior via 'Get.' This adds useful context beyond the name, though it doesn't explicitly state side effects or rate limits, which are not expected for a simple retrieval 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 three sentences with a clear structure: first states the core purpose and outputs, second gives usage direction, third provides the alternative. No redundant or fluffy 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 two well-documented parameters and no output schema, the description covers the essential information: return data, usage context, and alternative tool. It doesn't explain error handling or all possible return fields, but for a simple retrieval tool with good schema coverage, it's sufficiently 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 both parameters (ticker and window) fully described in the schema, including examples and valid window values. The description itself adds a few ticker examples but doesn't significantly extend the schema's semantics. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get real-time signal intelligence for a Kalshi/DFlow market ticker.' It lists return data (prediction, accuracy, DFlow price, WebSocket price data) and explicitly distinguishes from sibling get_market_predictions by specifying Kalshi tickers.

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 when-to-use and when-not-to-use guidance: 'Use THIS tool for Kalshi tickers (KXBTCD, KXHIGHCHI-*, KXLOWTNYC-*). For crypto asset predictions (BTC/ETH/SOL/XRP), use get_market_predictions instead.' It names the alternative directly.

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 present, so the description itself indicates this is a read-only 'Get' operation and lists the specific status fields returned. This helps set expectations for return content, though it does not address potential staleness, authentication, or other behavioral nuances.

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

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

A single, information-dense sentence that front-loads the purpose and immediately lists the key data fields. No wasted words, and it 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?

This is a simple one-parameter getter with no output schema, and the description's enumeration of returned fields effectively compensates for the missing output schema. It is largely complete for such a straightforward tool, though a brief note on when to prefer this over related sibling tools would make it fully 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?

The input schema fully documents the single marketId parameter with the description 'Market ID or PDA', giving 100% schema coverage. The tool description adds no extra parameter semantics beyond implying the market is 'specific', so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Get') with a clear resource ('a specific market') and enumerates the detailed data returned (pool sizes, odds, bet count, settlement status, time remaining). It is clear and distinguishable from broader browse tools, though it does not explicitly differentiate from the sibling 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?

The wording implies this tool is for fetching detailed status data for a single market, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like get_market_pools or browse_markets. Usage context is only inferred.

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

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

The description implies a read-only operation via 'Get' and notes it 'Returns portfolio summary with unrealized gains', which adds some behavioral context. However, with no annotations, it does not disclose potential prerequisites (e.g., wallet ownership verification), pagination, or error cases.

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

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

The description is concise, front-loaded with the core action, and contains no fluff. Two sentences effectively convey purpose and return value.

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

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

Given the simple one-parameter schema and no output schema, the description is sufficiently complete: it specifies scope (open positions, bets, P&L) and return content (portfolio summary with unrealized gains). It could mention overlap with similar tools, but this is not critical.

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 fully describes the sole parameter 'wallet' with 'Your wallet address' (100% schema description coverage). The description does not add any additional meaning about the parameter beyond what the schema already provides.

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

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

The description clearly states 'Get all your open positions, bets, and P&L across all markets', using a specific verb and resource. It distinguishes from sibling tools like get_my_purchases (purchases vs positions) and get_portfolio_detail (specific to P&L/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 provides clear context that this is for the user's own positions, but it does not explicitly mention when to use it instead of alternatives like get_portfolio_detail or get_my_purchases. No exclusions or alternative tool names are given.

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

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

With no annotations provided, the description carries the full burden. It states the tool returns purchase records and active leases, implying a read-only getter operation. However, it does not explicitly mention whether there are any side effects, authentication requirements, or rate limits. The optional include_leases parameter's behavioral effect (fetching backend data) is only described in the schema, not the 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?

Two concise sentences with no wasted words. Front-loaded with the core action 'Get your purchase history,' followed by clarifying details. Every word 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?

The tool is simple (2 params, no output schema). The description states what it returns (purchase records and active leases), covering the basic return values. The schema handles parameter details. However, the description could be slightly more explicit about the conditional inclusion of leases based on include_leases, but overall it's fairly complete for this complexity level.

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% (both wallet and include_leases have descriptions), so the baseline is 3. The description adds some context by mentioning lease details and active leases, which aligns with include_leases, but it doesn't add meaningful syntax or format details beyond what the schema already provides. The wallet parameter is not explicitly discussed in the description, though 'your' implies it.

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 function: getting the user's purchase history, with specific details about what's included (listings bought, provisioning status, lease details). It distinguishes itself from sibling tools by its unique resource (purchases vs positions, season rank, etc.), using a specific verb and resource.

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: use when you need your purchase history or active leases. However, it provides no explicit guidance on when to use this tool instead of alternatives, nor any exclusions or conditions. No alternative tool is referenced.

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

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

With no annotations, the description carries the full burden. It lists the output fields (points, XP, bets, wins, losses, win rate, volume, qualification status, rank change), which is useful. However, it does not disclose any potential side effects, authentication requirements, error conditions, or whether the wallet must be the caller's own. The read-only nature is implied by 'Get' but not explicitly stated.

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

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

The description is a single, information-dense sentence followed by a clear prerequisite instruction. It is front-loaded with the main purpose and lists output fields without unnecessary fluff. Every word earns its place.

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

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

For a simple two-parameter read tool with no output schema, the description covers the essential usage: what data is returned and how to obtain the seasonId. It lacks an explicit return format description, but the enumerated stats give the agent a good sense of expected output. This is largely complete for this 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?

Both parameters are fully described in the input schema (100% coverage), so the description adds limited new parameter info. It does reinforce that seasonId comes from get_active_season ('Use get_active_season first'), but this is also noted in the schema's seasonId description. The description does not add format or usage details 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's purpose: 'Get your rank and stats in the current season' and enumerates specific fields (points, XP, bets, wins, etc.). It uses a specific verb+resource pair and implicitly distinguishes itself from sibling tools like get_season_leaderboard by focusing on the user's own rank.

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 guidance by instructing 'Use get_active_season first to get the season ID.' This establishes a clear prerequisite. However, it does not explicitly mention when to prefer this tool over alternatives like get_season_leaderboard, though 'your rank' implies personal versus global scope.

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 responsibility for behavioral disclosure. It does indicate the tool is read-only in nature ('Shows'), but it omits details about output format, potential side effects, authorization requirements, or any limitations. The listing of components (priming signals, etc.) gives some insight, but not enough for a complete behavioral profile.

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, composed of two sentences that quickly introduce the core function and then elaborate with a concrete outcome. It avoids redundancy and front-loads the key term 'narrative intelligence', though the initial list of concepts is slightly less structured than a straightforward verb phrase.

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 has no parameters, no output schema, and no annotations, the description must convey how it works and what it returns. It adequately states the high-level purpose and implied read-only nature, but it does not explain the exact output structure or any potential errors/limits. This is acceptable for a simple zero-parameter get tool, but more detail on return format would improve 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 tool has zero parameters and the schema defines none, so there are no parameter meanings to clarify. Baseline for zero parameters is 4, and the description does not need to compensate for any schema gaps. It correctly provides no misleading parameter information.

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 indicates the tool provides narrative intelligence, listing specific capabilities (priming signals, causal chain detection, market-event narrative matching) and stating it shows how events propagate through markets. While it lacks a strong imperative verb like 'retrieve' or 'compute', 'Shows' serves as the main action, and the content distinguishes it from sibling intel tools by focusing on narrative propagation.

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

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

Usage context is implied but not explicit. The description suggests the tool is for understanding market narratives and event propagation, but it does not state when to prefer it over similar tools like get_market_signals or get_chokepoint_intel, nor does it mention any exclusions or alternative scenarios.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It lists what the tool returns (arenas, endpoints, URLs, documentation), which is useful, but it does not explicitly state that it is a read-only, side-effect-free operation or whether authentication is required. The 'Get' verb implies read-only, but the safety profile is not explicit.

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

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

The description is a single sentence that front-loads the core purpose ('Get TrenchFu platform info'), then lists examples with a dash, and ends with 'Start here.' Every part is purposeful and there is no redundancy or fluff.

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?

The tool is simple (zero parameters, no output schema, no annotations). The description adequately covers the main output categories and provides a clear entry point. It does not detail the return format, but for a platform info tool, listing the categories of information is sufficient.

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

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

The tool has zero parameters and the schema is empty with 100% coverage. The description does not need to explain parameter semantics, and the baseline score of 4 applies because there is nothing additional to add.

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

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

The description uses a specific verb 'Get' with a clear resource 'TrenchFu platform info' and lists concrete contents (arenas, SDK endpoints, market creation URLs, documentation). This distinguishes it from sibling 'get_*' tools that are narrower in scope.

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

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

The phrase 'Start here' gives explicit guidance to use this tool first, implying it is the entry point for platform-level information. It does not name alternatives or exclusions, but the context is clear enough given the tool's role as a general info provider.

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

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

With no annotations, the description carries the burden of disclosing behavior. It lists the covered position types and notes it is more detailed than the summary, but it does not mention caching behavior (despite a refresh parameter), authentication needs, or potential side effects. The content overview is useful, but behavioral traits beyond content are lacking.

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 action, and includes only essential comparative context (vs get_my_positions). No filler or repetition.

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

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

For a read-only portfolio tool, the description explains what is returned (individual positions, PnL, claimable amounts), how it differs from a sibling, and the schema covers parameters. It could mention output shape or when to use refresh, but overall it is sufficiently complete given the tool's simplicity.

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 provides 100% coverage with descriptions for wallet, refresh, and sessionWallets. The description adds no further parameter-specific meaning, so a baseline of 3 is appropriate since the schema carries the explanatory load.

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

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

The description uses a specific verb ('Get') and resource ('full portfolio with individual positions'), and explicitly contrasts with get_my_positions, making its purpose clear and distinct from a 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?

It directly states when to use this tool over get_my_positions (when more detail is needed), naming the alternative. It could be stronger by also mentioning when to choose other position-related tools, but the guidance is present and clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds context that the prices are 'real-time on-chain', which is useful, but does not disclose potential errors, rate limits, or return format. For a simple read-only tool, this is moderate 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 two sentences, front-loaded with the main action ('Get current Pyth oracle prices'), and every word adds value. It is concise without being under-specified.

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

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

For a tool with one optional parameter and no output schema, the description is adequate but leaves out the return value format and behavior when 'symbols' is omitted (though the schema covers the latter). It does not specify whether the result is a map or list, but for a simple price feed this is a moderate 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 already provides full coverage for the only parameter 'symbols' with examples and an explanation of omission behavior. The tool description adds no additional semantic detail beyond what the schema already states, so the baseline score of 3 applies.

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

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

The description uses a specific verb 'Get' and a clear resource 'Pyth oracle prices', with concrete examples (SOL, BTC, ETH). It clearly states what the tool does and is not a tautology. No sibling tools overlap with this price feed functionality, so it distinguishes itself sufficiently.

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 implies when to use this tool (when current Pyth prices are needed) and is set in a context of real-time on-chain data. However, it does not explicitly mention alternatives or when not to use it, which would warrant a 5. The provided context is clear enough 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?

The phrase 'Get or generate' discloses that the tool may either retrieve an existing code or create a new one, which is a key behavioral trait. It also explains the purpose of sharing. However, it does not disclose potential side effects, requirements, or return format, and there are no annotations to supplement 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 two short sentences that front-load the primary action and then explain the value proposition. Every word contributes; no wasted text.

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

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

For a simple single-parameter tool with no output schema, the description adequately conveys what the tool returns (the referral code) and why it is used. It is self-contained for the agent's decision-making.

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 already describes the wallet parameter fully ('Your wallet address'), so baseline is 3. The description adds context that the code is 'your' referral code, implying the wallet is yours, but no additional parameter-level detail is provided.

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 verb phrase 'Get or generate' clearly identifies the action and resource (referral code). It distinguishes itself from sibling tools like apply_referral (which applies a code) and get_referral_stats (which fetches stats) by focusing on obtaining/creating one's own code.

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: use this tool when you want your own referral code to share and earn fees. However, it does not explicitly mention alternatives or exclusions, such as using apply_referral to use someone else's code.

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 lists what is returned (earnings, tree, count, volume) which is useful, but it doesn't disclose whether any authorization is needed, error behavior, or whether the wallet must be registered. For a read-only get tool, this is adequate but not rich.

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

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

The description is a single, front-loaded sentence with no filler. Every element adds value.

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

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

The tool is simple with one parameter and no output schema. The description lists the key return items, which serves as a substitute for an output schema. It is reasonably complete, though it doesn't specify units or formatting.

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 a single 'wallet' parameter described as 'Your wallet address'. The description adds minimal extra meaning beyond implying ownership via 'your', so baseline 3 is appropriate.

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

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

The description uses a specific verb ('get') with a clear resource ('referral statistics') and enumerates the content: earnings, referral tree, number of referrals, total volume. This clearly distinguishes it from sibling tools like get_referral_code and get_creator_earnings.

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 the tool is for viewing one's own referral stats via the wallet parameter. It provides clear context for when to use it, though it doesn't explicitly mention 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?

With no annotations, the description discloses the primary output components and the tier-gated detail level for whales. It does not explicitly state that the operation is read-only, describe authentication requirements, or define behavior for incomplete/invalid task IDs, but the 'Retrieve' verb implies a non-mutating read.

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

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

Three short sentences front-load the action and then specify the return payload. No filler or redundancy; every sentence provides distinct information (action, return contents, access tier).

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 read tool without an output schema, the description covers the main purpose, input, and return fields. It does not address error handling or prerequisites (e.g., research must be completed), but 'completed' is in the description, and the tiering behavior is explained. This is reasonably 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?

Both parameters are already fully described in the schema (taskId sourced from submit_research; wallet for tier-gated access). The description adds minimal new semantic value—it mentions taskId and whale holders, but this is already captured in the schema's 100% 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 states a specific verb ('Retrieve') and a specific resource ('completed research dossier'), identifies the input ('taskId'), and describes the return content (conviction score, synthesis, settlement tracking). This clearly distinguishes it from sibling get_* tools like get_job_detail or get_market_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?

The description implies usage: call it when you have a research task ID and need the results. It does not explicitly name alternatives or exclusion criteria, but the schema notes taskId comes from submit_research. The tiering mention ('Whale holders get full specialist evidence chain') provides some context about access requirements but no when-not-to-use.

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

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

The description discloses pagination behavior (default 50, max 100) and the ranking nature of results. No annotations exist, so this transparency helps the agent understand the tool's behavior, though it doesn't cover all edge cases.

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

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

Two concise sentences front-load the tool's core purpose, then cover pagination and the prerequisite. 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?

For a simple getter without an output schema, the description covers the return contents (ranked players with listed stats) and pagination details, making it sufficient for an agent to invoke 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?

The schema already provides 100% coverage for all parameters, including descriptions for seasonId, limit, and offset. The description reinforces the seasonId prerequisite but adds minimal additional semantic value beyond the schema.

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