TrenchFu

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

No annotations provided, so the description carries full burden. It discloses staking (minimum 0.01 SOL) and automatic wallet signing, but does not mention idempotency, reversibility, failure modes, or whether it's read-only or destructive. Adequate but could be more thorough.

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 main action, then essential details. 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?

No output schema exists, yet the description does not mention what the tool returns (e.g., transaction hash, confirmation). For a 2-parameter tool with no output schema, the description could be more complete by indicating return behavior.

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

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

Schema coverage is 100%, and the description adds meaningful context: intentId origin (pending-hires poll/webhook) and accepterWallet constraints (must be owner, agentWallet, or operator). This adds value beyond the schema descriptions.

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

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

The description clearly states the action (accept a hire), the target (ERC-8004 agent), and key details (stake on TMB market, minimum SOL, automatic signing). It distinguishes from siblings like accept_tmb_job by specifying 'external hire' and ERC-8004 agent.

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 context (pending hire, stake, provisioning) but does not explicitly state when to use this tool vs alternatives (e.g., accept_tmb_job, bid_on_job). There is no 'when-not' or 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 provided, so description bears full burden. It discloses financial commitment (staking SOL), refundable bond, and prerequisites. However, it omits details on reversibility, side effects, or what happens after acceptance (e.g., confirmation steps). Add moderate value beyond 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 main action, then prerequisites. No fluff. Could be slightly more structured (e.g., bullet list), but efficient and clear.

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

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

Given 5 params, no output schema, no annotations, the description covers prerequisites and core flow. However, it assumes knowledge of TMB and does not explain overall process or post-acceptance expectations. Still adequate for an AI agent with access to sibling 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?

Schema coverage is 100%, baseline 3. Description adds value: clarifies 'stake_sol' is returned on delivery, explains 'fee_payment_sig' as MPP payment signature and conditional requirement (when TMB_JOB_FEES_ENFORCED=true). This enhances understanding beyond schema descriptions.

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

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

The description clearly states verb (accept), resource (TMB on-chain job), and specific action (staking SOL on Delivered outcome). It distinguishes from sibling tools like 'accept_external_hire' (different job type) and 'bid_on_job' (different action: bidding vs accepting).

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 prerequisites: requires a refundable acceptance bond paid first, job must be open with confirmed on-chain market, registered agent profile. It implicitly tells when to use (when these conditions are met) but does not explicitly contrast with alternative tools like 'bid_on_job'.

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

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

No annotations provided, so the description carries full burden. It mentions linking for fee sharing but does not disclose side effects, reversibility, error scenarios (e.g., invalid code, already linked), or any destructive behavior.

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

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

Two concise sentences with no filler. Front-loaded with the action, followed by the effect.

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 action with no output schema, the description adequately covers purpose and effect. Could benefit from noting return type or error handling, but not necessary for basic use.

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

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

Schema covers both parameters with descriptions identical to the tool description. The description adds no extra meaning over the schema, baseline 3 for 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 clearly states the verb 'apply' and resource 'referral code', and explains the purpose: linking accounts for fee sharing. It is distinct from sibling tools 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 usage context (when you have a referral code) but lacks explicit when-not-to-use or alternatives. However, given no competing apply tools, the context is clear.

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

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

Without annotations, the description carries the full burden. It states the action and a requirement, but does not disclose response behavior, bid limitations, or whether bids are modifiable. Minimal but not misleading.

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

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

Two concise sentences with front-loaded purpose. No wasted words.

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

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

Given 5 parameters, no output schema, and no annotations, the description is too brief. It lacks information on response format, bid validation, or side effects, leaving agents underinformed.

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 reinforces parameter roles (price, delivery estimate, approach) but does not add significant new meaning beyond schema descriptions.

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

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

The description clearly states the tool's action ('Submit a bid on an open job') and specifies the key components (price, delivery estimate, approach). This distinguishes it from sibling tools like accept_external_hire or complete_job.

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

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

The description implies usage for bidding on open jobs and mentions a prerequisite (registered agent profile), but does not explicitly state when to use this tool versus alternatives or provide 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 provided; description does not disclose read-only nature, authentication requirements, rate limits, or potential side effects beyond implying non-destructive browsing.

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

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

Two sentences, no redundancy, front-loaded with key purpose and action.

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

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

No output schema, and description fails to mention what fields are returned, how pagination works (limit parameter not explained), or any other output 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 covers 100% of parameters with descriptions; description only repeats the filter categories already present, adding no new semantic detail.

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

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

Description clearly states it is a browse operation for the marketplace with specific resources (230+ endpoints) and filters. Implicitly differentiates from sibling browse_markets but does not explicitly name it.

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 pricing context (free to browse, pay on purchase) but lacks explicit guidance on when to use versus alternatives or 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?

No annotations are provided, so the description carries the full burden. It states the tool browses all active markets and mentions result fields, but does not disclose behavioral traits such as read-only nature, pagination behavior, or error handling. It is 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?

The description is two sentences long, front-loaded with the core purpose, and contains no unnecessary words. It is well-structured 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?

While the description covers the main purpose and filter parameters, it lacks output schema details. The agent only learns that results include a 'type' field, but not the full output structure or any other fields. For a browsing tool, more detail about the result set 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?

Schema coverage is 100% with each parameter having a description. The description adds minor context by mentioning filtering by status and category, but does not provide additional semantics beyond what the schema already conveys. 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 it browses all active prediction markets, explicitly listing both platform-curated (with examples) and user-created types. It includes the distinguishing 'type' field. This differentiates it from siblings like browse_listings (jobs/items) and browse_tmb_modes.

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 filtering options (status, category) with defaults, giving clear usage context. However, it does not explicitly state when not to use this tool or mention alternative tools for more specific queries, though the sibling set does not have a direct overlap.

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

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

No annotations provided. Description implies read-only through 'List available', but does not explicitly state non-destructive behavior, auth needs, or idempotency. Minimal for a listing 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: first defines purpose, second details content and usage. Every sentence adds value; no 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?

Covers purpose, return value content, and usage hint. No output schema, but description compensates by listing the constraint types. Slightly incomplete on potential pagination or ordering, but adequate for a simple list 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?

No parameters in schema. Description adds context about returned mode constraints (fee caps, evidence requirements, etc.), which aids understanding. Baseline 4 for 0 params.

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

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

Clearly states 'List available TMB market modes', with explicit tie to create_tmb_battle. Differentiates from sibling browse tools by specifying the domain and linking to a specific next step.

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 this to pick a modeId before calling create_tmb_battle. Provides clear context for use but does not mention when not to use 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?

No annotations provided, but description fully discloses behavior: returns a URL with specific structure, requires signature, and explains redirect behavior. Adds value beyond 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?

Single paragraph with few sentences, no redundancy. While concise, it could benefit from bullet points for clarity, but still 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?

No output schema, but description explains return value format and key behavioral details (signature requirement, redirect). Sufficient for an agent to use correctly given the tool's complexity.

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

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

Schema coverage is 100%, baseline 3. Description adds detailed context for parameters like wallet (base58), signature (Ed25519 over message), and redirect_uri (defaults, allowed schemes), enhancing 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?

Description explicitly states it builds a KYC verification deep-link URL for identity verification, specifying the URL format and use case. It clearly differs from siblings like 'check_kyc_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?

Provides context on when agents can sign (for provisioned wallets) vs when humans must visit the link (for user-held wallets). Does not explicitly list alternatives but gives clear usage guidance.

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

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

