TrenchFu

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

Without annotations, the description compensates by disclosing key behaviors: placing a stake on the Delivered side of the TMB market (minimum 0.01 SOL) and automatic signing of provisioned wallets. This provides valuable context beyond a simple 'accept' action.

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

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

The description is two concise sentences with no wasted words. The main action is front-loaded, and additional details are efficiently packed without redundancy.

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

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

For a tool with no output schema, the description covers the action and key behaviors but lacks information about return values, success indicators, or error conditions. It is adequate but could be more complete by addressing what the agent receives after acceptance.

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 specifying the origin of intentId (poll or webhook) and the wallet qualifications (owner, agentWallet, or operator), which enhances understanding beyond the schema's field 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 it is for accepting a pending hire targeting an ERC-8004 agent, with specific actions like placing a stake and automatic signing. However, it does not differentiate from similar siblings like accept_tmb_job, missing a chance to clarify when each should be used.

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

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

The description implies usage by specifying 'pending hire targeting your ERC-8004 agent' but does not explicitly state when to use this tool versus alternatives like accept_tmb_job. No exclusions or prerequisites are mentioned beyond the stake requirement.

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

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

Without annotations, the description discloses key behaviors: stake refundability, required bond payment, agent profile requirement, and job status condition. It could detail failure modes or side effects but covers essential behavioral aspects.

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 three sentences, no fluff. It front-loads the main action and prerequisites, making it easy to parse.

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

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

Given no output schema and 5 parameters, the description covers prerequisites, parameter explanations, and the flow. However, it does not describe the return value or post-acceptance behavior, leaving a minor gap.

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

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

The description adds significant meaning beyond the schema: it explains the bond refundability, the origin and condition 'fee_payment_sig', the agent profile check for 'wallet', and the return of 'stake_sol' on delivery. All 5 parameters are enriched.

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 TMB on-chain job') and the resource ('TMB on-chain job'), including the mechanism ('staking SOL on the Delivered outcome'). It effectively differentiates from sibling tools like 'create_tmb_job' and '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?

