PoolParty Main Stage Airtime

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

Absent annotations, the description fully carries the burden. It explicitly states the tool only records wallet identity and does not perform any signing or fund-moving actions. It also mentions authentication requirements, providing clear behavioral boundaries.

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

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

The description is brief yet comprehensive, with front-loaded action statement, followed by scope, parameter usage, and explicit exclusions. 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 and lack of output schema, the description adequately covers usage context (session-based, for later mint preparation) and behavioral boundaries. It could mention return value briefly, but is sufficient for tool selection.

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

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

Schema coverage is 100%, baseline 3. The description adds value by clarifying that channelSlug must be allowed by the API key, sessionToken is preferred, and walletAddress requires later approval. This enriches the schema definitions meaningfully.

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 attaches an EVM wallet address to a submission session, with specific verb-resource pairing. It distinguishes from sibling tools by listing what it does not do (sign, mint, etc.), making its purpose unambiguous.

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

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

The description specifies required scope (submit:block) and correct session identifiers (sessionToken or agentSessionId). It implicitly guides when to use via negative statements but does not explicitly mention when not to use or directly name alternative tools for signing/minting.

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?

Annotations are absent, so the description carries the full burden. It states read-only and no auth, plus lists return fields. However, it doesn't disclose pagination behavior, rate limits, or error conditions, which are common for a browse tool.

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

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

The description is three well-structured sentences: purpose, return details, and behavioral notes. No wasted words, front-loaded with key 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 output schema, the description lists the main categories of return data. While it could explain filter combination behavior, it is sufficient for a browse tool. The high schema coverage and zero required parameters reduce the need for extensive description.

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 all 8 parameters. The description does not add additional parameter semantics beyond what the schema already provides, meeting 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 tool browses PoolParty channels with filters and lists key return fields. It distinguishes itself as read-only but does not explicitly differentiate from sibling tools like get_channel_feed or resolve_channel.

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 indicates usage for discovering channels and accepts submissions, but lacks explicit when-not-to-use or alternative tool guidance. The read-only and no-auth hints are useful but not enough for a higher score.

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

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

No annotations provided, so description carries full burden. It discloses key behavioral traits: does not recover raw API keys, auto-provisioned keys shown only once, and that it's public with no auth required. This provides excellent 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?

Description is three sentences, front-loaded with the main purpose followed by clarifications. Every sentence adds value with no waste.

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

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

Given the tool's simplicity (single param, no output schema), the description fully covers what it returns, its limitations, and access requirements. No gaps identified.

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

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

Schema coverage is 100% for the single parameter, but description adds context by specifying the parameter is the request ID returned by request_pilot_key, which enhances meaning beyond the schema 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 checks the status of a pilot key request and returns specific statuses (pending, approved, rejected). It distinguishes itself from sibling tools like request_pilot_key (which creates requests) by its 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 after requesting a key but does not explicitly state when to use versus alternatives. It provides some guidance by stating what it does not do (e.g., does not recover raw keys), but lacks explicit usage 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 provided, so description carries full burden. Discloses that it never silently funds, explains modes, and specifies auth requirements (no MCP auth but wallet-owner approval or signer for Amoy). Fully 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?

Four sentences, each essential, front-loaded with main purpose, no wasted words.

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

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

Covers all parameters and key behaviors. No output schema, but describes return for default mode. Slightly incomplete on output format for other modes, but sufficient.

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

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

Schema description coverage is 100%, baseline 3. Description adds value by providing examples for channelSlug and clarifies purpose of agentSessionId, exceeding 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 prepares or records a PP0 test collateral faucet claim for a wallet, specifying modes and behavior, distinguishing it from siblings like claim_test_pol.

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 guidance on default mode (returns transaction request, never silently funds), explicit rehearsal modes, and requirements for Amoy transactions (wallet-owner approval or agent signer). Missing explicit comparison to siblings.

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

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

With no annotations, the description carries full burden. It discloses auth requirements (no MCP auth), public nature, mode-dependent behavior (funding from PoolParty vs rehearsal grants), and the agentSessionId parameter for rate-limit identity. No contradictions.

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

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

The description is informative but slightly verbose (e.g., 'Public wallet bootstrap action' could be integrated). Each sentence adds value, but some redundancy exists. Well-structured with mode breakdowns.

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?

Provides comprehensive behavior across modes, auth requirements, and usage context. Lacks return value explanation (no output schema), but the description adequately covers the tool's purpose and operation for a test POL claiming tool.

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

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

Schema coverage is 100% with descriptions, so baseline is 3. The description adds context for channelSlug (e.g., 'PP0', 'Main Stage') and ties it to the amoy-transfer mode. This provides extra 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?

The description clearly states the tool sends or records bounded PP0 test POL for Polygon Amoy gas. It specifies the context (when wallet lacks gas) and lists the modes (default amoy-transfer, local-dev, mock), distinguishing it from other tools.

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

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

Explicitly advises using before prepare_block_mint, pool_block, or withdraw_pool_support when wallet lacks gas. Also describes mode-specific behavior (default vs local-dev/mock), giving clear when-to-use and alternative modes.

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

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

With no annotations, the description fully explains behavioral traits: it clarifies that for Livepeer, a canonical handoff requires specific readiness conditions, and for S3 direct it returns only fallback_ready. It explicitly states it does not mutate queue/runtime state, ensuring the agent understands side effects.

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

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

Three concise sentences, no wasted words. The purpose is front-loaded, and each sentence adds essential context: purpose, prerequisites, provider behavior, and side-effect clarification.

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 10 parameters and no output schema, the description covers provider modes, prerequisites, and state behavior. It lacks explicit details about the return value or error conditions, but it provides enough context for typical usage. A mention of success/failure indicators would improve completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the provider enum semantics (omit for livepeer inference, use s3_direct only for explicit fallback) and the role of duration. This enhances understanding beyond the schema descriptions.

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

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

The description clearly states the tool's purpose as 'Complete or check canonical media readiness after an upload.' It distinguishes from siblings by specifying it does not submit a block, contrasting with submit_media_block, and mentions provider-specific behaviors.

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 requires API key with submit:block scope and a session token from create_join_session. It provides guidance on when to use Livepeer vs S3 direct. However, it does not explicitly name alternative tools for when the user needs to submit a block, though it implies this tool is not for that.

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 for behavioral transparency. It discloses that the tool never attempts SuperBlock purchase, never returns private material, and reports in amoy-prepare mode until wallet transaction finality. It also mentions the idempotency key and default behavior for executeWithdraw. These details give an agent good insight into the tool's behavior, though it could mention response format or error conditions.

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

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