The description discloses that it 'Proxies the public GET endpoint,' indicating a read-only, stateless operation with no side effects. It lacks details on rate limits or authentication, but the behavioral implication is clear.

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 (four sentences), each serving a distinct purpose: purpose, endpoint context, usage conditions, and practical guidance. No redundancy or unnecessary 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?

The description adequately covers what the tool does and when to use it. No output schema is provided, but for a simple boolean check, the response format is self-explanatory. The context is 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?

Schema coverage is 100% with the 'wallet' parameter already described. The description adds the endpoint context ('Proxies the public GET https://proof.dflow.net/verify/{wallet}'), which clarifies how the parameter is used 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 explicitly states the verb 'Check' and the resource 'whether a Solana wallet has completed DFlow Proof verification.' It distinguishes this tool from the sibling 'build_kyc_verification_link' by focusing on status checking, while also clarifying the context of verification requirements.

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 guidance: 'Use this before attempting a Kalshi buy to fail-fast...' and explains when verification is needed (only for buying DFlow/Kalshi tokens) and when it is not (selling, redeeming, etc.), giving explicit exclusions and 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, the description partially compensates by stating it returns access status, expiry, and tiers. However, it does not explicitly declare the tool as read-only or non-destructive, nor does it mention any side effects or authorization requirements, leaving some behavioral 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 extremely concise: two sentences that immediately state the purpose and what is returned. Every word adds value, with no filler or repetition.

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

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

While the description covers the basic return fields, it lacks details about error conditions (e.g., invalid promo ID), edge cases, or the exact structure of the response. Given no output schema and no annotations, more context would be beneficial for a complete understanding.

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

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

Schema coverage is 100% (both parameters have descriptions), so the baseline is 3. The tool description does not add any additional explanation or context beyond what the schema already provides (e.g., wallet address and promo ID).

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

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

The description clearly states the tool's purpose: checking active access from a promotional pass. It uses a specific verb ('check') and resource ('promotional access'), and the return fields (status, expiry, tiers) are explicitly mentioned, making it distinct from sibling tools like view_promo and purchase_promo.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., view_promo for general promo details). There is no indication of prerequisites, context, or when not to use it, leaving the agent without clear decision criteria.

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 partially reveals behavior: it creates an unsigned transaction rather than performing the final claim. However, it omits side effects, required authentication scope, or error conditions, which are critical for an agent to understand the tool's full impact.

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 short sentences that convey purpose and output without waste. Every word adds value, making it efficient for an agent to parse.

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

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

While the core purpose is clear, the description lacks critical workflow context: it does not mention that the agent must sign and broadcast the returned transaction, nor does it specify preconditions (e.g., market must be resolved) or failure modes. Given no output schema, these omissions reduce completeness for a mutation-like tool.

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

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

Schema coverage is 100%, and schema descriptions already adequately explain each parameter. The description adds no extra parameter context beyond the tool's 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 verb 'claim', the resource 'winnings from a resolved TMB market', and the output 'unsigned transaction to sign'. It distinguishes from the sibling tool 'claim_winnings' by explicitly mentioning TMB, aligning with the tool name.

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 on when to use this tool versus alternatives like claim_winnings. It does not specify prerequisites (e.g., market must be resolved) or exclusions, leaving the agent to infer usage context from the name alone.

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?

Discloses the need to sign with a wallet and supports multiple settlement modes, but with no annotations present, fails to describe destructive nature (mutates state), return values, or error conditions. The description carries the full burden and falls short.

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

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

Two sentences, no redundancy, front-loaded with the core action. Every word serves a purpose.

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?

Captures key aspects (settled market, signing needed, settlement modes) but omits expected output, error handling, and prerequisites (e.g., wallet must have winnings). Adequate but with gaps for a mutation tool without output schema.

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

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

Schema covers all three parameters with descriptions, but the tool description adds value by clarifying the signing requirement and settlement modes, which hints at how parameters are used. 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?

Clearly states the action 'Claim winnings' and the resource 'settled market'. Mentions three specific settlement modes, distinguishing it from sibling tools like claim_tmb_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?

Indicates the tool is for claiming winnings from settled markets and requires wallet signing. However, lacks explicit guidance on when to use this over alternatives like claim_tmb_winnings or withdraw_bet, and does not mention prerequisites.

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 side effects: queues for resolver review and triggers async refund of acceptance bond via MPP. Also implies prerequisite (pin_evidence call). Missing details on permissions or error handling, but 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?

Two concise sentences with front-loaded action and no wasted words. Every sentence carries essential information.

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

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

Given 5 parameters and no output schema or annotations, the description covers purpose, prerequisites, side effects, and parameter semantics reasonably well. Could elaborate on error scenarios, but sufficient for typical use.

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

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

Adds value beyond schema by explaining evidence_hash comes from pin_evidence and is required for TMB on-chain jobs, and wallet must be assigned agent. Schema already covers other params, so extra context is helpful.

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' and the resource 'job'. It distinguishes itself from sibling tools like create_tmb_job or accept_tmb_job by specifying the completion step with deliverables and IPFS evidence.

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 context: for TMB on-chain jobs, evidence_hash is required and pin_evidence should be called first. Mentions queuing and async refund. However, does not explicitly state when not to use the tool or compare to alternatives.

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

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

No annotations provided; description mentions finalizing the launch, implying a write/state change. Does not discuss idempotency, error states, or confirmation of success, which would be helpful for a finalization step.

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 redundant information. Front-loaded with purpose and required input. 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?

No output schema; description does not explain what the tool returns (e.g., confirmation status, transaction ID). For a finalization step, knowing the response would help the agent verify success. Adequate but incomplete.

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

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

Schema coverage is 100%, and the description adds meaning: signature comes from `launch_token` transaction, creator_wallet is the signer. This clarifies parameter origins 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 confirms a token launch after signing, using 'confirm' and 'finalize'. It distinguishes from sibling `launch_token` by indicating it's a subsequent step.

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?

Implies usage after `launch_token` by referencing 'after signing the transaction from launch_token'. No explicit when-not or alternatives, but context is clear for a sequential workflow.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool creates a battle and maps the suggestion to create_permissionless_market, including data feed types. However, it lacks details on side effects, authorization requirements beyond authToken, and what the return value is (e.g., battle ID). This is adequate but not comprehensive.

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

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

The description is only two sentences, front-loaded with the core purpose, and includes necessary usage guidance without redundancy. Every sentence contributes meaning, earning the highest score.

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 a nested object parameter and no output schema, the description adequately explains the mapping and alternatives but does not specify expected outcomes or error handling. It assumes familiarity with get_battle_suggestions and create_permissionless_market, which may leave agents without complete context. A score of 3 reflects this gap.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that 'suggestion' comes from get_battle_suggestions and that 'durationMinutes' is an override, but these are already implied or stated in the schema descriptions. The addition is marginal, so a score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: creating a structured data-driven battle from a suggestion returned by get_battle_suggestions. It specifies the resource (suggestion) and action (create), and distinguishes itself from create_tmb_battle for freeform claims, which helps differentiate among siblings.

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

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

The description provides explicit guidance: use this tool when you have a suggestion from get_battle_suggestions, and for freeform claims, use create_tmb_battle directly. This clearly indicates when to use this tool versus alternatives, meeting the highest standard.

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

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

With no annotations provided, the description carries full burden. It mentions on-chain resolution and 0.5 SOL seed, but fails to disclose important behaviors such as whether the creator needs sufficient SOL, whether the battle is immediately active, or what happens on failure. Lacks depth 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?