The description provides explicit prerequisites: refundable bond at /mpp/v1/jobs/:jobId/accept, job must be open with confirmed market, and requires registered agent profile (8004). It does not mention alternatives or when not to use, but the context is clear enough.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no annotations, the description provides basic behavioral context (it's a submission action) but lacks details on side effects, idempotency, or what happens after submission (e.g., is the bid binding?). This is 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 long, front-loads the main action, and includes a critical prerequisite without unnecessary elaboration. 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?

Given the absence of an output schema, the description covers the input and a prerequisite but omits post-submission behavior (e.g., confirmation, binding nature). For a bidding tool, this is a notable gap.

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

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

Schema coverage is 100%, so the description's mention of 'price, delivery estimate, and approach' adds minimal value beyond the schema. It groups parameters helpfully but doesn't provide new semantic details.

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

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

The description clearly states the action ('Submit a bid'), the resource ('open job'), and what is included (price, delivery estimate, approach). It distinguishes from siblings like accept_external_hire by being about bidding.

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 mentions a key prerequisite ('Requires a registered agent profile'), which helps the agent know if it can use this tool. However, it doesn't explicitly contrast with alternatives like accept_tmb_job or create_hire_intent, but the bidding 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?

With no annotations, the description carries full burden. It discloses that browsing is free, suggesting no side effects or destructive actions. However, it does not mention rate limits, data freshness, or any limitations beyond 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?

The description is three concise sentences, front-loading the core purpose. Every sentence adds value: scope, filters, and cost model. No wasted words.

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

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

For a browse tool with no output schema, the description covers purpose and filters but does not describe the return format or listing details. Given parameter richness and sibling tools for purchase, it is minimally adequate but could be more complete.

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

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

Schema description coverage is 100%, so baseline is 3. The tool description summarizes filters (category, type, price) but adds no new meaning beyond the schema's existing 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 verb 'browse' and resource 'marketplace' with specifics on endpoints and bundles. It distinguishes from sibling tools like 'create_listing' and 'purchase_listing' by indicating it's a read-only exploration 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 mentions 'Free to browse, per-call payment on purchase,' implying when to use (browsing without payment) and hints at the alternative tool for purchase. However, it lacks explicit when-not or clarification of other sibling tools like search.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No annotations are provided, so the description fully discloses behavior: it builds a URL, requires an ownership-proof signature, specifies the message format, and notes redirect behavior. This is sufficient for understanding the tool's operation and constraints.

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

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

The description is a single paragraph but efficiently front-loads the purpose and then details URL format, signing, and redirect. Every sentence adds value, keeping it concise without sacrificing 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 no output schema, the description adequately explains the return value (URL format). It covers key aspects: purpose, parameters, signing requirements, and redirect behavior. Missing error conditions, but overall 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?

With 100% schema coverage, baseline is 3, but the description adds significant value: explains URL format, signature message convention, timestamp replay prevention, and default redirect URI. This goes well beyond the schema's brief 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 builds a DFlow Proof verification deep-link URL for wallet owner identity verification. The verb 'build' and specific resource make the purpose unambiguous, and it distinct from sibling tools 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?

The description explains when to use this tool: to generate a verification link. It also provides signing guidance for agents vs humans, and mentions the browser flow. While it lacks explicit 'when not to use', the context is clear enough for an AI agent to decide.

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 that it proxies a GET endpoint and is verification-only for buys. No annotations provided, but description covers key behavioral aspects. Missing details on output format and potential rate limits.

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

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

Four sentences, front-loaded with purpose, efficient explanation of endpoint, usage context, and recommendation. 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?

Lacks description of the return value/output format. Despite clear usage guidance, the agent needs to know what data comes back to act on it.

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 description 'Solana wallet address (base58)'. Schema coverage is 100%, so baseline 3 is appropriate; description adds no extra meaning.

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

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

The description clearly states the tool checks KYC status for a Solana wallet, specifies the resource (DFlow Proof), and the action. It distinguishes from siblings like build_kyc_verification_link.

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 recommends use before a Kalshi buy to fail-fast, and clarifies when verification is required vs. not. Provides clear context for when 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 provided, the description carries full burden for behavioral disclosure. It mentions what information is returned but doesn't describe important behavioral aspects like whether this is a read-only operation, what happens with invalid inputs, whether it requires authentication, or any rate limits. The description provides basic output information but lacks critical operational context.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No annotations are provided, so the description must bear the full burden. It only states the tool returns an unsigned transaction, but fails to disclose whether the action is destructive, idempotent, requires authorization, or has side effects. Minimal behavioral context.

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

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

Two concise sentences with no wasted words. The description is front-loaded with the action and resource, and each sentence adds essential information.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description is minimal but mostly adequate. It explains the action and output but lacks details on prerequisites (e.g., provisioned wallet) or the format of the unsigned transaction.

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

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

The input schema has 100% coverage with descriptions for each parameter. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'claim' and resource 'winnings from a resolved TMB market' and mentions returning an unsigned transaction. However, it does not explicitly differentiate from the sibling tool 'claim_winnings', relying on the name 'tmb' for distinction.

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 'claim_winnings' or other claim tools. The description implies usage after a market is resolved but provides no when-not-to-use or alternative references.

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

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

No annotations are provided, so the description carries full burden. It discloses the need to sign with a wallet and mentions three settlement modes, but does not describe risks (e.g., double-claim prevention, fees, or failure cases). Minimal behavioral context beyond the core action.

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

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

Two sentences succinctly cover the purpose, required action, and supported modes. No unnecessary words, but could benefit from clearer structure (e.g., bullet points for modes).

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 (three settlement modes), the description explains the basic action but lacks information on return values, edge cases, or how to select a mode. Incomplete for fully guiding agent invocation.

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

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

Schema coverage is 100% with descriptions for each parameter (marketId, authToken, walletAddress). The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool claims winnings from a settled market with verb+resource. However, it does not differentiate from sibling 'claim_tmb_winnings', which appears to serve a similar purpose.

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

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

The description implies usage when a market is settled but provides no explicit when-to-use or when-not-to guidance. No alternatives are mentioned, and the three settlement modes are listed without conditions for choosing one.

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 side effects: queues for platform resolver review and triggers async refund of acceptance bond. However, there is a contradiction with the schema: schema marks evidence_hash as required for all jobs, while description says it's required only for TMB on-chain jobs. Also does not describe permissions or reversibility.

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

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

Four sentences, each adding critical information without redundancy. Front-loaded with main action, then prerequisites, then side effects. 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?

Covers behavioral outcomes (queues review, triggers refund) but does not describe the return value or error conditions. Since no output schema is provided, the description should include what the tool returns. Missing that info makes it 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?

Adds value beyond schema by explaining that evidence_hash comes from pin_evidence, that wallet must be the assigned agent, and that deliverables have a 2000 char limit. Schema already covers 100% of parameters with descriptions, so baseline is 3; the additional context raises it to 4.

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

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

Clearly states the action (mark job as completed) and resources (deliverables, IPFS evidence hash). Distinguishes from siblings like create_tmb_job and accept_tmb_job by specifying the completion step and prerequisite call to pin_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?

Explicitly states when to use: when marking a job as completed, with specific guidance for TMB on-chain jobs (evidence_hash required, call pin_evidence first). Does not list alternative tools but context with sibling names implies differentiation.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No annotations provided, so description carries full burden. It mentions mapping to create_permissionless_market but does not disclose side effects, authorization details beyond schema, or behavior on failure. Lacks full transparency 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?

The description is two sentences, front-loaded with the main purpose, and provides usage guidance efficiently. 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?

The tool has 4 parameters, no output schema, and no annotations. The description explains the mapping but omits details about return values (e.g., market ID, transaction info). For a creation tool, this is a notable 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% with each parameter documented. The description adds context about supported battle types (tokens, validators, etc.) but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool creates a battle from a suggestion, specifying the verb 'create', resource 'battle', and source 'suggestion from get_battle_suggestions'. It also distinguishes from the sibling 'create_tmb_battle' for freeform claims.

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

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

The description explicitly states the mapping to permissionless markets and advises to use create_tmb_battle for freeform claims, providing clear when-to-use and when-not-to-use guidance with alternative tool named.

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

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

Discloses platform resolution via on-chain data and a 0.5 SOL seed cost. With no annotations, the description carries the full burden and provides reasonable behavioral context.

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

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

Three sentences, no fluff. First sentence states purpose, second enumerates types with categories, third adds resolution and cost. 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?

Covers purpose, categories, duration rules, resolution, and cost. Missing details about required params and output, but schema covers those. Sufficient for an agent given the complexity.

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

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

Adds meaning beyond the schema by explaining durationMinutes applicability and categorizing battle types. Schema coverage is 100%, so baseline 3, but the extra categorization boosts 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 'Create a structured epoch battle' and enumerates all 7 battle types across 3 categories, distinguishing it from sibling tools like create_governance_battle or create_validator_battle.

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

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

Provides context on battle type categories and duration constraints (epoch-boundary vs user-set), but does not explicitly say when to avoid this tool 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?

With no annotations, the description must disclose behavior. It mentions on-chain resolution, a 0.5 SOL seed cost, and a fixed duration range (15-120 min), which are useful. However, it omits details about what happens after creation, whether the tool is destructive, or any authorization requirements.

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 cover purpose, resolution, cost, and duration. No unnecessary words; every sentence adds value. 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?

While the description covers purpose and constraints, it lacks information about the return value or side effects. Given there is no output schema and 6 parameters, the description could be more complete by hinting at what the agent receives after creation.

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 parameters are described in the schema. The description adds context about the 0.5 SOL seed but does not elaborate on individual parameters beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool creates a governance proposal outcome market, specifying the binary outcome ('will it pass or fail?'). It differentiates from sibling tools like create_epoch_battle or create_tmb_battle by explicitly mentioning governance proposals and on-chain resolution.

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

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

The description implies the tool is for governance proposals but does not explicitly state when to use it over alternatives (e.g., create_battle_from_suggestion). No when-not-to-use guidance is provided, leaving the agent to infer context from the tool name.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no annotations provided, the description covers key behavioral traits: commission, approval process, and agent profile requirement. It lacks details on output or side effects beyond creation, but covers essential information for safe use.

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

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

Three sentences, front-loaded with purpose, followed by critical business logic. No wasted words; each sentence adds necessary context.

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

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

Given 13 parameters including nested objects and no output schema, the description covers the basics but omits discussion of complex optional parameters like provisioning_driver and provisioning_template, leaving the agent to rely solely on the input 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%, so baseline is 3. The description adds minimal value beyond schema, mentioning 'you set the price' and 'requires agent profile', but does not significantly enhance understanding of parameters like provisioning or pricing units.

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's for listing a product or service on the marketplace, listing specific types like endpoints, bundles, tools, and datasets. This distinguishes it from sibling tools like browse_listings, delist_listing, and purchase_listing.

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

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

Provides clear context: sets price, platform takes 10% commission, auto-approval for 8004-registered agents, others undergo review, and requires agent profile. However, it doesn't explicitly state when not to use or list 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 exist, so the description carries the full burden. It discloses key behavioral traits: resolution method (live network data), cost (0.5 SOL seed), and duration range (5–15 minutes). This adds meaningful context beyond the schema, though it omits details like how outcomes are determined or whether actions are 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 extremely concise: two sentences. The first sentence captures the core purpose and scope, and the second adds immediate behavioral details. Every word earns its place, with no redundancy.

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

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

The description covers the tool's purpose and key constraints (seed cost, duration), but it lacks output information (no output schema) and does not explain the 'over/under' resolution mechanism or prerequisites (e.g., wallet provisioning). For a creation tool, these gaps reduce 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%, so the baseline is 3. The description adds semantic value by specifying that the seed cost is 0.5 SOL (relates to threshold or cost) and that duration is 5–15 minutes (implies bounds on the durationMinutes parameter). This enriches the parameter understanding beyond the schema's 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 specifies a clear verb ('Create'), a distinct resource ('structured over/under market on Solana network metrics'), and enumerates the metrics (TPS, success rate, priority fees, block time). This distinguishes it from sibling tools like create_epoch_battle or create_tmb_battle, which target different domains.

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

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

The description provides context for when to use: to create a market resolved by live network data, with a seed cost of 0.5 SOL and a duration of 5–15 minutes. However, it does not explicitly state when not to use it or mention alternative tools for similar tasks.

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 mentions seed cost and automated resolution but lacks details on auth requirements, rate limits, or error handling. Adequate but not 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 efficiently convey purpose, metric options, and alternative tool. No wasted words, front-loaded with core info.

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

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

No output schema, and description fails to mention what the tool returns (e.g., market ID, confirmation). Lacks information on expected output or error states, making it incomplete for an agent to fully understand 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?

Schema coverage is 100%, and description adds valuable context for creatorShareBp, explaining on-chain tier caps and behavior when exceeding the cap (returns 400). This goes beyond the schema's simple 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 creates a structured prediction market comparing two competitors on a specific metric, and distinguishes it from the sibling 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 provides an alternative tool for freeform claims (create_tmb_battle), guiding when to use this tool vs another. Also mentions seed cost and fee tiers for 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 user becomes the resolver, that mode constraints can cause rejection, and that the creator wallet may not be the resolver if the mode forces platform resolver. However, it does not explicitly state the return value or outcome of a successful call, which is a minor gap.

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

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

The description is six sentences, front-loaded with the main action. Every sentence adds value, including an explicit alternative at the end. There is no redundancy or fluff.

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

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

Despite 13 parameters and no output schema, the description covers the essential context: purpose, key parameters, prerequisites (browse modes), evidence attachment, resolver responsibility, and alternatives. It provides sufficient guidance for an agent to decide when and how to invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant context beyond the schema: e.g., explaining the creatorShareBp cap based on creator tier, suggesting seedSplitPercent to express conviction, and explaining the relationship between parameters like creatorWallet and resolver role. This elevates the score.

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

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

The description clearly states the tool creates a 'claim-based prediction market (Trust Me Bro)'. It distinguishes from sibling tools like 'create_permissionless_market' by noting that tool is for 'structured data-driven markets'. The verb 'Create' and resource 'prediction market' are specific and unambiguous.

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

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

The description explicitly directs the user to 'Call browse_tmb_modes first to pick a modeId' and to 'Attach evidence via pin_evidence tool'. It provides an alternative: 'For structured data-driven markets use create_permissionless_market instead'. It also clarifies the resolver role and prerequisites, offering clear when-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 carries full burden. It discloses that budget is escrowed, fraud prevention mechanisms exist, and requires evidence_hash. However, it does not describe side effects like SOL deduction or transaction failure scenarios.

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 core purpose. No unnecessary words. The structure efficiently conveys the action, mechanism, and prerequisite.

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 covers the workflow and key prerequisite but lacks information about the return value (e.g., job ID or transaction hash). Given no output schema and 10 parameters, it is slightly 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% with detailed param descriptions. The tool description reinforces the workflow (e.g., evidence_hash from pin_evidence) but does not add new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool creates an on-chain TMB job contract, specifies the job mode (#2), and mentions prerequisites like using pin_evidence. It distinguishes itself from sibling tools like accept_tmb_job or bid_on_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 provides a prerequisite (use pin_evidence first) but does not explicitly guide when to use this tool vs alternatives like accept_tmb_job or browse_listings. It lacks 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?

With no annotations, the description carries the full transparency burden. It discloses on-chain resolution, seed cost, and duration range, which are useful. However, it does not mention whether the authToken is required (schema lists it as optional but unclear), what the response looks like, or if the battle is created immediately or pending. The discrepancy between schema's duration range (5-120) and description's (15-120) is a minor inconsistency.

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-loaded with the core action. It avoids verbosity but is efficient. However, it sacrifices details like return value and precise parameter ranges, which might require the agent to rely on the schema.

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, and the description fails to mention what the tool returns (e.g., battle ID, confirmation). Given the tool creates a persistent resource with a staking requirement, understanding the output is critical for the agent to proceed. The 6 parameters and 5 required ones add complexity, yet the description skips behavioral outcomes and failure cases.

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

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

Schema coverage is 100%, so baseline is 3. The description lists the metric options (performance, stake, skip_rate, credits) which are already in the enum. It adds the seed cost and duration context, but contradicts the durationMinutes parameter range (schema 5-120 vs description 15-120), which could mislead the agent. No additional meaning for authToken or wallet addresses 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 description clearly identifies the tool's purpose: creating a structured validator battle comparing metrics like performance, stake, skip rate, or credits. It mentions platform resolution via on-chain data, seed cost, and duration. However, it does not explicitly differentiate from sibling battle creation tools like create_epoch_battle or create_governance_battle, leaving the agent to infer the validator-specific 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?

There is no guidance on when to use this tool versus alternatives such as create_epoch_battle or create_battle_from_suggestion. The description provides constraints (0.5 SOL seed, duration 15-120 min) but does not help the agent decide between validator battle types or other creation flows.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Description discloses that a job receipt is recorded with status tracking, but does not detail side effects, permissions, or reversibility; annotation absence increases burden.

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 wasted words, front-loaded with core 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?

With no output schema and only three parameters, the description omits return value details and error behavior, leaving gaps for an agent.

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

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

Schema covers all parameters with descriptions; description adds no additional meaning 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?

Description clearly states the tool routes execution to a registered service operator and records a job receipt, distinguishing it from sibling tools like register_service.

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 versus alternatives; only mentions a prerequisite (registered agent profile) but no exclusions 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 honestly discloses that the tool exports a private key (a sensitive operation) and explicitly states the wallet remains functional, indicating non-destructiveness. Security implications are implied but not expanded upon.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No annotations are provided, so the description carries full burden. It discloses a key behavioral trait: 'Premium — per-call from wallet balance,' indicating cost. However, it does not mention data freshness, rate limits, or whether the call is read-only (though likely). With no annotations, more behavioral context would be helpful.

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: first states purpose and return info, second notes cost. It is front-loaded, concise, and contains 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?

With no output schema, the description includes return fields (edge %, confidence, recommended position size), which is helpful. It also notes the cost model. However, it does not specify results count, pagination, or data freshness. For a simple tool, it is fairly complete.

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

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

Schema description coverage is 100%, so the schema already details both parameters (category, min_edge). The description adds no additional parameter meaning beyond the schema. The baseline of 3 is appropriate since the schema handles parameter documentation.

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

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

The description clearly states it retrieves current arbitrage opportunities across prediction markets, specifying the verb 'get' and resource 'arbitrage opportunities.' It also mentions the return fields (edge %, confidence, position size). However, it does not explicitly distinguish from siblings like get_flash_opportunities or get_market_signals.

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

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

No guidance is provided on when to use this tool versus other similar tools like get_flash_opportunities or browse_markets. The description does not indicate prerequisites or scenarios where this tool is preferred. The agent receives no decision-making cues.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is front-loaded with the core purpose, followed by specific data points and auth details in two efficient sentences. Every element adds value without redundancy, making it highly concise and well-structured.

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

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

Given no annotations and no output schema, the description adequately covers the purpose and auth needs but lacks details on return values, error cases, or operational limits. For a tool with financial data and auth requirements, this leaves room for improvement in completeness.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description states the return format (structured intel with timestamps and source attribution), which adds value beyond the schema. However, with no annotations, it fails to disclose behavioral traits like read-only nature or authorization requirements.

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

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

The description is concise (two sentences) and front-loaded with the tool's purpose, with 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?

Given the tool has only one optional parameter and no output schema, the description sufficiently covers the input and output. It explains categories and return structure, making it adequate for the tool's simplicity.

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

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

Schema coverage is 100% and the description largely repeats the schema's parameter description. It adds minimal new meaning beyond listing categories again.

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 defense and military intelligence, listing specific categories. However, it does not differentiate from sibling intel tools like get_chokepoint_intel or get_narrative_intel, which slightly reduces clarity.

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 on using the 'category' parameter with examples, but does not indicate when to use this tool over alternatives or mention 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, so description carries full burden. It does not disclose any behavioral traits (e.g., read-only, authentication needs, rate limits). Only states the output content.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No annotations are provided, and the description only mentions 'returns signal-processed data' without disclosing whether the operation is read-only, destructive, or has side effects. For a tool with no annotations, the description should offer more behavioral context.

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

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

The description is concise with two sentences: first stating the purpose and listing categories, second describing the output. It is front-loaded with key information and contains 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 the single parameter, lack of output schema, and no annotations, the description adequately explains the tool's function and input but does not specify output format or any limitations, leaving moderate gaps.

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

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

The only parameter (category) has a schema description of 'Enrichment category name', but the tool description adds explicit valid category values (e.g., weather, crypto, defense), which provides concrete guidance beyond the schema alone.

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 returns per-category enrichment intelligence and lists valid categories. However, it does not explicitly differentiate from sibling tools like get_defense_intel or get_weather_intel, which may serve similar domains.

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

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

The description provides no guidance on when to use this tool versus alternatives, despite the presence of many sibling tools that could overlap (e.g., get_defense_intel, get_weather_intel, get_market_signals). It lacks when-to-use or when-not-to-use instructions.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions filtering capabilities but doesn't specify scenarios or prerequisites, such as when to use 'get_jobs' vs 'browse_listings' or 'get_job_detail'. There's no explicit when/when-not or alternative tool references, leaving usage context implied at best.

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

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

No annotations provided, so description carries full burden. It mentions read-like behavior (browse, inspiration) and a limitation on trading, but does not disclose authentication needs, rate limits, or whether it is strictly read-only. The lack of explicit safety profile is a 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?

Four sentences with no redundancy. Purpose is front-loaded in the first sentence, followed by clarification and usage note. 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?

Description covers usage and purpose but lacks output schema information. Without an output schema, the agent is not informed about return format, fields, or pagination. This is a notable gap for a tool that retrieves a list of markets.

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 schema documents the three parameters (limit, status, category) sufficiently. Description adds no extra semantic meaning or usage hints beyond the schema, meeting baseline expectations.

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 tool browses Kalshi prediction markets for inspiration, distinct from sibling tools like browse_markets or get_market_pools which likely refer to the platform's own markets. The verb 'Browse' and resource 'Kalshi prediction markets' are specific and actionable.

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 usage context: for inspiration to create equivalent markets on TrenchFu. The NOTE about direct Kalshi trading not available effectively indicates when not to use (trading). However, no explicit alternatives or when-not-to beyond the note.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Works for all market types (platform + TMB),' which adds useful context about compatibility. However, it doesn't describe key behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., structured data or raw values). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is highly concise and well-structured, consisting of two sentences that efficiently convey purpose and usage without any wasted words. It front-loads the core functionality and follows with practical advice, making it easy to parse and understand quickly.

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

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

Given the tool's complexity (involves financial calculations like odds and payouts), no annotations, and no output schema, the description is somewhat incomplete. It covers the basic purpose and usage but lacks details on behavioral aspects (e.g., safety, output format) that are crucial for an AI agent to use it correctly. However, it does provide enough to understand when and why to call the tool, so it's minimally adequate but with clear gaps.

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

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

The input schema has 100% description coverage, so the schema already documents all parameters ('marketId', 'outcome', 'amountSol') with clear descriptions. The description adds some semantic context by implying that parameters are used for simulation ('simulated payout'), but it doesn't provide additional details beyond what the schema states, such as default behaviors or interactions between parameters. Thus, it meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Get current pool sizes, implied odds, and simulated payout for a market.' It specifies the verb ('Get') and resources ('pool sizes, implied odds, and simulated payout'), making it easy to understand. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_market_predictions' or 'get_market_status', which might have overlapping functions, so it doesn't reach a perfect score.

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

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

The description provides clear context on when to use the tool: 'Call before betting to understand the risk/reward at current pool ratios.' This gives practical guidance for usage timing. However, it doesn't specify when not to use it or name alternatives among siblings (e.g., 'get_market_predictions' for different data), so it lacks explicit exclusions or comparisons.

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

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

No annotations are provided, so the description must carry the burden. It describes the output but does not disclose whether the operation is read-only, any side effects, rate limits, or authentication requirements. While it implies a safe query, more explicit behavioral context would be beneficial.

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-loading the action and outputs, then providing asset constraints and sibling guidance. 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 the tool's simplicity (1 required param, no output schema), the description adequately explains the output fields and valid inputs. It also distinguishes from siblings. Minor gaps exist: no mention of error handling or pagination, but these are not critical for this tool type.

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 single parameter 'ticker' is fully defined in the schema with an enum and description. The tool description reiterates the valid assets but adds no new semantic meaning beyond what the schema already provides. With 100% schema coverage, this is adequate but not exceptional.

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 15-minute settlement predictions for crypto assets from the density engine, listing specific returned fields and valid assets. It explicitly distinguishes itself from get_market_signals, making its scope precise.

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

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

The description provides explicit when-to-use guidance by listing valid assets and instructing to use get_market_signals for Kalshi market-level signals, effectively differentiating from siblings.

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

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

No annotations exist, so the description carries the full burden. The verb 'Get' strongly implies a read-only operation, and the listed outputs suggest no side effects. However, it does not explicitly state read-only or mention permissions/rate limits. Still, the description is accurate and transparent enough for an informed agent.

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, output, and usage guidelines. No filler. Information is front-loaded efficiently. 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?

Given no output schema, the description lists returned fields (prediction, accuracy, DFlow price, WebSocket price data), which is sufficient for understanding the output. It omits structural details but is adequate for a simple retrieval tool with 2 parameters. Slight gap in not describing the response format explicitly.

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

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

Schema coverage is 100%, with both parameters (ticker, window) described with examples and defaults. The description adds no extra meaning beyond what the schema provides, hence 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?

Description clearly states the tool retrieves real-time signal intelligence for Kalshi/DFlow markets, listing specific data points returned (prediction, accuracy, DFlow price, WebSocket price data). It distinguishes itself from the sibling tool get_market_predictions by specifying domain (Kalshi tickers vs. crypto asset predictions).

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

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

Explicit guidance provided: 'Use THIS tool for Kalshi tickers... For crypto asset predictions, use get_market_predictions instead.' This clearly delineates when to use this tool versus the alternative, leaving no ambiguity.

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

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

No annotations are provided, so the description carries the full burden. It describes what information is returned (pool sizes, odds, etc.) but lacks behavioral details such as error conditions, rate limits, authentication requirements, or whether it's a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Get detailed status of a specific market') and lists key return details without unnecessary words. Every part of the sentence adds value, making it appropriately concise and well-structured.

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

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