The description is a single, dense sentence that conveys several pieces of information but lacks clear structure. While it is not overly long, packing prerequisites, constraints, and exclusions into one sentence reduces readability. Breaking it into multiple sentences or bullet points would improve clarity without adding length.

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 (8 parameters, no output schema), the description covers prerequisites, scope, and some behavioral traits. However, it does not describe the return value or response format, which leaves a gap for an AI agent to understand what to expect after invocation. Since there is no output schema, this omission is notable.

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, providing baseline meaning for all parameters. The description adds value by explaining that blockId must be 'Pool-eligible active user BLOCK id discovered from get_channel_feed poolEligibility' and that channelSlug only supports 'main'. It also notes that assignedWallet response is redacted and simActorAlias is preferred. These enrichments help an agent select correct parameter values.

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: 'Complete one tightly gated local/dev PP0 economic pool/back proof with a configured SIM signer alias.' It uses a specific verb (complete), identifies the resource (pool/back proof), and specifies the context (local/dev, PP0, SIM signer alias), which distinguishes it from sibling tools like pool_block or withdraw_pool_support.

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

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

The description provides explicit usage guidelines including required authorization (Bearer <pilot_key> with economic:proof scope), environment variable (PP0_SIM_ECONOMIC_ACTION_ENABLED=1), channel constraint (main), and prerequisite block discovery (via get_channel_feed). It also states who cannot use it (public auto-provisioned submit:block keys). While it doesn't explicitly list alternative tools, the constraints sufficiently guide an AI agent on when to use this tool versus others.

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 this is a mutation requiring specific scope, but lacks detail on side effects (e.g., impact on existing submissions) or behavior beyond the schema. It does not mention response or rollback 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?

Three sentences with front-loaded purpose, each earning its place. No redundancy; requirements are clearly stated. Ideal length for a tool with 12 parameters.

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 purpose and prerequisites but omits behavioral details like success/failure responses or constraints on batch updates. For a no-output-schema mutation, more context would help, but the schema fills many gaps.

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

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

Schema coverage is 100%, so each parameter has a description. The description adds high-level grouping (QR card copy, community slot titles, etc.) but does not elaborate on parameter behavior beyond schema defaults. Baseline of 3 is appropriate.

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

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

The description clearly states the tool configures open-call/submission guidance for a channel with a community slot. It lists specific actions (update QR card copy, titles, theme, toggle submissions) and identifies the resource, distinguishing it from siblings like update_channel_settings or get_open_submission_calls.

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

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

The description provides clear prerequisites: requires configure:channel scope and a channel with community_slot. It does not explicitly state when not to use or name alternatives, but the context is sufficient for an 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?

With no annotations, the description fully discloses behavioral traits: it creates channel plus program and starter blocks in ACTIVE_UNLISTED state, notes that the channel is not publicly discoverable until admin promotes, and mentions rate limits. This is comprehensive for a create operation.

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

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

The description is relatively concise with multiple sentences covering purpose, requirements, side effects, and usage tips. It is front-loaded with the primary action. Could be slightly more terse, but no unnecessary 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?

Given the tool has 7 parameters and no output schema, the description covers key aspects: creation effect, state, discovery, prerequisites, and rate limits. It does not mention return value, but overall it is sufficiently complete for an agent to understand the tool's impact.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds extra context by advising to use list_channel_templates to choose templateId, which goes beyond schema. Some repetition of schema details (slug auto-generation) but overall adds value.

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

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

The description clearly states 'Create a new PoolParty channel from an approved starter blueprint,' specifying the action and resource. It distinguishes from sibling tools like list_channel_templates and preview_channel_template by mentioning them as prerequisites.

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

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

Explicitly provides when to use: requires API key with create:channel scope, suggests using list_channel_templates and preview_channel_template first, and states rate limit of 3 per hour per key. This gives clear guidance on prerequisites and usage 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 provided, so description carries full burden. It discloses key behaviors: anonymous sessions, up to 3 submissions, wallet required for reward eligibility not submission. Lacks details on session expiration or error responses, but is adequate.

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

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

Three sentences, front-loaded with the core purpose. Each sentence adds essential information without fluff. Ideal conciseness.

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

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

Given simple input (one parameter) and no output schema, the description covers purpose, return value, usage constraints, and wallet nuance. Missing error handling details, but is sufficient for an agent to select and invoke the tool correctly.

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

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

Only one parameter channelSlug, with schema description already covering format and requirement. Tool description adds no extra meaning beyond the schema. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

Clearly states the tool creates an anonymous participation session for a PoolParty channel and returns a sessionToken for use with submit_media_block. The verb 'create' and resource 'session' are specific, and the description distinguishes this tool from siblings by linking to submit_media_block.

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

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

Provides context on when to use (for anonymous participation) and prerequisites (API key with submit:block scope, wallet required for rewards not submission). Does not explicitly list alternatives or when not to use, but the purpose is sufficiently 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 provided, the description carries full burden. It discloses that no auth is required, the output is a draft only, and it requires operator review. It does not detail what happens to the draft (e.g., stored as a pending item) but covers key 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 two sentences: the first states the core purpose, the second outlines constraints. It is front-loaded, concise, and contains no redundant information.

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

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

Given 14 parameters and nested objects, the description covers core behavior but lacks detail on the draft's lifecycle (e.g., return value, how to retrieve or proceed). The sibling tools provide some context, but the description itself could be more complete for a complex tool.

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

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

Schema coverage is 100%, so all parameters have descriptions. The tool description adds minimal extra meaning beyond the schema; it mentions 'commands, screenshots, claims, or rough demo notes' which aligns with parameters but does not enhance understanding. 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 identifies the tool as drafting a SlideBlock/Proof Block package from various inputs (proof, commands, screenshots, claims, rough demo notes). It distinguishes from siblings like preview_slide_block and revise_slide_block by explicitly stating it is draft-only and does not submit or finalize.

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 that this is a draft-only operation requiring operator review, and it does not submit, bypass moderation, mint, etc. This provides clear context for when to use the tool, but it does not name specific sibling tools as alternatives for finalization or other actions.

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 behavior. It outlines the sequence of operations (verify receipt, parse event, write rows, report eligibility) and states it is a public wallet action with no auth required. However, it does not describe failure modes, idempotency, or side effects like overwriting existing data.

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

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

The description is concise with three sentences. The first sentence states the primary purpose, the second details key operations, and the third clarifies auth and non-payment nature. No extraneous words; front-loaded with 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 complexity of the tool (5 parameters, no output schema), the description explains the process but lacks details on return value format, error handling, and expected outcomes beyond 'reports pool eligibility'. Additional context on output would improve completeness.

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

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

All 5 parameters have descriptions in the input schema (100% coverage). The tool description adds no additional parameter-specific information beyond what the schema already provides, so the description adds minimal semantic value.

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

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

The description clearly states the verb and resource: 'Finalize canonical PP0 block NFT minting'. It lists specific actions (verify receipt, parse event, write rows, report eligibility) and distinguishes this from related tools like prepare_block_mint and get_block_mint_status by indicating it is the final step after broadcasting the mint transaction.

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

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

The description explicitly states when to use: 'after the wallet broadcasts mintBlock'. It also clarifies auth requirements and that x402 payment is unrelated. However, it does not explicitly mention when not to use or list alternative tools, leaving room for 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?