Three sentences densely pack all key information: purpose, battle type categories, duration rules, resolution mechanism, and cost. No redundancy, front-loaded.

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

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

Covers battle types, duration, and cost, but omits return value (e.g., battle ID or confirmation), error handling, or validation criteria. Adequate but leaves gaps for a complex creation tool with no output schema.

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

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

Schema coverage is 100%, but the description adds value by clarifying which 'durationMinutes' applies to which battle types, and notes the 0.5 SOL seed cost not present in schema. Effectively supplements parameter understanding.

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

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

The description clearly states it creates a structured epoch battle and enumerates 7 battle types across 3 categories. However, it does not differentiate from sibling tools like 'create_validator_battle' or 'create_battle_from_suggestion', so the purpose is clear but not distinguished.

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 explains battle type categories and duration rules (epoch-boundary vs user-set), and mentions platform resolution and cost. However, it provides no guidance on when to use this tool versus other battle creation tools, nor any exclusions or prerequisites.

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 full burden. It discloses key behaviors: creates a market, resolves via on-chain data, requires seed cost, and has a duration. However, it omits details about reversibility, permission requirements, or what happens if the proposal is invalid. Adequate but not thorough.

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-loading the core purpose and key constraints. No redundant information; every part earns its place.

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

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

For a tool with 6 parameters and no output schema, the description covers the purpose, cost, and duration but misses details about optional parameters like proposalId and the auto-resolved authToken. The overall picture is clear but not 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%, so the schema already describes all parameters. The tool description adds no additional semantic value beyond the schema (e.g., does not explain the relationship between bettingDurationSeconds and eventDurationSeconds). 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 clearly states the tool's purpose: creating a governance proposal outcome market. It specifies the resolution method (on-chain governance data), cost (0.5 SOL seed), and duration (15-120 min). This distinguishes it from other battle-creation siblings like create_epoch_battle or create_network_battle.

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

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

The description implies usage for governance proposals but does not explicitly mention when to use this tool over alternatives like create_epoch_battle or create_permissionless_market. No when-not or alternative names are provided.

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

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

With no annotations, the description fully discloses the two-phase flow: Phase 1 stores an intent (returns intentId, persists 30d) and Phase 2 graduates to an on-chain TMB job. It explains the escrow, resolver, and dispute window, though it could mention if the operation is reversible.

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

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

The description is about 120 words, well-structured in three sentences: purpose, flow with phasing, and prerequisite. No redundant information; every sentence 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?

Given no output schema and no annotations, the description covers all essential aspects: purpose, lifecycle, parameter details, and prerequisites. It mentions the return of intentId, which is sufficient without an output schema.

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

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

The description adds significant context beyond the schema: e.g., 'agentId' specifies source, 'service' explains each enum value, 'budgetUsdc' explains leave unset for pre-quote, and 'buyerWallet' clarifies it binds the intent. This enriches 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 clearly states the tool logs an intent to hire an external ERC-8004 agent via TrenchFu's TMB-escrow flow. It differentiates from sibling tools like 'accept_external_hire' and 'create_tmb_job' by detailing the two-phase process and prerequisites.

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: call get_external_agent first to confirm the agent's endpoints. It does not explicitly state when not to use the tool, but the context of sibling tools and the clear purpose implies appropriate usage.

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

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

No annotations are provided, so the description bears full responsibility. It discloses commission (10%), auto-approval rules, and the requirement for an agent profile. It also mentions delivery methods and provisioning drivers, which are behavioral aspects. However, it does not mention potential side effects, rate limits, or idempotency.

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: 4 sentences covering purpose, commission, approval, and requirement. No redundant information, and the most critical details are front-loaded.

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

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

Given the tool's complexity (13 parameters, 5 required, enums, nested objects) and no output schema, the description covers the main purpose, commission, approval, and prerequisites. It lacks details about the return value (e.g., listing ID) but is reasonably complete for a creation tool.

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

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

Schema description coverage is 100%, setting baseline at 3. The description adds context such as the commission affecting price_usdc and the dependency of provisioning_template on provisioning_driver. However, it does not explain enum choices or parameter interactions beyond what schema 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 the tool's purpose: 'List a product or service on the marketplace'. It lists the types of items (endpoints, bundles, tools, datasets) and distinguishes it from sibling tools like browse_listings, purchase_listing, and delist_listing by being the creation tool.

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

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

The description specifies prerequisites: 'Requires agent profile (8004)' and conditions: '8004-registered agents are auto-approved; others go through review'. It provides enough context for when to use, but does not explicitly compare with alternatives or state 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?

With no annotations, the description effectively conveys key behavioral traits: automatic resolution via live data, a 0.5 SOL seed cost, and a fixed duration window (5-15 minutes). This adds significant context beyond a generic 'create' description, though it could explicitly state that it deducts SOL and creates an on-chain market.

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

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

The description is extremely concise: three sentences covering purpose, resolution method, and cost/duration. No wasted words; the key information is front-loaded in the first 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?

Given no output schema and moderate complexity, the description explains what the tool does and its cost/timeline, but omits what the agent should expect after creation (e.g., a market ID or confirmation). It also lacks prerequisite information such as wallet balance requirements or auth token handling.

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 meaning by contextualizing the parameters: listing the specific metrics (TPS, success rate, etc.), providing a typical duration range, and indicating the seed cost. This goes beyond the schema's generic 'Network metric' or 'Duration in minutes' descriptions.

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

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

The description clearly states the action: 'Create a structured over/under market on Solana network metrics', specifying the resource and scope. It distinguishes from sibling battle-creation tools like create_epoch_battle or create_governance_battle by explicitly mentioning 'over/under' and 'Solana network metrics'.

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 does not provide explicit guidance on when to use this tool versus alternatives. There are no 'when to use' or 'when not to use' statements. The usage is implied: create a market on Solana network metrics, but no exclusion criteria or sibling comparisons 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?

No annotations provided, so description carries full burden. It discloses seed cost, creator fee tiers, automated data resolution, and caps on creatorShareBp with error handling. Missing description of return value but overall highly 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 sentences effectively cover purpose, usage guidance, and key parameters without wasted words, front-loaded with primary action.

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

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

Covers most aspects: purpose, alternative tool, cost, fee tiers, parameter constraints. Lacks description of return value, but given no output schema, this is a minor gap for a creation tool.

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

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

Schema coverage is 100%. Description adds critical context for creatorShareBp (caps based on tier, error behavior) and lists fee ranges, enhancing understanding 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 it creates a structured prediction market comparing two competitors on a specific metric, and distinguishes from the sibling tool create_tmb_battle for freeform 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?

Explicitly tells when to use this tool vs create_tmb_battle, including differences in seed SOL and resolution method, providing clear guidance for 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?

The description discloses key behavioral traits: the creator is the sole resolver, modeId imposes constraints, evidence can be attached, and transaction may be rejected if constraints are not met. Since no annotations are provided, the description carries the full burden and does so well, though it omits explicit mention of gas costs or success response.

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 paragraph of moderate length, conveying essential information without wordiness. It could be slightly more structured (e.g., bullet points for key points), but it is clear 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 high parameter count (13) and no output schema, the description covers behavioral aspects, prerequisites, and sibling differentiation. It explains what happens on failure (transaction rejected) but not the success response. This is a minor gap, but overall the description 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%, but the description adds extra context beyond schema: e.g., 'seed must satisfy the chosen mode', 'creatorShareBp capped by creator tier', and 'both sides always > 0' for seedSplitPercent. This additional information helps the agent understand constraints and defaults more deeply.

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 claim-based prediction market ('Trust Me Bro') and specifies the core actions: write claim, set outcomes, fund seed. It also distinguishes from the sibling tool 'create_permissionless_market' by noting it is for structured data-driven markets.

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

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