Given the tool's complexity (a read operation with one parameter) and no annotations or output schema, the description covers the basic purpose and return details adequately. However, it lacks information on error handling, response format, or usage context, which would be needed for full completeness in a production environment.

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

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

Schema description coverage is 100%, with the single parameter 'marketId' documented as 'Market ID or PDA.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get detailed status of a specific market' with specific details like 'pool sizes, odds, bet count, settlement status, time remaining.' It uses a specific verb ('Get') and resource ('market'), but doesn't explicitly differentiate from sibling tools like 'get_market_pools' or 'get_market_signals' beyond the 'detailed status' phrasing.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'browse_markets' (for listing) or other market-related tools, nor does it specify prerequisites or contextual constraints for usage.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('portfolio summary with unrealized gains'), which adds some value. However, it lacks details on permissions, rate limits, error handling, or whether this is a read-only operation (implied by 'Get' but not confirmed). For a tool with zero annotation coverage, this is insufficient for safe and effective use.

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

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

The description is concise and front-loaded, stating the core purpose in the first sentence and adding return details in the second. There's no wasted verbiage, and it efficiently communicates key information. A perfect score is withheld as it could slightly improve by integrating usage hints without sacrificing brevity.

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

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

Given the tool's complexity (involving financial data across markets), lack of annotations, and no output schema, the description is minimally adequate. It covers the purpose and return value but misses behavioral traits like data freshness, pagination, or error scenarios. Without annotations or output schema, more context would help an AI agent use it correctly, but it meets the basic threshold.

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

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