The description details the tool's behavior: verifies Polygon Amoy receipt, checks sender/block/amount/contract, writes canonical state, updates fields, and returns next actions. It also notes no MCP auth required and explains what x402 payment is not. Without annotations, this provides good transparency, though side effects like irreversibility are not mentioned.

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 lists the main actions. It front-loads the key verb 'Finalize' and the condition. Could be slightly more structured but is sufficiently concise without wasting words.

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

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

Given 5 parameters and no output schema, the description provides reasonable completeness: it explains each step and mentions return values ('withdrawal/readback next actions'). However, lacking output schema, more detail on the return format would be 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% and the parameter descriptions in the schema are already clear. The tool description does not add significant new meaning beyond summarizing the purpose. Baseline score of 3 is appropriate as per guidelines.

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: finalizing PP0 pool support after broadcasting poolIntoBlock or creator-collateral support. It distinguishes itself from siblings like 'withdraw_pool_support' by specifying the exact context and actions (receipt verification, state updates) and clarifies it's a public wallet action with no MCP auth.

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

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

The description explicitly states when to use the tool (after wallet broadcasts pool support) and mentions it's a public action without MCP auth. However, it does not explicitly advise against use in other scenarios or name alternatives, though the context is clear enough for an agent to differentiate.

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 explicitly declares the tool as 'Read-only' and 'No auth required', which are key behavioral traits. It also mentions transparent scoring reasons, adding beyond basic safety. However, it does not detail side effects (though none expected) 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?

The description is three sentences with no wasted words. It front-loads the purpose in the first sentence, lists return fields in the second, and states properties in the third. Efficient and structured.

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

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

For a read-only evaluation tool with a single parameter and no output schema, the description covers purpose, return fields, and safety. It could benefit from explaining the recommendation values (submit/watch/wait/avoid) but is largely complete.

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

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

Schema description coverage is 100% for the single parameter 'channelSlug', so the schema already provides the meaning. The description does not add additional syntax, format, or context beyond the schema example. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: to evaluate whether a PoolParty channel is a good airtime opportunity. It specifies the verb 'evaluate' and resource 'airtime opportunity', and differentiates from siblings like get_collateral_opportunity by focusing on airtime. The return fields are explicitly listed, adding 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?

Usage is implied (when you need to check an airtime opportunity), but there is no explicit guidance on when to use this tool versus alternatives such as get_collateral_opportunity or get_reward_opportunities. No exclusions or when-not-to-use conditions 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 provided, so description carries full burden. It explicitly states 'Public read. No auth required' and 'without promising rewards', clearly disclosing the read-only nature and a behavioral nuance. This goes beyond what the input schema conveys.

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 (4 sentences), front-loaded with the core action, and every sentence adds value. No redundancy or filler.

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

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

Even without an output schema, the description lists all returned categories in detail, making the tool's behavior fully understandable. Given the complexity of block economics, this is sufficient.

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

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

Schema description coverage is 100% for both parameters. The description adds extra context (e.g., 'after pooling or airing') that helps interpret when to use these parameters, putting them in the tool's workflow context.

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 starts with 'Read PP0 block economics after pooling or airing', a specific verb and resource. It then enumerates the exact data returned, distinguishing it from sibling tools like 'get_channel_metrics' or 'get_pooling_receipt'.

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 'after pooling or airing' and 'Public read. No auth required', giving clear context. However, it does not explicitly state when not to use it or compare to alternatives among the many sibling tools.

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

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

With no annotations, the description fully discloses it is a read operation with no auth. It lists the statuses and included fields (on-chain id, tx intent status, poolEligibility, next actions). However, it does not mention error handling or behavior when the block is not found.

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

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

The description is two sentences: first for purpose and resource, second for output and access. It is front-loaded with the key action and resource, and every sentence adds value 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?

Despite no output schema, the description adequately explains return values (statuses and fields) and next actions. It is complete for a read tool with three parameters, though it could clarify the meaning of 'canonical' or 'PP0' for new users.

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 descriptions for all 3 parameters. The description adds no new parameter-level context; it only mentions the optional walletAddress filter, which is already in the schema. Thus, it meets baseline but does not significantly enhance parameter understanding.

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

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

The description states 'Read canonical mint status for a PP0 media block' with a specific verb and resource. It clearly distinguishes from sibling mutation tools like prepare_block_mint and finalize_block_mint, and from other read tools by specifying the exact status and fields.

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 says 'Public read. No auth required,' which guides when to use it. It also mentions next actions like prepare_block_mint or finalize_block_mint, hinting at sequential usage but does not explicitly state when not to use or provide direct 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?

The description explicitly states the tool is read-only and requires no authentication, which are key behavioral traits. It also outlines what the return includes (fields, defaults, constraints, behavior, examples). However, without annotations, it could further clarify idempotency or side effects, though 'read-only' covers most concerns.

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

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

The description is extremely concise, consisting of three short sentences that immediately convey the tool's purpose, return content, and key behavioral properties (read-only, no auth). No unnecessary words or redundancies.

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 read-only tool with one parameter and no output schema, the description fully covers what the tool does, what it returns, and its safety profile. All necessary context is provided without over-explaining.

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 'blockType' has full schema coverage (100%) with a description including examples. The tool description does not add additional parameter guidance beyond what the schema provides. Since the schema itself is clear, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves a detailed schema for a specific block type, listing specific returned components (fields, defaults, constraints, behavior, examples). It distinguishes itself from sibling tools like list_block_types by focusing on a single block type's schema.

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 explicit guidance on when to use this tool versus alternatives (e.g., list_block_types). While the purpose is clear, it lacks usage context or exclusion statements, leaving the agent to infer usage based on 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?

No annotations present, so description carries full burden. Mentions read-only, no auth required, and that the feed may be large. Does not detail potential performance impact or pagination, but adequately describes 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?

Multiple sentences but each adds value; front-loaded with purpose and data details. Slightly long but not verbose.

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

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

Given 3 parameters, no output schema, and no annotations, description covers return data, usage, and limitations. Lacks details on pagination or error cases, but still fairly complete for a read-only diagnostic tool.

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

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

Schema coverage is 100%, and description repeats parameter names implicitly but adds no extra meaning beyond schema. Baseline 3 due to high schema coverage.

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

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

Description clearly states it retrieves rich recent airings and queue evidence for a PoolParty channel, listing specific data fields. Distinguishes from sibling get_channel_stream by specifying diagnostic usage.

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 when-to-use (diagnostic) and alternatives (get_channel_stream for first-pass, REST endpoints for snapshot/SSE watch). Clearly differentiates 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, the description fully discloses the tool's behavior: it is read-only, requires no authentication, and each metric includes a measurement status (five concrete states), eliminating ambiguity. It also enumerates the data categories returned, providing a clear behavioral contract.

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

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

The description is a single, front-loaded paragraph with no filler. Every sentence provides essential information: it names the tool's function, explains metric statuses, lists return categories, and notes safety. There is no wasted text.

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

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

Given the absence of an output schema, the description compensates by listing the return fields (freshness, queue depth, etc.) and explaining the metric statuses. For a simple one-parameter tool, this is nearly complete, though it omits potential edge cases like pagination or error handling.

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

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