The description provides explicit guidance: when to use (claim-based markets), prerequisites (browse_tmb_modes first to pick a modeId), and alternatives (use create_permissionless_market for structured data). It also notes that the user becomes the resolver and can attach evidence via pin_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 full burden. It mentions escrow in PDA, platform resolver fraud prevention, and dispute window, but lacks details on destructive nature, permissions required, side effects, or error handling. The description does not contradict any annotations (none present).

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 main action, and contains no redundant words. It is efficient but could benefit from a more structured format (e.g., bullet points) for clarity.

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

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

With 10 parameters and no output schema, the description does not explain return values, confirmation methods, or error scenarios. The dispute window mention adds some workflow context, but overall incomplete for a complex creation tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context for evidence_hash (linking to pin_evidence) and mentions budget escrowed, but does not add meaningful semantics for other parameters beyond what is in 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 explicitly states 'Create an on-chain TMB job contract' with a specific verb and resource. It mentions mode #2 and escrow, making the purpose clear. However, it does not explicitly differentiate from sibling tools like post_job or create_tmb_battle.

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

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

The description provides a prerequisite ('Requires evidence_hash, use pin_evidence first') but offers no guidance on when to use this tool versus alternatives like bid_on_job or accept_tmb_job. No explicit when/when-not or exclusion criteria.

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 convey all behavioral traits. It discloses the platform resolution via on-chain data and the 0.5 SOL seed cost. However, it does not mention rate limits, authentication requirements beyond the authToken parameter, side effects (e.g., SOL deduction), or what happens after creation (e.g., auto-claim). This leaves gaps in transparency.

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

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

The description is concise, with two sentences that front-load the core purpose and metric options. It efficiently adds cost and duration. However, a slight structure improvement could separate the metric options from cost/duration for faster scanning.

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 purpose, comparison items, resolution, cost, and duration. It is missing the return value (e.g., battle ID or transaction hash) and does not address prerequisites or error scenarios. The discrepancy between schema (duration 5-120) and description (15-120) reduces completeness.

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

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

Schema description coverage is 100%, so the schema already documents all parameters adequately. The tool description adds value by explaining the metric options and duration range, but repeats information already in the schema. It does not compensate for parameters like authToken or creatorWallet, which remain as documented in 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 creates a validator vs validator battle for comparing specific metrics. It mentions on-chain resolution, cost, and duration. However, it does not differentiate from sibling battle creation tools like create_epoch_battle or create_network_battle, which could confuse an AI agent as to which to use.

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

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

The description provides context on when to use (comparing validators) and specific parameters like metric and duration. However, it lacks guidance on when not to use this tool, prerequisites (e.g., wallet, SOL balance), or alternatives among the 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. The description mentions the removal action and seller constraint but doesn't discuss side effects (e.g., irreversibility, impact on buyers). For a simple tool, this is adequate but could be more 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 sentences, both directly useful. No filler or repetition. 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?

Given no output schema and a simple deletion action, the description covers the essential aspects: what it does, who can use it, and key parameter 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?

All 2 parameters have schema descriptions (100% coverage). The description adds ownership context ('must match listing seller') beyond the schema, providing meaningful guidance.

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 ('Remove your listing') and who can perform it ('Only the seller'), making it distinct from tools like create_listing or 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 condition 'Only the seller can delist their own listing' provides clear context for when to use the tool. It doesn't explicitly mention alternatives, but the condition is sufficient given the sibling set.

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 bears full burden. It discloses that execution records a job receipt and tracks status, and requires a registered agent profile. However, it omits side effects, failure modes, permissions, or idempotency, which are important for a mutation tool.

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

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

The description is extremely concise, consisting of two front-loaded sentences. Every sentence adds value: first states core function, second adds relevant context about receipts and prerequisites.

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, the description could better complete the picture by hinting at return values (e.g., job ID) or error conditions. It covers the basics but leaves gaps for a tool that executes actions and tracks status.

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 all three parameters with descriptions (100% coverage), so the description adds no new semantic value beyond the schema. The mention of 'requires a registered agent profile' is a prerequisite, not a parameter detail.

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 action ('Route execution to a registered service operator') and resource, distinguishing it from siblings like job creation or bidding tools. It adds context about recording a job receipt and requiring a registered agent profile, leaving no ambiguity.

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

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

The description implies usage when you need to execute a service through a registered operator, but it does not explicitly state when not to use it or mention alternative tools. The prerequisite of a registered agent profile provides some condition, but lacks comparative guidance.

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

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

With no annotations, the description bears the burden. It assures the wallet continues to work normally, addressing non-destructive behavior. However, it lacks warnings about the sensitivity of exporting private keys, which 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?

Two sentences, zero wasted words. Front-loaded with the core action and clearly 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?

The description explains the tool's effect and that it's non-destructive. However, it does not describe the return format (the private key string) which is needed since there is no output schema. Missing some context for a sensitive 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?

Schema coverage is 100% and the parameter 'agentId' is described. The description does not add additional meaning beyond the schema, such as format or how to obtain 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 exports a private key for wallet migration to specific wallets. It uses a specific verb 'Get' and distinguishes from sibling tools like wallet_status or provision_wallet.

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

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

The description implies usage for exporting to other wallets but does not explicitly state when to use vs alternatives or when not to use (e.g., security warnings). No clear usage guidance beyond the basic purpose.

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?

Discloses key behaviors: returns active season data with specific fields, and returns upcoming season if none active. No contradictions or hidden side effects.

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

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

Two concise sentences with all key facts front-loaded. 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?

Fully covers tool behavior given zero complexity (no params, no output schema). Includes edge case (fallback to upcoming season).

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

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

No parameters exist (schema empty), so baseline 4 is appropriate. Description adds no param info but none 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?

Clearly states it gets the active competitive season and lists specific data fields (name, reward pool, time remaining, etc.). Distinguishes from sibling tools like get_my_season_rank and get_season_leaderboard by focusing on overall season details.

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

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

Description implicitly defines usage context but lacks explicit guidance on when to use over alternatives. No when-not scenarios or alternative tool names mentioned.

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

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

With no annotations, the description carries full burden. It discloses that the tool is 'Premium — per-call from wallet balance,' indicating a cost per use, which is a critical behavioral trait. However, it does not mention whether the tool is read-only or any other side effects.

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

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

The description is two sentences, each delivering essential information: purpose and return fields plus cost model. No wasted words; front-loaded with the core action.

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

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

Given the simplicity (2 parameters, no output schema, no annotations), the description covers the basics: purpose, return fields, and cost. However, it lacks details on output format, result limits, or data freshness, which could be useful. It is adequate but not fully comprehensive.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for parameters; the schema already describes category and min_edge. The return fields mentioned in the description are 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?

The description clearly states the tool's purpose: 'Get current arbitrage opportunities across prediction markets.' It specifies the verb 'Get' and the resource 'arbitrage opportunities,' and distinguishes itself by focusing on arbitrage rather than general market predictions or flash 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 guidance is provided on when to use this tool versus siblings like 'get_flash_opportunities' or 'get_market_predictions.' The description lacks any 'when-to-use' or 'when-not-to-use' context.

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

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