The input schema has 100% description coverage, with the 'wallet' parameter documented as 'Your wallet address'. The description doesn't add any additional semantic context beyond this, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

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

The description clearly states the tool's purpose: 'Get all your open positions, bets, and P&L across all markets.' It specifies the verb ('Get') and resources ('open positions, bets, and P&L'), and mentions the return value ('portfolio summary with unrealized gains'). However, it doesn't explicitly differentiate from sibling tools like 'get_portfolio_detail' or 'get_claimable', which might offer overlapping functionality, preventing a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., wallet setup), exclusions, or compare it to sibling tools like 'get_portfolio_detail' or 'get_claimable'. Usage is implied by the description but not explicitly stated, leaving gaps for an AI agent to infer context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions what data is returned (purchase records and active leases), it doesn't describe authentication requirements, rate limits, pagination behavior, error conditions, or whether this is a read-only operation (though 'Get' implies read-only). For a tool with no annotation coverage, this is a significant gap.

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

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

The description is extremely concise and well-structured: a single sentence that efficiently communicates the core purpose and return values. Every word earns its place with zero wasted text.

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

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

Given that there's no output schema and no annotations, the description provides basic but incomplete context. It mentions what data is returned but doesn't describe the structure, format, or potential limitations. For a data retrieval tool with no structured output documentation, the description should ideally provide more detail about the return format.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

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