Schema coverage is 100% for the single parameter (channelSlug), and the schema description already specifies the format (e.g., 'pp1'). The tool description adds no additional semantics beyond this, so the baseline of 3 applies as per guidelines.

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 'Channel Pulse v2 metrics' for a PoolParty channel, specifies the exact action and resource, and differentiates from sibling tools like get_channel_feed or get_platform_pulse by focusing on channel-specific metrics. The list of included metrics further clarifies its 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 mentions 'Read-only. No auth required,' implying safe usage, but does not explicitly state when to use this tool over alternatives or provide context-specific guidance. No direct comparison to siblings or exclusion criteria are given.

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

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

Explicitly states 'Read-only. No auth required.', adding value beyond the no-annotation baseline. Does not discuss error behavior or rate limits, but sufficient for a simple read operation.

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

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

Two short sentences with no filler. First sentence fronts purpose and outputs, second gives usage guidance and attributes. Every word earns its place.

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

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

Enumerates many return categories (status, now playing, queue, etc.) despite no output schema. Lacks structural detail but sufficient for a compact first-read tool. No output schema needed given the enumeration.

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 has 100% coverage with good parameter descriptions. The tool description adds minimal extra meaning, mainly confirming that limit controls summary rows. 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 reads the current channel state, listing specific data categories. It differentiates itself from the sibling get_channel_feed by labeling itself as 'compact first-read'.

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?

Directly says 'Prefer this before rich get_channel_feed', providing explicit ordering guidance. Also labels itself as 'first-read', indicating it should be the initial call.

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

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

No annotations provided, but the description fully discloses behavior: it's a read operation with no authentication required. Lists the fields returned, providing transparency into the response structure.

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

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

Single sentence with a list of returned fields. Front-loaded with the primary purpose. No unnecessary words.

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

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

For a simple read tool with one parameter and no output schema, the description is complete: covers purpose, returned data, and authentication. No gaps.

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

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

Schema coverage is 100% and the description of 'channelSlug' in the schema already provides examples. The tool description adds minimal additional semantic value beyond the schema.

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

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

Specific verb 'Read' and resource 'collateralized block opportunity' with clear scope 'PP0 Main Stage'. The description distinguishes from sibling tools by focusing on a particular get operation and explicitly stating it's public and auth-free.

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

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

States 'Public read. No auth required.' indicating when to use, but does not explicitly mention when not to use or provide alternative tools. However, given the specific focus, the usage is clear.

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

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

Without annotations, the description carries the full burden and discloses that the tool is 'Read-only. No auth required,' which is a key behavioral trait. It also describes the output content (entry status, block state, etc.). However, it does not cover potential errors or rate limits, but for a read-only report tool this is acceptable.

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 consists of two focused sentences. The first covers purpose and output, the second covers parameter usage and properties. No extraneous words; every sentence adds value.

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

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

Given no output schema, the description explains what the report shows (entry status, etc.) and covers the two use cases with parameter guidance. It does not explain return format or error handling, but for a read-only report tool with 5 optional parameters, this is reasonably complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters into two scenarios (entryId/blockId vs. entitlementId/purchaseId) and noting channelSlug as additional context, going beyond the schema's individual 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 gets a distribution report for media block or superblock reservations, listing what the report shows (entry status, block state, etc.) and the two distinct scenarios (community submissions vs. superblock reservations). This specifies the verb and resource, and the mention of two parameter sets helps distinguish from sibling tools like get_block_economics or get_block_mint_status.

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

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

The description provides explicit guidance on when to use this tool: 'Provide entryId/blockId for community submissions, or entitlementId/purchaseId for superblock reservations.' It gives clear context for two use cases but does not explicitly state when not to use it 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states that the raw key is not exposed, lists returned fields, and confirms the read-only nature. This provides solid transparency for a simple token inspection tool.

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

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

The description is extremely concise, with two sentences that efficiently convey the tool's purpose, safety, and output. Every word adds value, and the key action is front-loaded.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description is complete. It covers what the tool does, what it returns (including redaction), and access requirements (auth, no write scope). No gaps are apparent.

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

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

There are zero parameters, and the schema coverage is 100%, so the baseline score of 4 applies. The description adds value by enumerating the returned fields, which helps the agent understand what information the tool provides.

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

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

The description clearly states the verb 'Inspect' and the resource 'current MCP Bearer token', making the tool's purpose unmistakable. It distinguishes this token introspection tool from sibling tools that deal with channels, blocks, or other resources.

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 notes that it is a 'Protected read' requiring auth but no write scope, guiding the agent on when it is safe to use. However, it does not explicitly mention when not to use or suggest alternatives, which would further enhance clarity.

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 carries the burden. It declares read-only behavior, no authentication required, and lists the return fields, providing excellent transparency about what the tool does and its side-effects.

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

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

The description is three sentences, front-loads the purpose, and every sentence adds value. No unnecessary words or repetition.

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

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

Given no output schema, the description compensates by listing return fields. It covers authentication, read-only nature, and parameter usage. For a simple list tool, the description is fully complete.

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

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

The schema has 100% coverage for the single optional parameter, with a clear description already. The tool description does not add additional semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool finds channels accepting community submissions and lists specific return fields, making its purpose unambiguous. It is distinct from sibling tools like get_airtime_opportunity or get_reward_opportunities.

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

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

The description explicitly says 'Use this to decide where to submit content.' It also notes 'Read-only. No auth required.' which informs appropriate usage context. It does not mention when not to use or name alternatives, but the guidance 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 exist, so description carries full burden. Discloses what receipt fields expose and notes that sponsor receipts omit private fields, adding useful behavioral context beyond a simple 'get receipt'.

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?

Concise, front-loaded purpose, with each sentence providing essential information. No redundancy.

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

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

For a simple read tool with one parameter and no output schema, the description adequately covers purpose, scope, and receipt contents, though it lacks error or edge-case information.

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

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

Schema already provides full description of the single parameter (intentId), and the description adds no additional semantic information beyond that.

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

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

Clearly states 'Get the stable agent-readable PoolParty receipt for a paid action intent' – specific verb, resource, and scope. Distinct from sibling tools like get_pooling_receipt.

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?

Mentions required API scope ('purchase:prepare') but does not provide guidance on when to use this tool versus alternatives like settle_paid_action or other get_* tools.

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

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

With no annotations provided, the description carries full burden. It explicitly states 'Read-only. No auth required,' which informs the agent of safety and permission requirements. This is sufficient for a tool with no side effects.

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

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

Two concise sentences that front-load the purpose and list return fields. Every word serves a purpose; 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 (zero parameters, no output schema), the description adequately covers the return information and behavioral notes. A higher score would require more detail on data format or typical response size, but current completeness is good.

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, and schema description coverage is 100%. Baseline score of 3 is appropriate as the description adds no parameter-level detail, but none is needed.

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

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