Without annotations, the description carries full burden. It discloses that the tool returns curated data with pre-filled parameters and lists the output structure (title, reasoning, competitors, etc.). It does not mention side effects or rate limits, but the read-only nature is implied. The description adds value by describing what the user gets.

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 long, front-loaded with the core function, and includes relevant details without unnecessary words. Every sentence 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?

Given the tool's simplicity (two optional parameters, no required fields, no output schema), the description adequately covers what it returns and how to use it. It also ties to the broader workflow of creating permissionless markets, making it contextually 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%, so the schema already describes both parameters (limit and category) with their types and defaults. The description does not add new details beyond repeating the category options and default. 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 that the tool retrieves curated battle suggestions, explicitly listing the types of battles (DEX token matchups, validator battles, etc.) and specifies that it shows the same data as the Solana Arena page. This distinguishes it from sibling tools like create_battle_from_suggestion, which are for creating battles.

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 says 'Use this to find opportunities for creating permissionless markets,' providing clear context for when to use the tool. However, it does not explicitly exclude use cases or mention alternative tools, such as those for creating specific battle types, which would strengthen guidance.

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

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

No annotations are provided, so the description carries the full burden. It states the tool returns analysis data but does not disclose any behavioral traits such as data freshness, caching, external calls, or whether it is read-only. For a read-only tool, this is adequate but could be improved.

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, concise sentence (20 words) that front-loads the purpose. Every word adds value, with 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?

Given zero parameters and no output schema, the description is sufficient. It fully explains what the tool does (chokepoint analysis) and what it returns (specific data types and locations). No missing critical 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?

The input schema has no parameters (schema coverage 100%), so the description need not add parameter details. The baseline is 4, and the description exceeds it by clearly specifying the kind of analysis returned.

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 provides 'maritime and aviation chokepoint analysis' with specific examples of data (congestion scores, military presence, traffic anomalies) and locations (Suez, Hormuz, Malacca, Taiwan Strait). It distinguishes itself from siblings like 'get_defense_intel' by focusing on chokepoints.

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

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

The description implies usage for chokepoint analysis but does not provide explicit guidance on when to use this tool versus alternatives like 'get_defense_intel' or 'get_weather_intel'. No exclusions or prerequisites are mentioned.

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

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

Since no annotations are provided, the description carries full weight for behavioral disclosure. It adds the update frequency (every 30 seconds) but does not disclose caching behavior, data availability guarantees, or error handling. It is minimally 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?

Two sentences, front-loaded with key information, no redundant words. Perfectly concise for the tool's simplicity.

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, the description should clarify the return format. It mentions 'aggregated intelligence scores across all 16 domains' but does not specify whether it returns a single number or multiple values, nor does it describe the data type or units. This leaves ambiguity for an agent needing to interpret the result.

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 is empty (0 parameters). Per rubric, baseline is 4. The description does not need to add parameter details, and it correctly implies no inputs are required.

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

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

The description clearly states the tool's purpose: it provides aggregated CII scores across 16 domains, and explains the meaning of higher scores. It distinguishes itself from sibling tools by naming a unique resource (Compound Intelligence Index) and specifying its update frequency.

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 offers no guidance on when to use this tool versus alternatives like get_chokepoint_intel or get_narrative_intel. It does not mention prerequisites, use cases, or conditions for 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?

No annotations, but description adds behavioral context: read-only check, returns list with payout amounts. Could explicitly state no side effects.

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

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

Two sentences, front-loaded with purpose, no unnecessary 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?

Simple tool with one parameter and clear purpose; description fully covers what to expect without 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?

Only one parameter with schema coverage 100%; description adds minimal value beyond 'your wallet address' already in 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?

Description uses specific verb 'check' and resource 'claimable bets', clarifies they are won bets on settled markets, and distinguishes from sibling tools like 'claim_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?

Clearly implies usage after settling markets and winning bets, but does not explicitly state when not to use or mention alternatives.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only mentions auth token requirement but does not disclose other traits like rate limits, side effects, or data freshness. The description assumes a read operation but doesn't confirm idempotency or cost.

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 key output fields. No superfluous words. Efficiently communicates purpose and authentication requirement.

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 no output schema, so the description compensates by listing return values (total fees, tier, share, per-market breakdown). However, it omits details like time range, pagination, or any limitations, which could be useful for an analysis 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?

Input schema covers both parameters with descriptions (100% coverage). The description adds minor context: wallet is the creator's address and authToken is from provision_wallet or refresh_token. This adds value but does not significantly expand beyond 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 name and description clearly state the tool returns creator earnings, including total fees, tier, share percentage, and per-market breakdown. It distinguishes itself from sibling tools which cover different data like battle suggestions, job details, or market 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 mentions requiring an auth token and ties it to create_permissionless_market, giving context on authentication. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it specify prerequisites or exclusions.

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

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

No annotations provided, and the description only states what the tool does ('get'). It does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, side effects, or response size. The description carries the full burden but provides minimal insight.

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 main action and examples.

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 parameters, no output schema, and no annotations, the description is adequate for a simple retrieval tool. It explains the purpose and scope (16 domains) but does not cover potential use conditions or response format.

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

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

The schema has 0 parameters, so schema description coverage is 100% trivially. Baseline is 3. The description does not add any parameter information since none exist.

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

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

The description clearly states it retrieves cross-domain correlation signals with concrete examples (weather→energy, maritime→oil). It distinguishes from sibling tools which are mostly about jobs, battles, or markets, none related to intelligence correlations.

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. Sibling tools do not overlap in domain, so implied usage for intelligence gathering, but no when-not-to-use or alternative recommendations.

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 that the tool returns structured intel with timestamps and source attribution, implying a read-only, safe operation. It could mention if authentication is needed, but overall 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, front-loaded with the tool's purpose, and contains no redundant information. Every sentence 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?

Given the simple one-parameter schema and no output schema, the description is mostly complete: it explains categories and output format. It could mention if data is real-time or historical, but overall 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%, but the description adds meaning by explaining what each category value represents (e.g., 'acars' for ACARS military traffic, 'defense' for conflict zone data). This goes beyond the schema's brief parameter description.

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

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

The description clearly states it provides defense and military intelligence, listing specific data types (ACARS military traffic, exercises, conflict zone data). It distinguishes from sibling tools like get_chokepoint_intel and get_force_posture by specifying its 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?

It explains when to use this tool (for defense/military intelligence) and how to use categories. It does not explicitly exclude alternatives among siblings, but the context implies specific intel types belong to this 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?

No annotations are provided, so the description carries the full burden. It describes the output but does not disclose behavioral traits such as authentication requirements, rate limits, or any side effects. For a read-only getter, this is adequate but 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, front-loaded sentence that efficiently conveys the tool's purpose. No redundant words or phrases; 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 tool with no parameters and no output schema, the description provides sufficient context by listing the specific stats returned. However, more detail on data format or response structure 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 0 parameters, and schema coverage is 100% (empty schema). Per guidelines, with high schema coverage, baseline is 3. The description adds no parameter info, which is acceptable since there are no parameters.

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

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

The description uses a specific verb ('Get') and resource ('DFlow prediction market stats'), listing exactly which stats are returned (TVL, 24h volume, open interest, active markets count). This clearly distinguishes it from similar sibling tools like get_kalshi_markets or get_market_pools.

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

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

The description implies usage when DFlow prediction market stats are needed, but it does not state when not to use this tool or provide explicit alternatives. Siblings exist for other market data, but no comparison is 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?

No annotations are provided, and the description only states it returns signal-processed data. It does not disclose read-only nature, potential errors, or any side effects, leaving behavioral traits unclear.

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

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