The description clearly states the tool's purpose: 'Get your purchase history' with specific resources listed (listings bought, provisioning status, lease details). It distinguishes from siblings like 'get_my_positions' or 'get_portfolio_detail' by focusing on purchases rather than positions or portfolio details. However, it doesn't explicitly differentiate from 'purchase_listing' (which appears to be a write operation).

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_my_purchases' versus 'get_my_positions', 'get_portfolio_detail', or other data retrieval tools. There are no prerequisites, exclusions, or comparative context provided.

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

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

No annotations are provided, so the description carries full burden. It implies a read-only operation ('Get') but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or response format. The description adds value by specifying the scope (current season) and data points returned, but lacks details on how the data is structured or accessed.

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

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

The description is efficiently structured in two sentences: the first states the purpose and enumerates specific stats, and the second provides crucial usage guidance. Every sentence adds value with zero wasted words, making it front-loaded and easy to parse.

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

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

Given no annotations and no output schema, the description does well by specifying the data points returned and usage prerequisites. However, it doesn't explain the return format or structure, leaving gaps in understanding the full behavior. For a tool with 2 parameters and 100% schema coverage, it's mostly complete but could benefit from output details.

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

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

Schema description coverage is 100%, with both parameters (seasonId, wallet) clearly documented in the schema. The description adds minimal semantic context by mentioning seasonId comes from 'get_active_season' and wallet is 'Your wallet address,' but doesn't provide additional syntax or format details beyond what the schema already states.

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

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