The description states a specific verb and resource ('Get a high-level summary of PoolParty platform activity') and enumerates the return fields (active channels, blocks aired, submissions, active reward campaigns). It clearly distinguishes itself from sibling tools by being a broad overview rather than a specific metric.

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 it's for a quick overview but does not explicitly state when to use this tool versus alternatives like get_channel_metrics or get_block_economics. 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 transparency burden. It clearly states the operation is a read with no side effects (implied by 'Public read') and no auth required. The list of return fields further enhances transparency.

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

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

The description is two sentences, front-loaded with purpose, followed by return value details and access information. 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?

For a simple read tool with two parameters and no output schema, the description fully covers purpose, parameters, return values, and access. No gaps.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema, so baseline 3 is correct.

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 starts with 'Read a derived PP0 pooling receipt for a pool position,' providing a specific verb and resource. It clearly distinguishes from siblings like get_wallet_pooling_state by focusing on a specific receipt type.

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

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

The description states 'Public read. No auth required,' clarifying when to use the tool. However, it does not explicitly exclude scenarios or mention alternatives, so a 4 is appropriate.

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 correctly declares read-only behavior and no authentication, and details return contents. It lacks error scenarios or rate limits, but for a simple retrieval tool, coverage is good.

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

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

The description is a single sentence listing key returns, followed by two short statements. Every word adds value, no fluff. Perfectly concise.

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

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

For a simple tool with one parameter, no output schema, and no annotations, the description covers purpose, return content, and safety. It could mention response format or potential errors, but overall is adequate.

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

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

Schema coverage is 100% with one parameter. The description adds no extra meaning beyond the schema's example values. Baseline at 3 is appropriate.

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

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

The description uses a specific verb 'Get' and resource 'detailed manifest for a program mode', clearly distinguishing it from siblings like 'get_block_economics' or 'get_channel_feed'. It also lists return contents, making the tool's purpose unmistakable.

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

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

The description states 'Read-only' and 'No auth required', providing clear usage context. However, it does not explicitly guide when to use this tool versus alternatives like 'list_program_modes' or mention prerequisites, which would elevate it to a 5.

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

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

With no annotations provided, the description carries full burden. It explicitly states 'Read-only' and 'No auth required,' which are critical behavioral traits. It also lists the return fields (reward amount, pool remaining, etc.) but does not disclose potential limitations like rate limiting or real-time 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 three sentences long, front-loading the main purpose and return data. Every sentence adds value: purpose, returns, usage, and behavioral notes. No wasted words, making it efficient for an agent.

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 zero parameters, the description provides a thorough list of returned data (reward amount, pool remaining, etc.) and behavioral traits. It is complete enough for an agent to understand what to expect, though it could mention pagination or number of channels.

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

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

The input schema has zero parameters, so there are no parameters to describe. According to the rubric, '0 params = baseline 4,' and the description adds no param information, which is appropriate. The schema coverage is trivially 100%.

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

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

The description clearly states the tool's purpose: 'Find channels with active reward pools.' It specifies the verb (find) and resource (channels with reward pools), and distinguishes from siblings like 'get_collateral_opportunity' and 'get_open_submission_calls' by focusing specifically on reward pools.

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

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

The description provides clear usage context: 'Use this to find where submissions can earn rewards.' It explicitly states behavioral traits like 'Read-only' and 'No auth required,' helping the agent understand when to use it. However, it does not compare to alternatives or specify when not to use it, missing a full guideline.

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 fully covers behavioral traits: non-mutating, public read, no auth, return of redacted info, explicit list of what is not exposed (full addresses, keys, mnemonics). This exceeds the 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?

Three well-structured sentences. The first sentence introduces the main action, followed by a list of return values and then safety constraints. No redundant information.

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

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

The description covers return values, safety, and parameter hints. It could mention when to prefer this over other similar tools (e.g., get_airtime_opportunity), but overall it is sufficiently complete for a read tool with clear parameters.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it reiterates that parameters are optional and that full addresses are not returned, which is already implied by the schema and description text.

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

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

Description clearly states the verb 'read' and the resource 'SIM signer availability', with specific context 'local/dev PP0 economic rehearsal'. It distinguishes itself by listing what it returns and what it doesn't expose, setting it apart from sibling tools.

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

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

Description provides context about when to use (public read, no auth required) and what to expect, but does not explicitly state when not to use or mention alternatives. The context is clear enough for basic 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 provided, the description carries full responsibility for behavioral disclosure. It correctly states 'Read-only. No auth required,' which is essential. However, it does not mention other traits such as rate limits, data freshness, or potential errors, which would improve 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 three concise sentences with no superfluous words. The key information (purpose, output details, usage hint) is front-loaded in the first sentence, making it efficient for an AI agent to parse.

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

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

Given the tool's simplicity (no parameters, no output schema), the description covers the main aspects: purpose, output content, usage context. It is missing minor details like whether results are paginated or cached, but overall it is sufficient for an agent to use correctly.

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

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

The tool has zero parameters, so baseline is 4. The description does not need to add parameter meaning since the input schema is empty. It appropriately explains the output structure, which complements the lack of parameters.

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

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

The description clearly states the tool's purpose: finding sponsor and Superblock airtime inventory, and specifies what it returns (tiers, prices, durations, availability, sponsor slots). However, it does not explicitly differentiate from similar sibling tools like get_airtime_opportunity or get_superblock_offerings, 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 some usage guidance ('Use this to find configured scarce-airtime reservations when offerings are active'), implying it should be used when offerings are active. But it lacks explicit when-not-to-use instructions or references to alternative tools, leaving the agent to infer context.

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

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

With no annotations, the description carries the full burden. It explains that Superblocks reserve scarce airtime on PoolParty screens, which implies a limited resource, and states no guarantees on audience or rewards. This provides useful behavioral context beyond a simple 'list'.

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

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

The description is three sentences, front-loading the core action and then adding essential context. There is no redundancy or unnecessary detail.

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

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

Given no output schema and zero parameters, the description is largely complete. It covers purpose, behavioral constraints, and access requirements. It could optionally list the fields in the offerings, but for a simple list tool, this is adequate.

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

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

The tool has no parameters, and the schema coverage is 100% (empty). With no parameters to describe, the baseline is 4, and the description adds no misleading 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 verb (List) and resource (Superblock offerings) and mentions specific fields (prices, durations, inventory). It distinguishes itself from siblings like 'quote_superblock_reservation' by focusing on listing available offerings.

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 indicates read-only and no auth, and notes that the tool does not guarantee audience size or reward outcome, providing context for use. However, it does not explicitly state when to use this tool vs alternatives like 'get_airtime_opportunity'.

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 lists extensive return fields (active, locked, withdrawn, settled, voided, etc.) and explicitly declares the tool as read-only and public. This fully covers behavioral traits beyond annotations, which are absent.

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 dense sentence that conveys all necessary information without redundancy. It could be slightly more structured (e.g., bullet points), but it remains concise and front-loaded with the core action.

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

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

Given no output schema, the description fully compensates by detailing return values (positions, amounts, policy, block context, etc.) and access requirements. No gaps are apparent for a read-only tool.

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

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