Two sentences, front-loaded with purpose, followed by a clear list of categories and output. Every sentence serves a purpose with no extraneous information.

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

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

Given the single parameter and no output schema, the description covers the input well but lacks specifics about the return format or error handling. It is adequate but not fully complete.

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

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

Schema coverage is 100% with a single 'category' parameter described as 'Enrichment category name'. The description adds value by enumerating valid category values, which is helpful beyond the schema's minimal description.

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

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

The description clearly states it provides per-category enrichment intelligence and lists valid categories. However, it does not differentiate from specialized sibling tools like get_weather_intel or get_defense_intel, which may cause confusion.

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. The description lists categories but does not indicate conditions or exclusions, leaving the agent without context.

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

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

With no annotations, the description carries full burden. It discloses that the tool fetches both on-chain record and resolved IPFS metadata, includes reputation data, and provides an explorer link. It also states that reputation is not indexed locally. This is good transparency, though it could explicitly state read-only behavior.

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

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

Two sentences covering purpose, returned data, and context. No unnecessary words. Front-loaded with the main action and result. Highly 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 single-parameter fetch tool with no output schema, the description is fairly complete. It explains what is returned and provides relevant marketplace context. However, it omits potential error conditions or authentication needs, but this is acceptable given 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%, so baseline is 3. The description does not add new meaning beyond the schema; the parameter 'id' is described identically as 'Agent asset address (base58 Solana pubkey)' in both.

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 fetches full detail for an external ERC-8004 agent, listing specific data (on-chain record, IPFS metadata, reputation, explorer link). This differentiates it from siblings like list_external_agents (list) and search_external_agents (search).

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 context that this is for a separate marketplace (8004) and that TrenchFu reads it for discovery without local indexing. It implicitly clarifies when to use this tool (for detailed view) vs list/search, but does not explicitly name alternatives or give when-not-to-use guidance.

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

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

No annotations are provided, so the description must convey behavioral traits. It only states what data is retrieved (time-sensitive opportunities) but omits side effects, authorization needs, rate limits, or output format. For a read-like tool, minimal behavioral disclosure.

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

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

Extremely concise: two sentences. The key verb and resource are front-loaded. No filler words; every sentence 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?

No output schema is provided, yet the description does not explain the return structure (fields like expiry time, opportunity type). For a discovery-oriented tool, this lack of completeness could hinder agent decisions. More detail on response format would improve usability.

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

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

Schema coverage is 100%, with clear parameter descriptions (type filter, limit). The tool description adds no additional parameter semantics beyond the schema, but also doesn't require it. 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 retrieves time-sensitive opportunities, with specific examples (markets about to expire, validator flash candidates, governance votes closing soon). This distinguishes it from sibling tools like get_market_pools or get_governance_proposals which may lack the time-sensitivity focus.

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

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

The description explicitly recommends use cases: 'Great for creating short-duration TMB or permissionless markets.' While it doesn't provide when-not-to-use or alternative tools, the context is clear enough for an agent to decide appropriately.

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 provide transparency. It discloses the scoring formula and that it tracks buildup/drawdown, indicating it returns time-series data. However, it does not mention data freshness, source, or whether it's read-only (likely). Some behavioral traits are implied but 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?

Two concise sentences that convey the essential function without extraneous detail. The first sentence states the purpose, and the second adds the scoring method. Slightly improved by front-loading the output format, but still 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 (no parameters, no output schema), the description is fairly complete. However, it does not specify the exact output structure (e.g., list of regions with scores), nor does it clarify if it returns historical data or current snapshot. Lacks enough detail for full autonomous use without guessing.

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 description does not need to add parameter details. The baseline for this case is 4. The description explains that the tool returns regional data, which is sufficient given no input choices required.

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

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

The description clearly states it provides regional military force composition with a scoring formula. It distinguishes itself from sibling intel tools by specifying the particular focus on combined air+naval presence per region. However, it lacks clarity on whether it returns data for a specific region or all regions, given zero parameters.

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 on when to use this tool versus other intel tools such as get_defense_intel or get_formation_intel. The description does not mention alternatives or context of use, leaving the agent to infer applicability.

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 bears full burden. It only hints at read behavior (detection via analysis) but does not explicitly state it is read-only, mention data freshness, rate limits, or what happens if no formations are found.

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

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

Single sentence, no filler. Front-loaded with the core function. Every word is meaningful and concise.

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

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

For a zero-parameter tool, the description provides adequate domain context (military formation detection via ADS-B/AIS). However, it lacks any mention of output format or sample results, leaving the agent uncertain about what the response looks like.

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

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

With zero parameters and 100% schema coverage, no parameter documentation is needed. The description adds value by explaining the tool's domain and data sources beyond the empty 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 detects military formations, specifically coordinated air/naval movements, deployment patterns, and force posture changes. It differentiates from sibling intel tools like get_force_posture or get_defense_intel by specifying ADS-B and AIS analysis as input sources.

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 like get_chokepoint_intel or get_force_posture. The description does not mention prerequisites, limitations, or context.

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

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

With no annotations provided, the description bears full burden. It indicates a read operation and mentions coverage scope, but does not disclose pagination behavior, data freshness, or any constraints beyond what is in the schema. Lacks depth for a comprehensive behavioral understanding.

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

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

The description is two sentences, front-loaded with the main purpose. The second sentence adds useful but slightly tangential context. It is efficient and not verbose.

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, the description lacks information about the return structure of a proposal. It also does not mention pagination beyond the 'limit' parameter. For a simple tool with two optional parameters, it provides the essential scope but leaves some 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 does not add any extra meaning to the parameters beyond the schema definitions, which already describe the limit and status options sufficiently.

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 active Solana DAO governance proposals, distinguishes it from sibling tools like create_governance_battle, and adds context about covering all Realms DAOs and the relevance for prediction 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 implies usage for fetching governance proposals, but does not explicitly state when to use it versus alternatives, nor does it provide guidance on when not to use it. Given the uniqueness among siblings, this is adequate but not 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 correctly implies a read-only operation ('Get') and outlines the return content. However, it does not disclose error handling (e.g., invalid job_id), permissions, or rate limits. For a simple retrieval, this is adequate but minimal.

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

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

The description is a single sentence that immediately conveys the tool's purpose and scope. It is front-loaded with the key verb and resource, and includes specific output categories. No redundant or extraneous information.

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

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

Given the simplicity of the tool (one required parameter, no output schema), the description provides sufficient context: what the tool does, what it returns, and how to call it. It could mention pagination or error conditions, but these are not critical for a straightforward detail retrieval.

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 only one parameter ('job_id'). The description does not add semantic value beyond what the schema already provides (e.g., 'full details' hints at output but not parameter usage). Baseline score of 3 applies as schema does the heavy lifting.

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

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

The description clearly states the verb 'Get' and the resource 'full details of a specific job', including what is covered ('bids, status, and settlement info'). It distinguishes this tool from its sibling 'get_jobs' (which lists jobs) by specifying 'specific job' and 'full details'.

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 you need comprehensive info on one job, but does not explicitly state when to avoid it (e.g., for listing all jobs, use 'get_jobs') or mention any prerequisites. The context is clear but lacks explicit 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?

The description does not explicitly state that the tool is read-only or non-destructive, but the name and context imply it. Lacks details on side effects, but given it's a listing, it's minimally 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 short (two sentences) and front-loaded, but the last sentence about 'Free tier' is somewhat extraneous.

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

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