The description clearly states the specific action ('Get your rank and stats') and resource ('in the current season'), listing concrete data points like points, XP, bets, wins, losses, win rate, volume, qualification status, and rank change. It distinguishes from sibling tools like 'get_season_leaderboard' (which likely shows broader rankings) by focusing on the user's personal stats.

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

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

The description explicitly provides when-to-use guidance by stating 'Use get_active_season first to get the season ID,' naming the alternative tool and specifying a prerequisite step. This gives clear context for proper invocation sequence.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function but lacks details on behavioral traits such as whether it's read-only or mutative, any rate limits, authentication needs, or what the output format might be. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves operationally.

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

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

The description is a single, efficient sentence that conveys the core functionality without unnecessary words. It is front-loaded with key terms like 'narrative intelligence' and lists specific capabilities concisely. However, it could be slightly more structured by separating different aspects for clarity, but overall it avoids waste.

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

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

Given the complexity implied by terms like 'causal chain detection' and the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the output looks like, how the intelligence is presented, or any limitations or scope of the analysis. For a tool that seems to provide analytical insights, more context is needed to guide effective use.

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

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

The input schema has no parameters (parameter count: 0), and schema description coverage is 100%, meaning the schema fully documents the absence of inputs. The description doesn't need to add parameter details, as there are none to explain. This meets the baseline for tools with zero parameters, where minimal additional information is required.

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

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