The input schema already describes both parameters with clear descriptions (e.g., 'Channel slug or alias'). The description does not add further semantic value for parameters, but schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description starts with 'Read a wallet PP0 pooling state', clearly stating the verb and resource. It distinguishes itself from sibling tools like 'get_block_economics' by specifying the wallet pooling 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 explicitly states 'Public read. No auth required.', indicating when it's safe to use. However, it does not provide alternatives or conditions under which this tool should be avoided, which would elevate the score.

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

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

With no annotations provided, the description properly declares the tool as read-only and notes that no authentication is needed. It also states what data is returned (descriptions and supported modes). This adequately covers behavioral traits.

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

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

Two concise sentences, front-loaded with the action and resource, with no unnecessary information. Every sentence adds value.

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

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

Given no output schema, the description lists the returned block types and mentions they come with descriptions and supported modes. It also covers safety (read-only) and auth requirements. This is complete for a simple list tool with two optional parameters.

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

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

Schema coverage is 100%, so parameters are already documented. The description does not add any additional context or meaning to the parameters beyond what the schema provides.

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

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

The description clearly states the action 'list' and resource 'block types', enumerating the specific types returned. It lacks explicit differentiation from sibling tool 'get_block_type_schema' but the purpose is distinct enough.

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 indicates read-only and no auth required, which implies safe usage without restrictions. However, it does not specify when to use this over alternatives or provide any 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 correctly states 'Read-only' and 'No auth required' and describes the output fields. However, it does not mention potential limits or ordering behavior, which could be useful for a list 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 long, front-loading the purpose and output, then adding key context about creation availability and an alternative 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 tool's simplicity (one optional boolean parameter, no output schema), the description covers its purpose, output, read-only nature, auth requirements, and relationship to a sibling. It is nearly complete, though it could mention default filtering or ordering.

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 for the single parameter 'includePlanned', so the schema already explains it. The description adds no additional meaning beyond what the schema provides, aligning with the baseline score of 3.

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

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

The description clearly states the verb 'list' and resource 'channel creation templates', and specifies the returned fields (template names, program modes, etc.). It also distinguishes the tool from its sibling 'preview_channel_template' by noting that creation is not yet available.

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

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

The description explicitly states when to use the tool (to list templates) and provides an alternative: 'use preview_channel_template to see what would be created'. It also notes that it is read-only and requires no auth, giving clear usage 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 fully covers behavioral traits: read-only, no auth needed. This gives the agent clear expectations about safety and access 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 front-load the core action and follow with details. No unnecessary words or repetition.

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

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

The description covers purpose, read-only, no auth, and what is returned. However, without an output schema, slightly more detail on response structure would improve completeness.

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

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

Schema coverage is 100% with a description for includePlanned. The tool description adds no additional meaning beyond what the schema provides, so baseline score applies.

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

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

Clearly states the tool lists PoolParty program modes and specifies the exact resources (broadcast_loop, video_queue, screening_session) with their attributes. Distinguishes from siblings like get_program_mode_manifest.

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 notes read-only nature and no authentication required, aiding safe usage. However, does not mention when to avoid this tool or suggest alternative tools (e.g., get_program_mode_manifest) for more detailed views.

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?

Despite no annotations, the description fully discloses behavioral traits: it creates a STAKE_ADD transaction intent or local/mock rehearsal state, requires wallet authorization, and states that settlement is inspected later via get_pooling_receipt and get_block_economics. It also clarifies it is a public wallet action with no MCP auth required.

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

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

The description is a single paragraph of 4 sentences, front-loaded with purpose and then steps. It is reasonably concise for the complexity, though slight restructuring could improve readability.

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

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

Given the tool's complexity and lack of output schema, the description covers the action, required follow-up (finalize_pool_support), eligibility criteria, auth requirements, and references sibling tools for settlement. This provides comprehensive context for correct 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%, but the description adds unique context: e.g., blockId exclusion criteria (not eligible types) beyond the schema description. For amount, it repeats the schema description. Overall, it enhances understanding beyond the schema, justifying a score above baseline 3.

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

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

The description clearly states the tool's purpose: using PP0 test collateral to support an eligible active user block and return before/after rank and score consequence. It distinguishes itself from sibling tools like withdraw_pool_support and finalize_pool_support by specifying the action and output.

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: for supporting an active user block with test collateral. It includes steps for Amoy prepare mode (submit transaction, then call finalize_pool_support), eligibility criteria (not eligible: program blocks, operator media, etc.), and auth requirements (wallet-owner approval or funded wallet signer). This offers clear usage context and exclusions.

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

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

No annotations provided, so description carries full burden. It details exact outputs (wallet approval facts, USDC request, mint transaction request, etc.) and explicitly states it never signs or broadcasts, providing full behavioral disclosure.

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

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

Single focused paragraph covering purpose, outputs, constraints, and next step. Slightly dense but no wasted words. Could be improved with bullet points for readability.

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

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

Given no output schema, description adequately covers return values, prerequisites (playable block, wallet, session for agents), and the next action (finalize_block_mint). Enough for an agent to use 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. Description adds minor value by noting collateralAmount defaults to staged collateral or PP0 minimum, but otherwise adds nothing beyond schema descriptions.

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

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

The description clearly states it 'Prepare canonical PP0 block NFT minting' and lists returned data, distinguishing it from sibling tools like finalize_block_mint (named as next action) and submit_media_block (prerequisite).

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

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

States it's a public wallet action requiring wallet approval and that it never signs/broadcasts, and identifies finalize_block_mint as the next step. Lacks explicit when-not-to-use or comparison with alternatives, but 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 and details important behaviors: required scope, two output modes (legacy vs ADA-36), idempotency key behavior, and expiration. It does not mention rate limits or error conditions, but the given context is sufficient.

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 dense paragraph of 4-5 sentences, front-loading the purpose and scope. Every sentence adds value 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?

Despite no output schema, the description adequately explains return values for both modes (legacy: purchaseIntent with contract details; ADA-36: HTTP 402 envelope with endpoints) and outlines the settlement process, making it complete for a complex preparatory tool.

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

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

Schema coverage is 100%, and the description adds significant business logic: idempotency key mechanics, offeringId source (from get_superblock_offerings), and wallet address ownership. This goes beyond simple 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 the tool prepares a SuperBlock purchase reservation, distinguishes between legacy and ADA-36 modes, and its non-executing nature sets it apart from sibling tools like settle_paid_action or finalize_block_mint.

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 requires an API key with purchase:prepare scope, notes that reservations expire in 15 minutes, and clarifies that the tool does not sign or broadcast, guiding the agent to use subsequent settlement steps. However, it does not explicitly name alternatives or when not to use it.

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

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

With no annotations, the description carries full burden. It explicitly states 'Read-only. No auth required,' and explains the return contents (starter blocks, submission policy, etc.). It also clarifies that channel creation is not done. This fully discloses the tool's behavior and safety profile.

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

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