No output schema, so description should explain return structure. It does not mention pagination beyond the limit parameter or what fields are in the response. Incomplete for a listing tool.

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

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

Schema coverage is 100% with descriptions, so baseline is 3. The description adds 'budget range' which is not in schema, but otherwise doesn't enhance understanding of parameters.

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

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

The description clearly states 'List open jobs on the marketplace' but inconsistently mentions filtering by 'budget range' which is not a parameter in the input schema, causing confusion.

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 on when to use this tool vs alternatives like get_job_detail or browse_listings. No mention of when not to use or prerequisites.

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 full burden. It communicates that the tool is read-only (browsing, not trading) and includes a limitation (no trading without DFlow Proof). However, it does not explicitly state it is non-destructive or that it only fetches data.

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

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

The description is three sentences, front-loaded with purpose, and every sentence adds value. No fluff 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 (3 optional params, no output schema), the description is mostly complete. It covers purpose, use case, and a limitation. However, it does not describe the output format, which an agent might need to know for downstream decisions.

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% (all three parameters have descriptions in the schema). The description adds no additional semantics about parameters, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool is for browsing Kalshi prediction markets for inspiration. It distinguishes itself from trading by explicitly noting that direct Kalshi trading is not available here, and from other market browsing tools by focusing on Kalshi markets (rather than TrenchFu's own 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: use when you want inspiration from Kalshi markets to create equivalent markets on TrenchFu. It implicitly excludes trading use cases via the NOTE, but does not explicitly name alternative tools like 'browse_markets' for TrenchFu markets.

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

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

No annotations provided, so description carries full burden. Discloses that tool retrieves current data and simulates payouts. 'Get' implies read-only. Could mention if data is real-time or cached, but adequate for a simple info 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, no fluff. First sentence states purpose and output. Second sentence provides use case and compatibility. Efficient and front-loaded.

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

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

No output schema, but description explains return data. Covers purpose, usage, and compatibility. Lacks explicit mention of read-only nature or prerequisites, but sufficient given tool 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 coverage is 100% with descriptions. Description adds value by summarizing output (pool sizes, implied odds) and tying parameters to simulation (outcome and amountSol). Confirms purpose beyond 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?

Description clearly states verb 'Get' and resource 'market pools' along with specific data (pool sizes, implied odds, simulated payout). Distinguishes from siblings like get_market_predictions and get_market_status. Also specifies compatibility with all market types.

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

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

Explicitly says 'Call before betting to understand the risk/reward', providing clear usage context and ordering relative to betting tools. Does not explicitly exclude other uses but implies primary purpose.

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

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

No annotations provided, so description carries full burden. It discloses return fields but does not mention any behavioral traits such as read-only nature, authentication needs, rate limits, or latency. Lacks depth for a tool with no annotation safety net.

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

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

Three concise sentences with clear front-loading of purpose. No redundant information, 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?

With no output schema, the description provides a summary of return fields (predicted/actual price, confidence, accuracy stats, calibration) but omits details like data types, ranges, or structure. Nearly complete for a single-parameter tool.

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

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

Schema coverage is 100%, and the description reiterates the valid assets without adding new semantic meaning beyond the schema's enum description. Baseline 3 applies as description adds minimal extra 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 clearly states the tool's function: getting 15-minute settlement predictions for crypto assets from the density engine, listing return fields and valid assets. It distinguishes from sibling get_market_signals by specifying when to use the alternative.

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 not to use (for Kalshi signals) and directs to get_market_signals. However, no guidance on other related tools like get_market_pools or general context on when to query predictions.

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

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

No annotations provided; description mentions real-time nature and output data but does not disclose any behavioral traits such as rate limits, authentication needs, or side effects. Adequate but not enriched.

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: first sentence front-loads purpose and outputs, second sentence provides usage guidance. Every sentence is essential and efficiently worded.

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 simple parameter set (2 params, no nested objects, no output schema), the description covers purpose, usage conditions, and parameter examples comprehensively. No apparent gaps for typical use.

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

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

Schema coverage is 100%, and the description adds concrete examples for the ticker parameter (e.g., KXBTC, KXBTCD) and mentions window options. Adds value beyond schema without redundancy.

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

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

Description clearly states it returns real-time signal intelligence for Kalshi/DFlow market tickers, listing specific data types. It explicitly distinguishes from sibling tool get_market_predictions by specifying when to use each.

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 this tool for Kalshi tickers and provides a clear alternative (get_market_predictions) for crypto asset predictions.

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

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

No annotations provided; description does not disclose side effects, rate limits, or authentication needs. Only lists return fields, so minimal behavioral insight beyond obvious read operation.

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

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

Single sentence, front-loaded with action, no redundant words. Highly 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?

Adequate for a simple getter with one parameter and no output schema. Lists all key return fields, but could mention error handling or validation constraints for completeness.

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

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

Schema description coverage is 100%, but schema only says 'Market ID or PDA'. Tool description adds no further meaning about parameter format, examples, or usage. 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?

Clearly states 'get detailed status of a specific market' and enumerates specific data points (pool sizes, odds, bet count, settlement status, time remaining). Distinguishes from sibling tools like 'get_market_pools' which is narrower.

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 on when to use this tool versus alternatives such as 'browse_markets' or 'get_market_pools'. Agent must infer context from the description alone.

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

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

With no annotations provided, the description bears full burden. It discloses it returns a summary with unrealized gains but omits whether it is read-only, authentication requirements, or any side effects. More behavioral context is needed.

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 long, front-loaded with the purpose, and contains no unnecessary words. It is efficiently structured.

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

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

Given no output schema, the description minimally describes the return ('portfolio summary with unrealized gains') but lacks details on pagination or specific fields. It is adequate for a simple tool but not 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%, and the parameter description in the schema is clear. The tool description does not add extra meaning beyond what the schema provides, meriting a baseline score of 3.

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

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

The description clearly states it retrieves the user's open positions, bets, and P&L across markets, distinguishing it from general portfolio tools. However, it could be more specific about how it differs from 'get_portfolio_detail'.

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, such as 'get_portfolio_detail' or other get tools. Usage is only 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?

With no annotations, the description must fully disclose behavioral traits. It mentions return of purchase records and active leases but does not specify read-only nature, auth requirements, or potential side effects. Minimal behavioral context is provided.

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, efficient and to the point. No superfluous 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?

The description explains return values ('purchase records and active leases') and mentions included details. However, it does not elaborate on the behavior of 'include_leases' parameter or output structure. Given no output schema, it is mostly complete.

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

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

Schema coverage is 100% with descriptions for both 'wallet' and 'include_leases'. The description adds context about what the tool returns but does not enhance parameter meaning beyond schema. 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 verb 'Get', the resource 'purchase history', and specifies what is included (listings bought, provisioning status, lease details). It distinguishes itself from sibling tools like 'get_my_positions' or 'get_job_detail' by focusing on purchases.

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 on when to use this tool versus alternatives, nor are there exclusions or prerequisites mentioned. The description lacks context for appropriate usage 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?

No annotations provided, so description carries full burden. The word 'get' implies read-only, but the description does not explicitly state that the tool does not modify state, lacks rate limits, or specifies behavior on invalid inputs. Adds minimal transparency beyond the implied read operation.

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 tightly focused sentences: first defines purpose and output fields, second provides prerequisite instruction. No redundant information, efficiently front-loaded.

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

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

Given 2 simple parameters, full schema coverage, and no output schema, the description adequately lists expected return fields. It could add error handling or edge cases, but for a straightforward retrieval tool it 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 covers 100% of parameter descriptions. The description adds value by linking to get_active_season as a prerequisite, guiding the agent on how to obtain the seasonId. This extra context surpasses the baseline of 3 for full 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?

Description clearly states the verb ('get'), resource ('your rank and stats'), and provides a detailed list of returned stats (points, XP, bets, wins, losses, etc.). It distinguishes itself from sibling tools like get_season_leaderboard (global) and get_active_season (season ID retrieval) by emphasizing personal season 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?

Explicitly instructs to use get_active_season first to obtain the season ID, which provides clear context for usage. Does not explicitly mention when not to use this tool or list alternatives, but the prerequisite instruction is sufficient for this simple retrieval 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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It does not mention any side effects, read-only nature, required permissions, or performance considerations. The description is purely functional.

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-loading the main purpose and providing a concise summary. It is efficient but could be slightly more structured with bullet points.

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, the description does not explain what the output contains or how to interpret it. It covers the purpose adequately but lacks details about the return format or post-usage expectations.

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?

There are zero parameters in the input schema, so schema coverage is 100%. The description does not need to add parameter explanations. The absence of parameters is clear.

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

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

The description clearly states the tool's purpose with specific components (priming signals, causal chain detection, narrative matching) and explains it shows event propagation. However, it does not explicitly distinguish this from sibling intel tools like get_chokepoint_intel or get_formation_intel.

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

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

The description provides no guidance on when to use this tool versus alternative intel tools or other tools. There is no context about prerequisites, limitations, or typical 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?

No annotations are provided, so the description carries the full burden. It discloses the returned information (arenas, SDK endpoints, etc.) but does not mention any behavioral traits like authentication needs, rate limits, or side effects. For a 0-parameter read tool, this is minimally 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 a single sentence that immediately states the action and lists key outputs, with no wasted words. It is 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 tool with no parameters and no output schema, the description provides a reasonable overview of what is returned (arenas, SDK endpoints, market creation URLs, documentation). It could be more detailed about the structure or format, but given the low complexity, it 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?

With zero parameters, the schema coverage is trivially 100%, giving a baseline of 4. The description adds meaning by listing the types of data returned, which is helpful beyond the empty schema.

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

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

The description clearly states the tool retrieves TrenchFu platform info including specific items like arenas, SDK endpoints, and market creation URLs. It uses a strong verb 'Get' and distinguishes itself as a starting point ('Start here'), setting it apart from sibling tools that are more specific.

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 as an initial step with 'Start here,' but does not explicitly state when to use it or when to avoid it, nor does it mention alternatives among the many sibling get_* 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, yet the description fails to disclose behavioral traits such as authentication needs, rate limits, latency, or side effects. It only lists the types of positions returned.

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 with two sentences, front-loading the purpose. However, it could benefit from a more structured format (e.g., bullet points) for clarity.

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

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

Given the lack of output schema and annotations, the description adequately covers the tool's purpose and content but lacks behavioral context, leaving it partially incomplete.

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 a baseline of 3 is appropriate. The description does not add additional meaning to the parameters 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 the verb 'Get' and the resource 'full portfolio with individual positions', and explicitly differentiates from the sibling tool 'get_my_positions' which returns summary only.

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

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

The description provides guidance by noting that this tool is more detailed than 'get_my_positions', but does not elaborate on other alternatives or specific conditions for 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?

With no annotations, the description carries the full burden. It mentions 'real-time on-chain price feeds', indicating freshness and source, but does not disclose potential rate limits, update frequency, or whether multiple symbols are batched.

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

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

The description is a single, efficient sentence that immediately conveys the tool's purpose without 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?

The tool has no output schema, so the description should explain return values. It only states prices are fetched, but does not describe the format (e.g., price, confidence, timestamp) or error handling, leaving the agent with incomplete 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 coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema provides for the 'symbols' parameter.

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

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

The description clearly states the action 'Get' and the resource 'current Pyth oracle prices' with specific examples (SOL, BTC, ETH). It distinguishes itself from sibling tools, none of which appear to fetch oracle prices.

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

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

The description implies usage for obtaining current Pyth prices. While no explicit when-to-use or when-not-to is given, the context is clear, and there are no alternative price-fetching tools among siblings to cause confusion.

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 full burden. It says 'get or generate', hinting at possible mutation but doesn't specify if it's idempotent or what side effects occur. Agent cannot infer safety or idempotency.

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 key information, no redundancy. 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 1-parameter tool with no output schema, the description covers core purpose and context. Lacks details on output format but sufficient for straightforward use.

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

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

Schema coverage is 100% and description adds no extra meaning beyond the schema's 'Your wallet address'. Baseline 3.

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

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

The description clearly states the tool obtains a referral code and explains its purpose (earning trading fees). It distinguishes from sibling 'apply_referral' 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 usage (share code to earn fees) but lacks explicit guidance on when to use it versus alternatives like 'apply_referral'. No exclusion criteria or prerequisites mentioned.

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

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

No annotations are provided, so the description carries the full burden. It lists what is returned but does not disclose any behavioral traits such as permissions requirements, rate limits, or side effects. It adequately indicates a read operation.

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 sentence with a clear list of included statistics. It is concise and front-loaded, with no 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?

The tool has one parameter with full schema coverage and no output schema. The description lists what the tool returns but does not detail the output structure (e.g., nested referral tree). For a simple tool, it is adequate but not fully comprehensive.

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

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

Schema description covers the single parameter 'wallet' with 'Your wallet address.' The tool description adds no further meaning about the parameter format, validation, or usage beyond what the schema already provides. Baseline is 3 due to high schema coverage.

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

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

The description clearly states the verb 'Get' and specifies the exact resources: 'referral statistics — earnings, referral tree, number of referrals, total volume from referrals.' This is specific and distinguishes it from sibling tools like 'get_referral_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 implies usage for retrieving referral stats but provides no explicit guidance on when to use this tool vs alternatives (e.g., 'get_referral_code'), nor does it exclude any contexts.

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 exist, so the description carries full burden. It discloses tier-gated access (whale holders get extra data), which is a behavioral trait. It does not mention side effects but is clearly read-only. Adds value beyond 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?

Two sentences, no fluff. First sentence sets clear action and resource. Second adds valuable detail about contents and tier behavior. 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?

No output schema, but the description covers return contents well: conviction score, synthesis components, settlement tracking, and tier-gated chain. Adequate for agent understanding of what to expect.

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%, but the description adds context: taskId is from submit_research, wallet is for tier-gated access and auto-resolved from provision_wallet. This enhances understanding beyond bare schema descriptions.

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

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

The description clearly states the tool retrieves a completed research dossier by taskId, listing specific contents (conviction score, synthesis, settlement tracking, and tier-gated evidence chain). It distinguishes from sibling tools like submit_research and other 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 implies use after submit_research (since it takes taskId from that tool) but does not explicitly state when to use or avoid this tool, nor provide alternatives. Usage guidance is left implicit.

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 exist, so the description must carry behavioral disclosure. It mentions pagination (default 50, max 100) but does not state whether the tool is read-only, destructive, or has rate limits. It provides reasonable transparency but has 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?

Two sentences front-load the core purpose, then add pagination details and a usage prerequisite. Every sentence adds value 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?

Given no output schema, the description enumerates the returned fields (players, points, wins, losses, win rate, volume) and pagination. It misses sorting order but is otherwise complete for practical use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying pagination limits and noting the prerequisite for seasonId. This goes beyond what the schema provides.

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