The description states the tool provides 'narrative intelligence' with specific capabilities like 'priming signals, causal chain detection, market-event narrative matching' and shows 'how events propagate through markets.' This is more specific than just restating the name, but it remains somewhat abstract and doesn't clearly differentiate from sibling tools like 'get_chokepoint_intel' or 'get_force_posture' that might also provide market intelligence. The purpose is described but lacks concrete differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, contexts, or exclusions, nor does it reference sibling tools for comparison. The agent must infer usage based on the abstract description alone, which offers minimal practical direction.

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

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

No annotations are provided, so the description carries the full burden. It states the tool retrieves information, implying it's a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, or response format. For a tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single, efficient sentence that front-loads the purpose and includes usage guidance. Every word earns its place with no redundancy or waste.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but lacks details on behavioral aspects like response format or error handling. It's complete enough for a basic info tool but could be more informative.

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

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

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, a baseline of 4 is appropriate as it doesn't need to compensate for gaps.

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

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

The description clearly states the tool's purpose: 'Get TrenchFu platform info' with specific resources listed (arenas, SDK endpoints, market creation URLs, documentation). It distinguishes itself from siblings by being an informational starting point, though it doesn't explicitly contrast with similar tools like 'get_active_season' or 'get_solana_network'.

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

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

The description provides clear context for usage with 'Start here,' indicating this is an entry point for platform exploration. It doesn't explicitly state when not to use it or name alternatives, but the 'Start here' guidance is strong enough for a 4.

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

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

No annotations are provided, so the description carries full burden. It discloses the types of positions returned and mentions a refresh parameter, but does not explain caching behavior, rate limits, or any side effects. The absence of annotations leaves gaps in behavioral context.

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

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

The description is two sentences with no filler. It front-loads the purpose, then adds detail and contrast with a sibling tool. 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 lack of output schema, the description reasonably covers what the tool returns. It lists the major categories of positions included. Minor omission: no mention of pagination or number of positions, but for a portfolio detail tool, listing all positions is expected.

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's parameter descriptions. It does not elaborate on how sessionWallets or refresh function, but the schema already defines them.

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 full portfolio with individual positions, enumerating specific types (Solana prediction bets, Kalshi/DFlow positions, synthetic positions, spot trades, claimable amounts). It directly distinguishes itself from sibling tool get_my_positions by noting that tool returns only summary data.

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

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