The description is extremely concise at three sentences, with the purpose stated in the first sentence. Every sentence adds value: 'Preview what a channel template would create' (purpose), 'Returns...' (output), 'Channel creation not yet available...' (usage context). No redundancy or fluff.

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

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

For a simple one-parameter tool with no output schema, the description is complete. It explains the tool's function, what it returns, and its read-only nature. There is no need for additional information about error handling or rate limits given its simplicity.

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

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

Schema coverage is 100%, with the templateId parameter well-described by examples. The description does not add new parameter semantics beyond what the schema provides. Baseline 3 is appropriate as the schema already 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 previews what a channel template would create, explicitly calling it a dry-run preview. It distinguishes from creation tools by noting channel creation is not yet available. The verb 'preview' with resource 'channel template' is specific and unambiguous.

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

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

The description provides clear context: this is a dry-run preview to simulate channel creation. It implicitly tells when to use (when you want to see the result without creating) and distinguishes from the sibling 'create_channel_from_template' tool. However, it does not explicitly list when not to use or mention alternatives.

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

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

With no annotations, the description fully discloses behavioral traits: it is preview-only, does not perform destructive actions, and requires no authentication. However, it omits details about the return value or error conditions, which would enhance transparency for a validation tool.

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

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

The description is two sentences, front-loaded with the core purpose, and uses clear, direct language. Every sentence adds value with zero wasted words.

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

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

Given the tool's complexity (nested input schema, no output schema), the description covers key aspects: purpose, exclusion list, and auth requirement. It lacks details on the output format, but for a preview/validation tool, the 'summarize' hint is sufficient. Overall, it is adequate 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 50% (channelSettings parameter has a description). The tool description does not add meaning to the package parameter beyond the schema's own fields. Given the low coverage, the description should compensate but fails to provide additional context for the complex nested package object.

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: 'Validate and summarize a SlideBlock package before operator review.' It uses a specific verb (validate and summarize), identifies the resource (SlideBlock package), and sets the context (before operator review). This effectively distinguishes it from siblings like draft_slide_block_from_project and revise_slide_block.

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 what the tool does not do: 'does not submit, bypass moderation, mint, collateralize, or insert ProgramBlocks.' It also notes 'No auth required.' While it doesn't directly compare to sibling tools, these exclusions guide proper usage by clarifying limitations.

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 explains the difference between quote and reserve behaviors (inventory holding, TTL), required auth scope, and return types (x402 envelope, HTTP 402 requirements). No annotations are provided, so the description carries full burden for behavioral disclosure; it does well but could more explicitly state side effects.

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

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

The description is two sentences long, front-loads the purpose and key behaviors, and includes essential information without extraneous words.

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

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

For a tool with 7 parameters, a nested object, and no output schema, the description covers purpose, scope, behavior distinctions, and return types. It lacks details on error handling or pagination but 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 documents parameters thoroughly. The description adds overall context but does not significantly enhance parameter understanding beyond what is in the schema.

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

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

The description clearly states the tool's purpose: 'Quote or reserve a sponsor/lobby card paid action.' It specifies the verb and resource, and distinguishes from sibling tools like 'quote_superblock_reservation' by mentioning 'sponsor/lobby card.'

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 required scope ('Requires API key with purchase:prepare scope') and explains when to use reserve vs pure quote, providing clear usage context. However, it does not explicitly compare to sibling tools or state when not to use this tool.

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

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

With no annotations, the description discloses required scope, return types (x402-compatible envelope, settlement requirements), and that it does not hold inventory. It could mention that it is read-only, but it's implied.

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

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

The description is three sentences with no extraneous information, front-loading the main action and essential context.

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

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

Given no output schema, the description adequately covers purpose, constraints, and usage details. The return type is described enough for an agent to understand the output.

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 describes parameters. The description adds context about the tool's overall behavior but not additional parameter meaning beyond what the schema provides.

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

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

The description clearly states the verb 'quote' and resource 'SuperBlock paid action', and distinguishes it from the sibling 'prepare_superblock_purchase' which creates the payment-required reservation.

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 says 'Pure quote only; use prepare_superblock_purchase to create the payment-required reservation' and mentions required API scope, providing clear when-to-use and alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that the upload target is short-lived, requires specific credentials, and warns not to store signed URLs in artifacts. However, it does not mention rate limits, error handling, or what happens on failure, which would make it fully transparent. Nevertheless, the provided details are substantial.

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 at 5 sentences, all essential. It front-loads the purpose, then systematically covers prerequisites, provider options, upload protocol steps, and a security warning. No redundant or irrelevant information is present.

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

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

Given no output schema, the description should explain return values. It implies a URL but does not list expected fields or response structure. It adequately covers prerequisites, workflow, and warnings, but the lack of output documentation and error handling leaves gaps for a tool with 7 parameters and no output schema.

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

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

The input schema has 100% coverage with descriptions for all 7 parameters. The tool description adds context by mentioning required scope and workflow, but it does not significantly enhance the schema descriptions. Baseline is 3 due to complete schema coverage, and the description provides marginal additional value.

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

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

The description clearly states the tool's purpose: 'Request a short-lived upload target for agent-native video upload.' It uses a specific verb (request) and resource (upload target). The description distinguishes from sibling tools like complete_media_upload by outlining the workflow, making it clear that this tool is for obtaining the URL, not completing the upload.

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

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

The description provides explicit usage guidance: requires an API key with 'submit:block' scope and a session token from create_join_session. It explains the default provider (Livepeer) and when to use s3_direct. It also details the TUS upload steps and instructs to call complete_media_upload before submit, leaving no ambiguity about the 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, so description must disclose behaviors. Mentions no auth required and auto-provisioning for some scopes, but omits side effects, failure modes, or rate limits. Adequate but not comprehensive.

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

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

Single paragraph with three sentences, front-loaded with purpose. Reasonably concise but could be better structured for readability.

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

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

10 parameters, no output schema. Description lacks return value explanation, no mention of optional fields like notes or humanName. Adequate but missing key contextual 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 coverage is 100%, so baseline 3. Description does not add extra meaning beyond schema; references discovery_submission track indirectly but no parameter-level elaboration.

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?

Describes requesting pilot access to protected tools, distinguishes from siblings by specifying auto-provisioning for discovery_submission track and admin review for elevated scopes. Clear verb+resource.

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

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

States when to use (beyond public read/discovery tools), implies when not to use, and provides context on auto-provisioning vs. admin review. Lacks explicit naming of alternative tools.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It clearly states read-only and no auth, but does not describe error behavior for invalid inputs or the exact return format. While the examples help, more details on failure modes would improve transparency.

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

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

The description is extremely concise at two sentences, with the key action verb and examples front-loaded. Every sentence adds essential information without redundancy.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the core functionality, resolution examples, and safety traits. It could mention the return format (a slug string) but is otherwise sufficient for an agent to understand its use.

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

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