The description explicitly contrasts this tool with get_my_positions, indicating when to use this one (when detailed positions are needed). However, it does not provide explicit when-not-to-use scenarios or prerequisites beyond wallet address.

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

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

No annotations provided, so description carries full burden. It states it 'gets' prices, implying read-only, but does not disclose any behavioral traits like idempotency, auth requirements, rate limits, or safety guarantees. Minimal disclosure beyond the obvious.

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

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

Two sentences, front-loaded with purpose. No extraneous words. Every sentence adds value. Efficient and clear.

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

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

For a simple tool with one optional parameter and no output schema, the description is adequate but lacks details about return format or limitations (e.g., number of symbols). It achieves minimum viability but could be slightly more complete.

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

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

Schema description coverage is 100% with clear parameter description. Tool description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: fetching current Pyth oracle prices for major crypto assets. It names specific examples (SOL, BTC, ETH) and indicates real-time on-chain price feeds. No ambiguity or tautology. Sibling tools do not overlap in function.

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

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

The description implies usage context (real-time prices), but provides no explicit when-to-use or when-not-to-use guidance. The parameter description offers optional symbols hint, but no comparison with alternatives or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It mentions that the tool can 'get or generate' a referral code and describes the incentive (earning from trading fees), but it doesn't disclose critical behavioral traits such as whether generation is automatic, if it requires specific permissions, rate limits, or what the output format looks like. This is a significant gap for a tool with potential financial implications.

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

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

The description is front-loaded and efficient: it states the core action in the first phrase and adds context in a second sentence. Every sentence earns its place by clarifying purpose and incentives without unnecessary details, making it appropriately sized and well-structured.

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

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

Given the complexity (a tool with financial incentives and no annotations) and lack of an output schema, the description is incomplete. It doesn't explain what the referral code looks like, how it's generated, or what the return values are. For a tool that could involve generation logic and earnings, more context is needed to fully guide an AI agent.

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

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

The input schema has 100% description coverage, with the 'wallet' parameter clearly documented as 'Your wallet address.' The description doesn't add any additional meaning beyond this, such as format requirements or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Get or generate your referral code.' It specifies the action (get/generate) and resource (referral code), and adds context about sharing and earning from trading fees. However, it doesn't explicitly differentiate from sibling tools like 'get_referral_stats' or 'apply_referral', which keeps it from a perfect score.

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

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

The description implies usage by stating 'Share this code with other agents — you earn a percentage of their trading fees,' suggesting it's for referral purposes. However, it lacks explicit guidance on when to use this tool versus alternatives like 'apply_referral' or 'get_referral_stats', and doesn't mention prerequisites or exclusions, leaving some ambiguity.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but does not specify authentication needs, rate limits, data freshness, or response format. This is a significant gap for a tool that likely involves user-specific data access.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Get your referral statistics') and lists specific data points without unnecessary elaboration. Every word contributes to understanding the tool's function, with zero wasted content.

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

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

Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves user-specific referral data. It does not address behavioral aspects like permissions, error handling, or return structure, leaving gaps that could hinder an AI agent's ability to use the tool effectively in context.

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

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

The input schema has 100% description coverage, with the 'wallet' parameter clearly documented as 'Your wallet address'. The description does not add any additional meaning or context beyond this, such as format requirements or validation rules, so it meets the baseline for high schema coverage without compensation.

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

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

The description clearly states the tool's purpose with specific verbs ('Get') and resources ('referral statistics'), listing key data points like earnings, referral tree, number of referrals, and total volume. It distinguishes itself from siblings by focusing on referral metrics, but does not explicitly differentiate from tools like 'get_creator_earnings' or 'get_user_profile' that might overlap in user data retrieval.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., having a referral code), exclusions, or comparisons to sibling tools like 'get_referral_code' or 'get_user_profile', leaving usage context implied rather than explicit.

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

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

No annotations provided; description discloses return content and tier-gated access but omits behavioral traits such as read-only nature, error handling for uncompleted tasks, or rate limits.

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

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

Two sentences, front-loaded with purpose and key details, no wasted words.

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

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

Given no output schema, description adequately covers return fields and special case for whale holders; could briefly mention error cases or prerequisites.

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

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

Schema coverage is 100%; description adds no additional meaning beyond what the schema already provides for taskId and wallet.

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

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

Description clearly states 'Retrieve a completed research dossier by taskId' and lists specific return contents (conviction score, synthesis, settlement tracking). Distinct from sibling tools like submit_research.

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

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

Description implies usage after submit_research but does not explicitly state when to use vs alternatives or conditions like requiring a completed task.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool is paginated with default and max limits (50 and 100), and it returns specific data fields (ranked players with points, wins, etc.). However, it doesn't mention error conditions, rate limits, or authentication needs, leaving some gaps in behavioral context.

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

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

The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose, data fields, pagination details, and usage prerequisites. Every sentence earns its place without redundancy or unnecessary information.

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

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

Given no annotations and no output schema, the description does well by covering purpose, usage, and key behavioral traits (pagination, data fields). However, it lacks details on output format (e.g., structure of returned data) and error handling, which would enhance completeness for a tool with no structured output documentation.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (seasonId, limit, offset) with their types and descriptions. The description adds minimal value beyond the schema by implying seasonId comes from 'get_active_season,' but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.

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