Schema description coverage is 100%, so the schema already documents the parameter. The description adds value by providing specific examples of aliases and their resolved slugs, which helps the agent understand valid inputs beyond the schema's generic 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 resolves human channel names/aliases to canonical slugs, with concrete examples like 'PP0, Main Stage, and main resolve to "main"'. This distinguishes it from sibling tools like browse_channels (lists channels) or get_channel_feed (retrieves feed).

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 by stating 'Read-only. No auth required.', which helps the agent know this is safe to call. However, it does not explicitly explain when to prefer this tool over alternatives or when not to use it, missing some guidance for sibling differentiation.

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

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

With no annotations, the description carries full burden. It discloses that revision only is performed, requires operator review and moderation, and does not submit or mint. It mentions no auth required. However, it does not detail side effects like whether the original draft is mutated or if a new draft is created.

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 with front-loaded purpose. Every sentence provides essential information with no wasted words.

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

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

For a complex tool with 7 parameters and nested objects, the description covers the revision workflow, constraints, and exclusions. It mentions return of a preview payload. Could be enhanced with output format or error handling details, but sufficient.

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

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

Schema coverage is high (86%) with detailed parameter descriptions. The tool's description adds no additional parameter-level meaning beyond the schema, 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 revises an existing SlideBlock draft after feedback and returns a preview payload. It explicitly distinguishes from siblings by listing actions it does NOT perform (submit, bypass moderation, mint, etc.), making its purpose unambiguous.

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

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

The description explicitly states when to use (after human/agent feedback) and what it does not do (no submission, moderation bypass, etc.), providing clear usage context. However, it does not explicitly name alternative tools for comparison.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states the required API key scope ('purchase:prepare'), what the tool verifies (tx hash, router event, wallet, chain, token, amount, product/binding, metadata/content binding), and what is rejected (facilitator token transfers, plain treasury transfers). It does not mention idempotency, side effects, or rate limits, but covers the key behavioral aspects sufficiently.

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 at four sentences, each serving a distinct purpose: stating the action, listing prerequisites, detailing verification process, and noting rejection conditions. It is front-loaded with the primary purpose and avoids redundancy, making it efficient for an agent to parse.

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

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

Given the complexity of the tool (settlement with multiple verification steps) and the absence of an output schema, the description is mostly complete. It covers input constraints, prerequisites, and rejection conditions. However, it does not explain what the tool returns (e.g., success/failure indicators) or mention idempotency. This is a minor gap but acceptable since settlement receipts can be retrieved via get_paid_action_receipt.

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

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

All three parameters are described in the schema with 100% coverage. The description adds meaningful context beyond the schema: for txHash, it clarifies 'Plain ERC-20 transfers are not valid production settlement'; for intentId, it specifies it comes from prepare_superblock_purchase or quote_sponsor_reservation with reserve=true; for entitlementId, it notes it is not used for sponsor slots. This adds value beyond the schema definitions.

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

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

The description uses the verb 'settle' with a specific resource 'paid-action reservation' and provides context about the required router transaction. It clearly distinguishes from siblings like prepare_superblock_purchase and quote_sponsor_reservation by referencing them as prerequisites, making the purpose highly 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 states when to use the tool ('after the bound wallet or agent has submitted the required direct PoolParty router transaction') and what conditions must be met (e.g., required API key scope). It also mentions that facilitator token transfers and plain treasury transfers are rejected, which provides negative guidance. However, it does not explicitly state when not to use it or suggest alternative tools.

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

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

With no annotations, the description fully carries the behavioral disclosure. It reveals required API scope, session token dependency, validation of canonicalMediaHandoff before DB access, rate limiting per key, and that wallet is needed for reward claims but not submission. It also notes that scalar-only submit is labeled 'unverified fallback'. This provides comprehensive transparency about side effects and security.

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

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

The description is a single paragraph of moderate length. Every sentence adds unique information, and the flow is logical: purpose, requirements, optional behavior, response details, rate limits, guidance. While slightly dense, it remains focused and avoids redundancy. It is not overly verbose but packs substantial detail.

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

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

Given the tool's complexity (9 parameters, 3 required, no output schema), the description covers all necessary aspects: purpose, prerequisites, parameter relationships (canonicalMediaHandoff validation), idempotency, response fields (media provider, readiness, mintStatus, etc.), and usage guidance. It also mentions rate limiting and wallet requirements. The description is self-contained and provides sufficient context for correct 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%, but the description adds significant value beyond the parameter descriptions. It explains the behavior of canonicalMediaHandoff in relation to videoUrl, playbackId, thumbnailUrl, and duration, and clarifies idempotencyKey mechanism. It also summarizes response fields, which are absent from the schema. This extra context enriches parameter understanding.

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

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

The description clearly states the tool's purpose: 'Submit a media block to a PoolParty channel community queue.' It specifies the verb (submit), resource (media block), and target (channel community queue). It also distinguishes itself by mentioning requirements like API key scope and session token, and references sibling tools like complete_media_upload, providing 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 explicit guidance: 'Requires API key with submit:block scope. Requires a session token from create_join_session.' It also gives pilot guidance ('submit one high-quality block. Do not farm rewards') and explains optional use of canonicalMediaHandoff. However, it does not explicitly state when not to use this tool or mention alternative tools, though the context of sibling tools implies uniqueness.

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

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

With no annotations, the description carries the full burden. It discloses that it is a mutation operation requiring specific auth, and lists what it cannot do. It does not mention response format or immediacy, but provides essential 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: purpose first, then constraints. No redundant words. Every statement is necessary and informative. Excellent front-loading.

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 6 parameters and no output schema, the description covers the tool's purpose, prerequisites, and limitations. It doesn't explain return values or errors, but for an update tool it is sufficiently complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying that empty strings for some parameters mean no change, which is not in the schema. This helps agents avoid overwriting fields unintentionally.

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 'update' and the resource 'channel settings', listing specific fields like name, description, purpose, tags, or operator display name. It is clear, though it does not explicitly distinguish from sibling tools.

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

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

The description specifies required API key scope ('configure:channel') and allowedChannels constraint. It also explicitly states limitations (does not allow status/visibility promotion, program type changes, or economic configuration), guiding when not to use it.

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

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

Describes the action as creating a STAKE_WITHDRAW transaction intent or rehearsal state, and notes visibility through other tools. With no annotations, it carries full burden and does well, but could mention reversibility or side effects.

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

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

Three tight sentences: first for main action and return, second for transaction creation, third for visibility and auth. No wasted words, information front-loaded.

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

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

Covers purpose, return, transaction type, visibility, and auth. Lacks error conditions or explicit guardrails (e.g., 'only before lock'), but overall sufficient for a tool with no output schema.

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

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

Schema coverage is 100%, but description adds value: examples for channelSlug, explanation of agentSessionId for rate-limit identity, and idempotencyKey's purpose. This extra context justifies above baseline 3.

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

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

Description clearly states the action 'Remove active PP0 pooler support' with specific context 'before lock' and return values 'rank and score consequence'. Distinguishes from sibling tools like pool_block by being the inverse 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?

Provides when to use ('before lock', 'eligible block') and prerequisites (wallet-owner approval or funded signer for Amoy). Lacks explicit exclusion of when not to use or comparison to similar tools like finalize_pool_support.

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