PoolParty Main Stage Airtime

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

With no annotations, the description carries full burden. It mentions that it applies a non-mutating proposal and reorders the queue, and requires a scope. However, it does not disclose side effects, whether it replaces or merges the queue, or if it is reversible. More detail 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?

Two concise sentences: first explains purpose and mechanism, second notes required scope. Every sentence adds unique value; 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?

Given no output schema and moderate complexity, the description does not explain the result (e.g., success, new queue state), idempotency, or if 'publish_program_queue' is needed afterward. While schema covers parameters well, broader context is missing.

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

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

Schema coverage is 100%, but the description adds value by explicitly linking 'proposedOrderedItemIds' to the output of 'propose_program_order', providing cross-reference context not in the schema. This enhances understanding beyond the basic schema descriptions.

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

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

The description clearly states the action ('apply'), the resource ('prior non-mutating programming proposal'), and the mechanism ('by reordering the Program Queue'). It distinguishes from sibling tools like 'propose_program_order' and 'reorder_program_queue' by specifying that it applies a prior proposal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 a prerequisite (a prior proposal) but does not explicitly state when to use this tool versus alternatives like directly using 'reorder_program_queue'. No 'when not to use' or alternative tool guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It mentions the required scope and what the tool does not do, but fails to disclose error handling, idempotency, rate limits, or side effects beyond the exclusions. This is insufficient for a mutation tool with 7 parameters.

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

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

Two sentences, front-loaded with the core action, followed by exclusions and scope requirement. No wasted words; efficient and readable.

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

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

Despite 7 parameters and no output schema, the description lacks critical context: no explanation of return values, error handling, confirmation of admission, or what the inventory state looks like after success. Incomplete for the tool's complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minor value by noting the candidate array is capped at 50, but otherwise does not explain parameters beyond what the schema already provides.

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

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

The description clearly states the verb 'admit' and the resource 'candidate inventory', and explicitly distinguishes from what it does not do (create Program Queue items, publish, etc.), making it distinct from siblings like accept_programming_proposal or create_program_item.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 (admit PP2 discovery results to inventory) and lists exclusions, but lacks explicit guidance on when to use versus alternatives, prerequisites, or when not to use.

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

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

With no annotations, the description carries full burden. It declares that the tool does not sign, approve, mint, stake, claim rewards, or move funds—disclosing its limited scope. However, it omits potential side effects like overwriting an existing attached wallet or error conditions (e.g., invalid session), so transparency is good but not exhaustive.

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

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

The description is a single, well-structured paragraph of four sentences. The first sentence states the core purpose, followed by authorization requirement, parameter usage, and limitations. Every sentence earns its place; no fluff.

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

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

With no output schema, the description should cover return values. It does not mention what the tool returns upon success or failure (e.g., confirmation, error message). It explains purpose, prerequisites, and parameter sources but is incomplete regarding the response structure, leaving the agent uncertain about the tool's 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 coverage is 100%, so baseline is 3. The description adds context beyond schema by explaining the source of sessionToken (create_join_session) and agentSessionId (submit/session readbacks), and reiterating that walletAddress is EVM. This adds moderate value, but the schema already documents each parameter adequately.

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

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

The description clearly states the action: attach an EVM wallet address to a submission session. It specifies the resource (same session used for submit automation) and distinguishes itself by explicitly listing what it does NOT do (sign, approve, mint, etc.), which sets it apart from sibling tools that perform those actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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, explains when to use sessionToken vs agentSessionId, and clarifies that the tool only records identity for later prepare_block_mint, not for executing transactions. This tells the agent when to use it and what not to expect.

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

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

With no annotations provided, the description carries the full burden. It explicitly declares 'Read-only. No auth required.', which clarifies safety and access. It also summarizes return fields, adding transparency beyond the schema.

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

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

Two sentences, front-loaded with purpose. Every word adds value: clear verb, filter specification, return summary, and safety note. 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 8 parameters and no output schema, the description lists key return fields (visibility, program type, etc.) and mentions 'whyShown reasons'. It sufficiently covers the tool's purpose but could elaborate on sorting or pagination behavior.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond what is in the parameter descriptions, such as listing default values and allowed ranges. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Browse' with resource 'PoolParty channels' and lists return fields. It clearly distinguishes from siblings like get_channel_feed or resolve_channel by emphasizing discoverability and filtering.

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

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

Explicitly states 'Use this to discover what channels exist and which accept submissions.' This gives clear context, though no when-not or alternative tools 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?

Fully discloses behavior: returns pending/approved/rejected with next steps, does not recover keys, and no auth required. No annotations provided, so description carries full burden, and it meets it well.

Agents need to know what a tool does to the 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 cover purpose, return values, and limitations/auth. No redundancy, each 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?

For a simple status check with one parameter and no output schema, the description is comprehensive: it explains what is returned, what is not, 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 requestId, and schema already describes it as 'The request ID returned by request_pilot_key.' The description adds no additional semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states 'Check the status of a pilot key request' with a specific verb and resource. It distinguishes itself from siblings like request_pilot_key and get_key_info by specifying that it checks status of a request, not returning keys.

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

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

Provides clear context: 'Does not recover raw API keys; auto-provisioned keys are shown only once in the original response' tells the user when not to use this tool. Also states 'Public. No auth required.' However, it does not explicitly name alternative tools for different 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 key behaviors: default mode returns a transaction request without silently funding, local-dev/mock are rehearsal grants, and authentication constraints. This goes beyond the schema to inform the agent about side effects and requirements.

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

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

The description is three sentences, each serving a distinct purpose: general action, default behavior, mode clarifications, and auth context. No wasted words, front-loaded with the main purpose.

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

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

The description covers usage modes, auth, and behavioral traits, which is sufficient for a 3-parameter tool without output schema. However, it does not specify the output format of the transaction request or how to handle it, leaving a minor gap.

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

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

Schema coverage is 100% and each parameter has a clear description. The tool description adds no additional semantic value beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool prepares or records a PP0 test collateral faucet claim for a wallet, specifying different modes (amoy-prepare, local-dev, mock). It is specific and actionable, but does not explicitly contrast with sibling tools like claim_test_pol, which may handle different tokens or modes.

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

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

The description mentions mode options and auth requirements ('no MCP auth required, but wallet-owner approval or agent-owned funded wallet signer needed for Amoy'), which guides when to use. However, it does not explain when to prefer this over alternatives (e.g., claim_test_pol) or provide when-not scenarios.

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

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

With no annotations, the description bears full responsibility. It discloses the default mode (amoy-transfer from PoolParty funder only on PP0/Main Stage) and alternative modes (local-dev and mock return rehearsal grants). It also states 'Public wallet bootstrap action. No MCP auth required.' However, terms like 'bounded' and 'PoolParty funder' are not explained, and side effects (e.g., funder deduction) are not covered.

Agents need to know what a tool does to the 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 four-sentence paragraph that front-loads the core purpose. Every sentence adds value: purpose, usage, mode details, and access. There is no redundancy or waste.

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

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

The description covers usage modes and prerequisites but omits return value details (no output schema). Terms like 'bounded' and 'PoolParty funder' assume domain knowledge. The tool is adequately complete for its intended workflow tie-in but lacks full closure for an agent.

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

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

Schema coverage is 100% with each parameter already described. The description does not add significant meaning beyond the schema; it only restates the wallet address needs gas and channel slug alias. 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's purpose: 'Send or record bounded PP0 test POL for Polygon Amoy gas.' It specifies the verb ('send or record'), resource ('bounded PP0 test POL'), and context ('for Polygon Amoy gas'). The usage context differentiates it from sibling tools by naming specific preceding operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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: 'Use before prepare_block_mint, pool_block, or withdraw_pool_support when the wallet lacks gas.' It also distinguishes modes (amoy-transfer, local-dev, mock). However, it does not explicitly say when not to use or mention alternatives, though the specificity is strong.

Agents often have multiple tools that could apply. Explicit usage 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 that it does not mutate queue/runtime state, explains readiness conditions per provider, and mentions required scopes. Lacks explicit error conditions or rate limits, but covers key behavioral aspects well.

Agents need to know what a tool does to the 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 about 120 words. It covers purpose, prerequisites, provider behavior, and exclusions without redundancy. Could be slightly more structured (e.g., bullet points), but remains concise and front-loads key info.

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

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

Given the tool's complexity (10 parameters, no output schema), the description adequately covers the main points. However, it does not describe the return value or response format, which is important for a completion/check tool. Lacks mention of error handling or pagination. With no output schema, the description should compensate slightly more.

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

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

Schema description coverage is 100%, so parameters are documented. The description adds extra context: explains the role of providerAssetId from request_media_upload_url, clarifies provider inference, and ties sessionToken to create_join_session. This goes beyond the schema to explain inter-parameter relationships.

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

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

Clearly states it completes/checks canonical media readiness after upload. Distinguishes between Livepeer and S3 direct providers, and explicitly says it does not submit a block or mutate queue/runtime state, differentiating it from siblings like 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 explicit prerequisites (API key with submit:block scope, session token from create_join_session), describes when to use (after upload), and explains provider-specific behaviors (Livepeer returns canonical handoff only after conditions, S3 returns only fallback_ready). Also states what it does not do, guiding against misuse.

Agents often have multiple tools that could apply. Explicit usage 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 never attempts SuperBlock purchase, never returns private material, and reports behavior in amoy-prepare mode until finality. It also mentions response redaction for assignedWallet.

Agents need to know what a tool does to the 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 detailed but every sentence adds value, covering purpose, requirements, exclusions, and edge cases. It is front-loaded and well-structured 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 complexity (8 parameters, no output schema, many siblings), the description covers authorization, environment setup, preconditions, non-behaviors, and special modes adequately. No output schema exists, so return information is not required.

Complex tools with many parameters or behaviors need more documentation. 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 what the schema already provides for each parameter; it only provides context about blockId discovery and channel limitation, which are already in 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 completes a tightly gated local/dev PP0 economic pool/back proof with a configured SIM signer alias. It distinguishes from sibling tools like pool_block or withdraw_pool_support by specifying it completes a proof after pooling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 details prerequisites: authorization scope, environment flag, channel, and blockId source. It also notes that public auto-provisioned keys cannot run this. It implicitly differentiates from alternatives by describing its specific role, but does not explicitly list when-not to use or name sibling 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 full burden. It correctly implies a mutation ('Update', 'toggle'), states scope and channel requirement, but lacks details on side effects, reversibility, idempotency, or error conditions. Adequate but not rich.

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

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

Three concise sentences: purpose, list of updateable areas, and requirements. No redundant words, front-loaded with the action. Efficient and clear.

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

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

Given 12 parameters and no output schema, the description covers the purpose, prerequisites, and parameter topics. It lacks mention of what the tool returns (e.g., success response) but is generally sufficient for a configuration tool in this context.

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

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

Schema coverage is 100% with individual descriptions. The description adds value by grouping related parameters into conceptual categories (QR card copy, community slot titles, submission theme, toggle), making it easier for an agent to understand which parameters serve which purpose.

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

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

The description clearly states the verb ('Configure'/'Update'), the resource ('open-call / submission guidance for a channel with a community slot'), and the specific fields it affects (QR card copy, community slot titles, submission theme, toggle submissions). It distinguishes from sibling tools like `get_open_submission_calls` (read) and `update_channel_settings` (different scope).

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

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

The description explicitly states prerequisites: requires API key with `configure:channel` scope and channel must have a `community_slot`. It does not mention when *not* to use or suggest alternatives like `get_open_submission_calls` for inspection, but the provided 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 adequately discloses: required API scope, created objects (channel + program + starter blocks), state (ACTIVE_UNLISTED), discoverability (not until admin promotes), and rate limit (3/hr). Minor omissions like error behavior are 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?

Very concise: three sentences, front-loaded with the main action. No fluff; every sentence earns its place by providing essential operational details.

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

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

For a creation tool with 7 params, no output schema, and no annotations, the description covers key constraints (scope, state, discoverability, rate limit). Missing return value info is acceptable given no output schema. Coule add error cases, but overall sufficient.

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

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

Schema description coverage is 100%, so baseline is 3. The main description does not add parameter-specific semantics beyond the schema, but the schema is already detailed. The additional context about rate limiting is behavioral, not parameter-level.

Input schemas describe structure but not intent. Descriptions should explain 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 a channel from a template blueper, specifying the verb 'create' and the resource 'channel from template'. Distinguishes from siblings like list_channel_templates and update_channel_settings by focusing on blueprint-based creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 to use list_channel_templates and preview_channel_template first, providing a clear prerequisite sequence. Lacks explicit 'when not to use' but gives sufficient context for proper usage.

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

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

No annotations exist, so description carries full burden. It discloses session limits, token usage, and that wallet is optional for submission. Lacks details on session expiration or creation behavior.

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

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

Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.

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

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

Given single parameter and no output schema, description explains purpose, return value, preconditions, and limits. Could mention session lifetime or error handling, but overall sufficient.

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

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

Schema has 100% coverage with description for channelSlug. The description adds extra meaning: 'Must have participation enabled' and example 'pp1'. Adds value beyond schema.

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

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

Clearly states the verb 'create', resource 'anonymous participation session', and its purpose to allow submissions via submit_media_block. This differentiates it from siblings like 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 preconditions (API key scope), limits (3 anonymous submissions), and clarifies wallet usage. Does not explicitly state when not to use it, 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?

Without annotations, the description carries full burden. It discloses the required scope and that an audit event is recorded. It does not describe destructive nature or return behavior, which is a minor gap.

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

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

Two sentences, no superfluous information. Front-loaded with the core action, then scope and side effect. Every sentence adds value.

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

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

Given no output schema and 6 parameters, the description explains purpose and side effects but omits what the tool returns (e.g., created item ID) or error conditions. Adequate but incomplete.

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

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

Input schema has 100% description coverage for all 6 parameters. The description does not add any additional meaning or context beyond the schema, so baseline score of 3 applies.

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

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

The description clearly states the action: 'Promote a source candidate into the editable Program Queue.' It uses a specific verb and resource, distinguishing it from sibling tools like accept_programming_proposal or admit_programming_candidates.

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

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

The description provides a prerequisite (write:program_queue scope) but no explicit guidance on when to use this tool versus alternatives like admit_programming_candidates or propose_program_order. Usage context is implied but not differentiated.

Agents often have multiple tools that could apply. Explicit usage 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 scope requirement, draft behavior, and replaceDraft pruning behavior. Misses details on idempotency or error handling, but overall provides sufficient behavioral insight.

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

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

Two sentences without extraneous info. First sentence defines action and behavior, second covers scope and limitation. Every sentence is essential and front-loaded.

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

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

No output schema and missing return value description. While key behaviors are covered, the description could mention what the tool returns (e.g., draft ID) and potential error conditions. Adequate but not fully complete.

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

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

Schema has full coverage (100%), but description adds context: items are ordered, replaceDraft prunes stale items, and it creates/reuses items. This semantic enrichment justifies 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?

Description clearly states the tool saves an ordered PP2 Program Queue draft from candidate IDs, specifying the resource and action. It distinguishes from sibling tools like publish_program_queue and list_program_queue by emphasizing it does not publish or mutate the live queue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 mentions required scope and explicitly states what the tool does not do (does not publish or mutate live queue), helping differentiate. However, it lacks explicit 'when to use' or alternative recommendations, leaving some ambiguity.

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

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

With no annotations, the description fully discloses behavioral traits: draft-only, requires review, no auth required, and explicitly lists operations it does not perform. It also mentions the return of a previewUrl. This is comprehensive for a draft tool.

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

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

Two sentences, front-loaded with purpose, followed by essential limitations. No redundancies; every word serves a purpose. Efficient and clear.

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

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

For a tool with 14 parameters and no output schema, the description covers the core purpose, return value (previewUrl), and boundaries. It does not detail all parameter interactions but the schema provides that. Missing error handling details, but acceptable for a draft operation.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context about the types of input (proof, commands, claims) but does not enhance meaning beyond the schema descriptions. No additional parameter-specific guidance is provided.

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

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

Clearly states the action ('Draft') and the resource ('SlideBlock/Proof Block package'). Specifies inputs from 'project proof, commands, screenshots, claims, or rough demo notes'. Distinguishes from siblings like 'revise_slide_block' by emphasizing it's draft-only and listing what it does not do.

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

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

Explicitly states when to use (for drafting) and when not to use (does not submit, bypass moderation, mint, collateralize, or insert blocks). Provides clear context that operator review is required, which guides the agent to select this for preliminary creation rather than final 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?

Discloses all major actions (verifying receipt, parsing event, writing multiple rows, reporting eligibility) and states public accessibility. Lacks details on error handling or idempotency, but given no annotations, it provides good coverage.

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

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

Two sentences with front-loaded purpose and a list of steps. Concise but the first sentence is dense; still efficient with no superfluous 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?

No output schema exists, and the description fails to explain what the tool returns (e.g., pool eligibility report, success status, error states). This is a significant gap for agent invocation.

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

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

Schema coverage is 100% with clear descriptions for all parameters. The description adds minimal extra meaning beyond mentioning the optionality of txIntentId. Baseline 3 is appropriate.

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

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

The description uses a specific verb "Finalize" and resource "canonical PP0 block NFT minting", and distinguishes from the sibling 'prepare_block_mint' by referencing the wallet broadcast and subsequent steps.

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

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

Clearly states when to use (after wallet broadcasts mintBlock) and provides context about auth requirements and the non-role of x402 payment. Does not explicitly list alternatives or when not to use, but the context is sufficient.

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

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

With no annotations provided, the description fully carries the burden. It discloses verification steps (receipt, sender, block, amount, contract), state writes (canonical PoolParty support state, rank/score fields), and return value (withdrawal/readback next actions). It also explicitly states what the tool does NOT do ('x402 payment is not pool support finality'). No annotation contradiction.

Agents need to know what a tool does to the 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 four sentences, each earning its place: purpose, verification steps, metadata (public/no auth), and a clarifying disclaimer. No fluff or repetition. Properly front-loaded with the verb and resource.

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

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

All parameters are documented in schema. The description explains the high-level workflow and return actions, though lacks explicit return format details. Given the absence of an output schema, the description provides sufficient context for the agent to understand the tool's role in the pooling lifecycle.

Complex tools with many parameters or behaviors need more documentation. 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 beyond schema by clarifying constraints: txIntentId optional with latest-pending fallback, walletAddress must match intent and receipt. It also implies that txHash is a Polygon Amoy tx and blockId is database-specific, which the schema already covers. Overall, adds moderate contextual nuance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'finalize' and resource 'pool support', distinguishing it from sibling tools like 'pool_block' (prepare) and 'withdraw_pool_support' (withdraw). It specifies the trigger (after broadcasting poolIntoBlock or creator-collateral support) and scope (PP0 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 clear timing ('after the wallet broadcasts...') and states it's a public wallet action with no MCP auth required. While it doesn't explicitly list when not to use or name alternatives, the context implies usage after preparation but before withdrawal. The sibling list includes relevant prep and withdrawal 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 the full burden. It discloses that the tool is read-only and requires no authentication, which is key behavioral information. It also lists the return fields. However, it does not mention potential rate limits, data freshness, or any side effects, which would enhance transparency.

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

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

The description is extremely concise: two sentences. The first sentence states the purpose, and the second enumerates the return fields. 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?

Given the tool has one parameter and no output schema, the description lists the return fields (score, recommendation, competition, reward, reasons) but does not explain how to interpret the recommendation or competition level. This is a minor gap, but overall it's fairly complete for a simple evaluation tool.

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

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

Schema description coverage is 100% for the single parameter channelSlug, with the schema already describing 'The channel slug (e.g., 'pp1').' The tool description does not add additional meaning beyond the schema, 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 'Evaluate whether a PoolParty channel is a good airtime opportunity right now.' It specifies the verb (evaluate), resource (PoolParty channel), and scope (airtime opportunity), which distinguishes it from sibling tools that evaluate other types of opportunities (collateral, reward, sponsor).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 when to use: to evaluate airtime opportunities. It explicitly notes 'Read-only. No auth required.', which sets expectations. However, it does not mention when not to use or explicitly contrast with sibling tools like get_collateral_opportunity or get_reward_opportunities, leaving some inference required.

Agents often have multiple tools that could apply. Explicit usage 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 covers key behavioral traits: it is a read operation ('Public read'), requires no auth, and does not promise rewards. The list of returned data provides transparency on what to expect.

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

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

The description is a single sentence that front-loads the core purpose, though the list of returned items is somewhat lengthy. It is concise and efficient overall.

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

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

With no output schema, the description details the return types adequately. It covers the essential context for using the tool, though it omits error handling or edge cases.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by mentioning 'PP0' and 'pooling or airing', providing context beyond the schema's parameter descriptions.

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

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

The description clearly states the action ('Read') and resource ('PP0 block economics'), and specifies the context ('after pooling or airing'). It distinguishes itself from siblings by focusing on block economics specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 when to use the tool ('after pooling or airing') and notes that it is public and requires no auth. It does not explicitly exclude alternatives, but the context is sufficient for most agents.

Agents often have multiple tools that could apply. Explicit usage 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, public, and lists return fields including 'next actions'. It adds behavioral context beyond parameter/schema, though it could mention data freshness or rate limits.

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

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

Two succinct sentences: first states purpose and statuses, second lists return fields and access. Every sentence adds value with no filler.

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

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

For a simple read tool lacking an output schema, the description adequately covers purpose, parameters, output format, and access. It could be more thorough on error conditions or status interpretations, 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?

The input schema has 100% coverage with descriptive parameter descriptions. The tool description adds meaning by explaining the return includes fields like on-chain id and next actions, which enhances semantic understanding beyond the schema alone.

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

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

The description clearly states the verb 'Read' and the resource 'canonical mint status for a PP0 media block', listing possible status values and included fields. It distinguishes itself from write siblings like prepare_block_mint and 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?

The description explicitly states 'Public read. No auth required.', indicating when to use this tool. It implies it should be used to check mint status rather than performing actions, but lacks explicit exclusions or alternative tool guidance.

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

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

With no annotations, the description carries the full burden. It correctly declares 'Read-only. No auth required.' and mentions the return includes 'safe defaults, agent constraints, runtime behavior, and example usage', which is transparent for a getter tool.

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

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

The description is three sentences, each adding value: purpose, return content, and security characteristics. No fluff; front-loaded with the action.

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

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

Given the tool is a simple getter with one parameter and no output schema, the description adequately covers what the tool returns. It could specify more about format or real-time behavior, but overall it's complete.

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

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

Schema coverage is 100% with a clear description and examples for the 'blockType' parameter. The tool description does not add significant meaning beyond the schema, meeting the baseline expectation.

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

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

The description clearly states 'Get detailed schema for a block type', specifying the action (get) and resource (block type schema). It implicitly distinguishes from sibling 'list_block_types' which lists block types without details.

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

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

The description provides context by stating 'Read-only. No auth required.', but does not explicitly guide when to use this tool versus alternatives like 'list_block_types'. Usage is implied rather than clearly delimited.

Agents often have multiple tools that could apply. Explicit usage 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 behavioral transparency. It states 'Read-only. No auth required' and notes that the feed 'may be large,' helping the agent anticipate performance and 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 concise paragraphs: first describes output, second gives usage guidance. Every sentence provides valuable 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 3 parameters, no output schema, and high complexity, the description is exceptionally complete. It covers what the tool does, what it returns, when to use it, and when to use alternatives.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context beyond the schema by explaining that the feed is 'rich' and 'may be large,' and it clarifies the purpose of the parameters in relation to the returned data.

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

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

The description clearly states it retrieves 'rich recent airings and current queue evidence' and details the specific fields returned (title, media type, timestamps, proof-of-play, reward status, mintStatus, poolEligibility). It also distinguishes from sibling tools like get_channel_stream and REST endpoints.

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

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

Explicitly says to use for 'diagnostic recent airing and queue evidence' and provides alternatives: 'For first-pass channel awareness, use get_channel_stream(channelSlug="main", limit=10) or the REST /api/channels/main/activity snapshot; use /api/channels/main/activity/stream when an SSE watch is intended.'

Agents often have multiple tools that could apply. Explicit usage 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 it is read-only and requires no authentication, which is critical behavioral info. It also describes measurement status handling and return contents, adding transparency beyond what annotations (none provided) would offer.

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

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

The description is concise, front-loaded with the main action, 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 the lack of an output schema, the description provides a comprehensive list of returned metrics, including freshness, queue depth, submissions, and reward info. It also covers read-only and auth requirements, making it complete for a single-parameter tool.

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

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

Schema coverage is 100% with one parameter (channelSlug) already described. The tool description adds minimal context ('PoolParty channel'), but this does not significantly enhance understanding beyond the schema's 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 it retrieves Channel Pulse v2 metrics for a PoolParty channel, with a specific verb and resource. The detail on included metrics distinguishes it from sibling tools like get_channel_feed or get_channel_stream.

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

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

The description does not explicitly state when to use this tool versus alternatives. While the purpose is clear, there is no guidance on exclusions or comparison to related tools, leaving the agent to infer.

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

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

Description mentions read-only and no auth, which are behavioral traits beyond schema, but no annotations are provided. The description could add more about error handling or limitations. 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?

Two sentences, informative, front-loaded with key information. Every word earns its place; 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?

No output schema, but description lists return categories (channel status, now playing, queue summary, etc.) which suffices for a compact read tool. With low complexity (2 params, no nested objects), the description is complete enough.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional semantics beyond what the schema provides (limit defaults, channelSlug format). Baseline 3 is appropriate.

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

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

The description clearly states it returns 'compact first-read current channel state' and lists specific data categories. It distinguishes from sibling 'get_channel_feed' by saying 'prefer this before rich get_channel_feed', making its purpose distinct.

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

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

Explicitly says 'prefer this before rich get_channel_feed', indicating when to use. Also states 'Read-only. No auth required.' which helps. However, no explicit when-not or additional context for other alternatives.

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

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

No annotations are provided, so the description carries full burden. It discloses that the operation is a public read with no authentication needed, which is informative. Additional context about potential rate limits or data freshness would improve transparency, but the current level is adequate.

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

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

The description is only two sentences. The first sentence concisely states the function and return items, and the second adds essential usage context. Every sentence earns its place with no redundancy.

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

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

Given the tool is a simple read with one parameter and no output schema, the description provides a comprehensive list of returned fields and states it is public. It could mention that the output contains all listed fields, but overall it is complete for the tool's simplicity.

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

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

The input schema fully describes the single required parameter 'channelSlug' with examples. The description does not add extra 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 reads a collateralized block opportunity and lists the returned fields. However, it specifies 'PP0 Main Stage' which may be a specific instance; the parameter 'channelSlug' allows other values, so the description could be misleading about generality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'Public read. No auth required.' which helps decide when to use. However, it does not provide guidance on when not to use this tool versus similar tools like get_airtime_opportunity or get_reward_opportunities.

Agents often have multiple tools that could apply. Explicit usage 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. Explicitly states 'Read-only' and 'No auth required', disclosing non-destructive nature and access requirements. Lists report contents. Does not mention rate limits or pagination, but sufficient for a read-only report.

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

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

Two sentences: first states purpose and output, second gives parameter instructions. Front-loaded with key information, no redundant words. Every sentence earns its place.

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

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

With 5 parameters and no output schema, description covers all aspects: what the report shows, which parameters to use for each context, and the read-only nature. Complete enough for correct invocation without relying on 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% with descriptions. Description adds value by grouping parameters by use case (community vs superblock) and referencing previous API responses (submit_media_block, prepare_superblock_purchase). Goes beyond schema to clarify parameter semantics.

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

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

Description clearly states verb 'Get' and resource 'distribution report' for specific entities: media block or superblock reservation. Lists detailed output fields (entry status, block state, etc.), distinguishing it from sibling tools like get_block_economics or get_channel_metrics.

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

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

Explicitly instructs which parameters to provide for community submissions (entryId/blockId) vs superblock reservations (entitlementId/purchaseId). States 'Read-only' and 'No auth required', indicating safe usage. Lacks explicit when-not-to-use or alternatives, but the guidance is clear for common scenarios.

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

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

With no annotations, the description fully carries the burden. It discloses that the tool is a read operation, requires auth, and does not expose the raw key. The return fields are listed, but no further behavioral details (e.g., rate limits) are given, which is acceptable for a simple read.

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

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

The description is two sentences with no extraneous words, front-loading the key action and immediately listing outputs. 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 zero parameters, no output schema, and straightforward behavior, the description completely covers the tool's purpose, inputs, security implications, and outputs.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds meaning about the tool's purpose and return values, compensating for no parameter documentation.

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

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

The description specifies the tool inspects the current MCP Bearer token without exposing the raw key, listing the exact return fields. It clearly distinguishes itself from sibling tools that operate on different 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 states it's a protected read requiring auth and no write scope, providing clear context for when to use it. It does not mention alternatives, but no sibling tool performs the same function.

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

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

Discloses critical behavioral traits: 'Read-only. No auth required,' which is essential given no annotations are provided. Does not mention rate limits or pagination, but the main safety and access characteristics are covered.

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

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

The description is concise and front-loaded: the first sentence states the core purpose. Each sentence adds value, 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?

Given the tool has 1 optional parameter and no output schema, the description thoroughly explains the return values (submission guidance, accepted media types, reward eligibility, queue depth, median time to air, step-by-step instructions) and usage context, making it 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% (the parameter 'channelSlug' already described in the schema). The tool description adds no additional meaning beyond what the schema provides, meeting the baseline for full coverage.

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

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

Clearly states 'Find channels accepting community submissions' with a specific verb and resource, and lists the detailed information returned (submission guidance, accepted media types, reward eligibility, etc.), distinguishing it 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?

Explicitly says 'Use this to decide where to submit content,' providing clear context for when to invoke the tool. Does not explicitly mention when not to use alternatives, but the guidance is sufficient.

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

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

No annotations are provided, so the description carries full burden. It discloses that receipts expose intent state, settlement info, etc., and notes that sponsor receipts omit private fields. This provides good 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 extremely concise with only two sentences, no redundant information, and front-loaded with the essential purpose.

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

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

Given the tool has one parameter and no output schema, the description is complete. It explains what the receipt contains, special handling for sponsor receipts, and the required scope.

Complex tools with many parameters or behaviors need more documentation. 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 is only one parameter with 100% schema coverage. The schema already describes the parameter well, listing where the ID comes from. The description does not add 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?

The description clearly states the verb 'Get' and the resource 'PoolParty receipt for a paid action intent', specifying the exact context. It distinguishes itself from sibling tools like get_pooling_receipt by focusing on paid action receipts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 includes a prerequisite (API key scope) and implies usage after paid action intents. It does not explicitly list when not to use or alternatives, but the context is clear enough 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 carries full burden. It declares read-only and no auth, which is good, but lacks details on data freshness, caching, or rate limits. The return value is described vaguely without specifying structure or optionality.

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

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

Two sentences, front-loaded with purpose, no redundant words. Every sentence contributes essential information.

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

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

For a simple read-only tool with no parameters and no output schema, the description adequately covers purpose, return items, and authentication. Slightly more detail on data freshness or typical use case would elevate it.

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

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

No parameters exist, so baseline is 4. The description adds value by specifying the tool's output and behavior beyond the empty schema.

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

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

The description clearly states it provides a high-level summary of platform activity, listing specific data types (active channels, blocks aired, submissions, reward campaigns). This distinguishes it from sibling tools that target specific metrics or actions.

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

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

No explicit guidance on when to use this tool versus alternatives. While it mentions read-only and no auth required, it does not compare it to other read tools like get_channel_metrics or get_block_economics.

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

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

The description states 'Public read. No auth required' and enumerates return fields, including 'explicit mock/local/amoy truth labels', which adds transparency. However, it does not discuss error conditions, rate limits, or potential side effects (though likely none). Given no annotations, this is adequate but not exceptional.

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

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

The description is front-loaded with the main purpose and efficiently lists return fields in a compact list. The extra sentence 'Public read. No auth required' is concise and useful. Minor improvement would be to break the long sentence listing return values.

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

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

Given no output schema, the description adequately explains return values (wallet, block, amount, lifecycle state, etc.) and environment labels. For a simple read tool with two required parameters, this is sufficiently complete to inform an agent.

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

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

With 100% schema description coverage, the baseline is 3. The tool description adds no additional parameter meaning beyond what the schema already provides (e.g., positionId and channelSlug descriptions are identical to 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 uses specific verb ('Read') and explicit resource ('derived PP0 pooling receipt for a pool position'), and clearly distinguishes the tool's return values and environment labels. It is unambiguous and differentiated from sibling get_* tools by its unique focus on pooling receipts.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., get_wallet_pooling_state, get_block_economics). The description does not mention prerequisites, exclusions, or use cases where this tool would be inappropriate.

Agents often have multiple tools that could apply. Explicit usage 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 declares 'Read-only' and 'No auth required', indicating no side effects. Could mention error handling for invalid modeId, but overall transparent for a simple get 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 sentences: first states purpose and lists contents, second adds behavioral qualifiers. No extra 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?

For a simple get tool with one parameter and no output schema, the description adequately explains what the manifest includes. Could mention response format, but it's not critical given the low complexity.

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

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

Schema coverage is 100% with description already providing example values. Tool description does not add new meaning beyond the schema's parameter description, 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?

Description clearly states verb 'Get', resource 'detailed manifest for a program mode', and lists specific contents (block types, actions, options, templates). It distinguishes itself from sibling tools like list_program_modes or get_block_type_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?

States when to use (read-only manifest retrieval) and conditions ('No auth required'), but does not explicitly mention when not to use or provide direct alternatives. The usage context is implied sufficiently.

Agents often have multiple tools that could apply. Explicit usage 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 explicitly states 'Read-only. No auth required' and details return information, fully covering 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?

Two concise, front-loaded sentences with no unnecessary words.

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

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

Despite no output schema, the description lists specific return fields (reward amount, pool remaining, etc.), making the tool's functionality complete for a no-parameter 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 tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description adds no parameter info, which is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 with active reward pools' and lists specific return fields, distinguishing it from sibling tools like get_collateral_opportunity or get_airtime_opportunity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the use case: 'Use this to find where submissions can earn rewards.' It doesn't explicitly exclude alternatives, but the purpose is clear given the sibling tool names.

Agents often have multiple tools that could apply. Explicit usage 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 'Public read. No auth required. Does not mutate state.' and details what is redacted and not exposed. This fully discloses behavioral traits beyond the absence of annotations.

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

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

The description is a single paragraph that front-loads the main purpose and lists returns and safety guarantees. It is efficient with no fluff, though slightly longer than strictly necessary.

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

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

Given no annotations and no output schema, the description provides sufficient context for an agent: purpose, return elements, safety, and parameter hints. However, it does not detail the exact output structure, which could be inferred.

Complex tools with many parameters or behaviors need more documentation. 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% parameter description coverage, so the schema already documents the two optional parameters. The tool description does not add additional semantic information about the parameters beyond what is in the schema.

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

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

The description clearly states the verb 'Read' and the resource 'safe SIM signer availability' for a specific context 'local/dev PP0 economic rehearsal'. It lists the return elements and what is not exposed, distinguishing it from siblings like get_airtime_opportunity or get_block_economics.

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

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

The description implies usage for reading SIM signer availability in local/dev PP0 economic rehearsal but does not explicitly state when-not-to-use or compare to alternatives. No exclusion criteria or alternative tool references are provided.

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

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

No annotations provided, so description carries full burden. It explicitly states 'Read-only. No auth required,' which clearly indicates non-destructive, safe behavior. Additional behavioral details (rate limits, destruction) are not needed given the tool's nature.

Agents need to know what a tool does to the 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: purpose and returns, usage hint, behavioral note. Front-loaded and concise with 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?

Covers purpose, return content, usage condition, and safety. Missing details about return structure or potential filters, but with zero parameters and no output schema, the description provides sufficient context for an agent to understand the tool's capability.

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

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

Input schema has zero parameters, so no additional semantics needed. The baseline for 0 params is 4, and the description does not need to add parameter 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 it finds available sponsor and Superblock airtime inventory and lists the returned elements (tiers, prices, durations, availability, slots). It distinguishes its purpose from generic tools but does not explicitly differentiate from sibling tools like get_superblock_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?

Provides usage context: 'Use this to find configured scarce-airtime reservations when offerings are active.' Missing explicit when-not-to-use or alternative tool references, so guidance is somewhat implied.

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

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

No annotations provided, so description bears full burden. Clearly states read-only behavior, no authentication needed, and that offerings only exist when active. Adds context about what Superblocks do and their limitations.

Agents need to know what a tool does to the 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: first describes functionality, second adds behavioral context, third clarifies read-only and auth. No waste, front-loaded with key info.

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

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

Completely covers purpose, return content (prices, durations, inventory), and behavioral context. No output schema needed; description is self-sufficient for a simple listing tool.

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

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

No parameters exist (0 params, 100% schema coverage). Baseline 4 applies as description need not add parameter 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?

Description clearly states 'List available Superblock offerings with prices, durations, and current inventory.' Uses specific verb (List) and resource (Superblock offerings), distinguishing it from sibling tools like get_airtime_opportunity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 Superblock offerings are active and clarifies limitations ('do not guarantee audience size or reward outcome'). Declares read-only and no auth required, but does not explicitly mention when not to use or alternatives.

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

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

Description indicates it's a read operation with no auth required, and lists returned fields. However, no annotations are provided, and the description does not disclose rate limits, error conditions, or any behavioral traits beyond being a read. Adequate but minimal.

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

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

Description is a single sentence that efficiently lists all returned data. Could be slightly more structured, but no redundant information. Front-loads the action ('Read') and access level.

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

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

Given no output schema, the description enumerates all major return fields (positions, amounts, policy, context, etc.), which sufficiently informs the agent of what to expect. Lacks edge case info but is complete for a straightforward read operation.

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

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

Schema describes both parameters with examples, and coverage is 100%. The description does not add new 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?

Clearly states 'Read a wallet PP0 pooling state' with specific verb 'Read' and resource 'wallet PP0 pooling state'. Distinguishes from sibling tools by focusing on wallet pooling state, which is a specific domain concept.

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

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

No guidance on when to use this tool versus alternatives like other get_* tools. Only mentions 'Public read. No auth required.' which is more about access than 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, the description carries full burden and discloses the required scope (write:live_queue) and side effect (records audit event). However, it does not mention idempotency, error conditions, or return value behavior, which could be useful for an insertion 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 action, and contains no redundant or superfluous information. Every word adds value.

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

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

For a simple insertion tool with 3 params and no output schema, the description covers purpose, auth requirement, and side effect. It could mention preconditions (e.g., whether the programItemId must exist) or postconditions, but overall 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 coverage is 100% with all parameters described. The description adds no additional parameter-level information beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Insert', the resource 'Program Queue item', and the specific location 'at the front of the live queue'. This distinguishes it from sibling tools like remove_live_queue_item or skip_current_live_item.

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

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

The description implies when to use (to insert at front of live queue) but does not explicitly state when not to use or compare with alternatives such as reorder_program_queue or list_live_queue. No guidance on prerequisites or conditions.

Agents often have multiple tools that could apply. Explicit usage 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 only indicates read intent via 'Inspect' and scope requirement. It does not disclose side effects, return size, or safety guarantees. More behavioral context is needed.

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

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

Two short sentences, front-loaded with the core action and followed by a scope requirement. 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?

Adequate for a simple tool with one parameter, but lacks output schema or return value description. Could improve by hinting at what fields are inspected.

Complex tools with many parameters or behaviors need more documentation. 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 clear description for channelSlug. The description adds no extra meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states the verb 'inspect' and the resource 'channel programming policy', covering source, approval, audit, and MCP-scope. It distinguishes from sibling tools like list_programming_buckets, though not explicitly naming alternatives.

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

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

Provides the required scope ('read:program_queue') which is a key prerequisite, but lacks guidance on when to use this tool versus other inspection or list tools. No when-not or alternative references.

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

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

With no annotations provided, the description carries the full burden. It declares the tool is read-only, requiring specific scope. It lists reported aspects but does not detail pagination behavior or cursor usage, though 'cursor availability' is mentioned. Transparency is good for a non-destructive 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 concise, consisting of two sentences. The first sentence front-loads the action and scope, and the second lists key features. Every word is informative with no wasted space.

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

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

Given 14 parameters and no output schema, the description covers the tool's purpose, required scope, and what it reports. It lacks guidance on output format or pagination, but it is largely complete for a complex 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?

Schema coverage is 100%, so baseline is 3. The description does not elaborate on individual parameters beyond the schema descriptions, but it frames the overall purpose. It adds some context via the list of reported items, but no parameter-specific enrichment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 runs a read-only PP2 discovery inventory audit across source queries, listing specific report outputs like upstream counts and exclusions. This distinguishes it from siblings like 'inspect_channel_programming_policy' and 'list_programming_candidates'.

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

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

The description provides clear context: it's a read-only audit requiring 'read:program_queue' scope. However, it does not explicitly state when to use this versus alternatives like 'list_programming_candidates', nor does it mention 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 provided, the description carries full burden. It declares read-only behavior and no auth requirement, but lacks details on pagination, ordering, 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?

Two concise sentences: the first states purpose and lists return types, the second adds behavioral notes. Front-loaded, no wasted words.

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

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

Given no output schema, the description hints at return structure (types with descriptions and supported modes). Lacks pagination details but sufficient for a simple listing tool.

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

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

Schema coverage is 100%, and the description's parameter mention ('Filter to block types supported by this program mode') closely mirrors the schema description, adding no new semantics beyond the schema.

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

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

The description clearly identifies the tool as listing PoolParty block types, enumerating specific types (media, notice, etc.) and stating it provides descriptions and supported modes. This distinguishes it from sibling list 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 states 'Read-only. No auth required,' implying safe usage anytime, but does not explicitly mention when to avoid or alternatives like get_block_type_schema.

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

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

Discloses read-only nature and no auth requirements beyond what annotations would provide. Adds behavioral context about return contents and current limitation.

Agents need to know what a tool does to the 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, front-loaded with key purpose. Slightly repetitive about what it returns, but 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?

Tool has low complexity (1 parameter, no output schema); description covers purpose, return contents, limitation, and authentication, making it fully informative.

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

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

Schema coverage is 100% with parameter description; description does not add extra meaning beyond the schema (e.g., defaults or usage hints).

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

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

Clearly states 'List available channel creation templates' with specific verb and resource. Distinguishes from sibling tool preview_channel_template by name.

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

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

Explicitly notes that channel creation is not yet available and directs user to preview_channel_template as alternative. Provides clear when-to-use guidance.

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

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

The description implies a read-only operation ('inspect') and states the required scope, but lacks details on response structure, pagination, or any side effects. With no annotations, more behavioral context would be helpful.

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

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

Two concise sentences, front-loaded with the core purpose. Every word earns its place with no redundancy.

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

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

Lacks description of return values (no output schema), and does not differentiate from sibling tools like 'list_program_queue' or 'insert_live_next'. Given the presence of many related queue tools, this omission limits completeness.

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

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

Schema description coverage is 100% and includes an example for channelSlug. The description adds no further semantic value beyond the schema, meeting the baseline adequately.

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

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

The description clearly states the action ('inspect') and resource ('current live queue projection for a channel'), which is specific and distinguishes it from sibling tools like 'list_program_queue' or 'insert_live_next'.

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

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

No guidance on when to use this tool versus alternatives. It mentions a required scope but does not provide comparative context or usage scenarios relative to sibling tools.

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

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

No annotations are provided, so the description must cover behavioral traits. It indicates a read operation via 'inspect' and requires scope, but lacks detail on side effects, rate limits, idempotency, or what happens if the channel slug is invalid. Basic transparency but not comprehensive.

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

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

The description is two concise sentences: first states purpose, second states scope requirement. No redundant information; every word adds value.

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

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

For a simple tool with one parameter and no output schema, the description covers the purpose and requirement. It mentions 'including unbucketed items' which adds useful context. However, it does not describe the response format or clarify if channelSlug is strictly 'pp2' or any slug. Slight gaps but adequate.

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

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

The schema has 100% coverage with a description for channelSlug. The tool description adds no additional semantics beyond the schema, merely echoing the example 'pp2'. Baseline 3 is appropriate.

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

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

The description clearly states it inspects persistent PP2 programming buckets grouped from Program Queue bucket labels, including unbucketed items. It specifies the action (inspect) and resource (programming buckets) and distinguishes from siblings like list_program_queue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the required scope but does not provide explicit guidance on when to use this tool versus alternatives. Context is implied (reviewing buckets) but no when-not-to-use or comparisons with sibling tools.

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

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

No annotations are provided, so the description should fully disclose behavior. It mentions the tool returns metadata, renderability, previews, and links, but lacks details on pagination, data freshness, or the nature of the operation (read-only is implied but not stated). The scope requirement is the only behavioral hint.

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

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

Two sentences, both front-loaded with essential purpose and requirement. No wasted words. 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?

No output schema exists, so the description should describe the return value. It mentions what is included (metadata, renderability, previews, links) but does not specify that it returns a list, pagination behavior, or any schema or structure. Parameter documentation in schema is strong, but overall context is adequate but not thorough.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the input schema already provides for parameters like limit, statuses, mediaTypes, etc. No param-specific enrichment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 inspects programming candidate inventory with specific details (source metadata, renderability, previews, Program Queue links). It distinguishes from siblings like list_program_queue (which is a simple list) and inspect_programming_discovery_inventory (which is for discovery).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the required scope (read:program_queue) but does not specify when to use this tool versus alternatives like list_program_queue or inspect_programming_discovery_inventory. No explicit exclusions or context for selection.

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

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

No annotations are provided, so the description carries full burden. It declares 'public read', implying no side effects, and describes the nature of profiles (separation of authority, not auto-provisioned). This adds valuable behavioral context beyond a simple listing.

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

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

The description is a single, well-structured sentence that front-loads the main action and includes essential details without 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 one optional parameter, no output schema, and no annotations, the description provides sufficient information: what it lists, when to use, and read-only nature. It could mention response format but is adequate for a simple list tool.

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

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

Schema description coverage is 100%, and the parameter description already includes the default value. The tool description does not add additional 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 'list' and the resource 'programming scope profiles', and provides context 'before requesting a pilot key'. It distinguishes from sibling tools by describing what the profiles do (separate authority) and that they are conservative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 to use this tool before requesting a pilot key, and notes it is public read. While it doesn't list alternatives or when not to use, it provides 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?

No annotations, but description declares 'Read-only' and 'No auth required', clearly disclosing the tool's safety and access profile. Also describes the return content type. This adds value beyond the schema.

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

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

Two sentences concisely cover purpose, return items, and behavioral traits. No redundant information; every word adds value.

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

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

Given the simple parameter and no output schema, the description adequately specifies what the tool does and returns. Minor gap: no mention of response format (e.g., list or object), but still sufficient for a straightforward listing tool.

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

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

Schema description coverage is 100% for the single parameter (includePlanned). The tool description does not add extra context beyond what the schema conveys, 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?

Description clearly states the action (List) and the resource (PoolParty program modes), specifies the returned items (broadcast_loop, video_queue, screening_session) with details (descriptions, best-for use cases, status). It distinguishes from sibling list tools by focusing on program modes.

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

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

Description implies read-only usage with no auth, but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not guidance is provided.

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

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

No annotations are provided, so the description carries the burden. It mentions the required scope, which is good, but does not disclose rate limits, pagination, or behavior when the queue is empty. Adequate but not thorough.

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

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

Single sentence, no fluff. Every word adds value. Efficient and front-loaded.

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

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

No output schema, and the description does not explain return format or structure. For a list tool, knowing what fields are returned would be helpful. However, the tool is straightforward, so it is minimally 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 covers 100% of the parameter with a description. The tool description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

Description clearly states the verb 'Inspect', the resource 'Program Queue', and the context 'for a channel'. It distinguishes from sibling tools like draft, publish, or reorder. 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?

Implies usage for viewing the editable queue before modifications, but does not explicitly state when not to use it or differentiate from alternatives like list_live_queue or list_programming_candidates. No exclusion or scenario 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?

Given no annotations, the description discloses important behavioral traits: it creates a transaction (STAKE_ADD), requires wallet-owner approval or agent-owned funded wallet for Amoy, and is a public wallet action with no MCP auth. It does not mention rate limits or potential side effects beyond ranking changes, but overall it is fairly transparent.

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

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

The description is several sentences long and front-loads the main purpose, but it includes some procedural details that could be streamlined. It is not overly verbose but could be more concise without losing 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?

The description references related tools (finalize_pool_support, get_pooling_receipt, get_block_economics) and outlines a workflow, which helps the agent understand the tool's role. However, it lacks explicit return value structure and uses terms like 'PP0' and 'Amoy' without definition, limiting completeness.

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

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

The input schema has 100% description coverage, so each parameter is already well-defined. The description adds little beyond the schema, only tying 'test collateral' to the amount parameter. This is adequate but does not significantly enhance 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: using PP0 test collateral to support an eligible active user BLOCK and returning rank/score changes. It also mentions creating a STAKE_ADD transaction intent, which clarifies the action. However, the term 'BLOCK' is capitalized and might be ambiguous without context, and the description is somewhat dense.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 usage context by referencing a multi-step workflow (Amoy prepare mode, finalize_pool_support, settlement via get_pooling_receipt and get_block_economics). However, it does not explicitly compare with sibling tools or state when not to use this tool, leaving some ambiguity for the agent.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: the tool never signs or broadcasts, requires wallet approval, and returns only preparation outputs (approval requests, transaction request). However, it does not explicitly state whether the tool is read-only or has side effects beyond returning data, nor does it mention idempotency or error handling. The transparency is adequate but not exhaustive.

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

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

The description is two sentences with no redundant fluff. The first sentence front-loads the core purpose and outputs, and the second adds essential constraints (no MCP auth, wallet approval required, never signs). Every word earns its place, and the structure is efficient.

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

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

For a tool with 6 parameters and no output schema, the description covers the return values (approval facts, request, txIntentId, gas/collateral, next action) and key prerequisites (block playable, wallet matching, session attachment). It could be more complete by explaining error scenarios or what happens if the block is not eligible, but it provides sufficient context for the average use case.

Complex tools with many parameters or behaviors need more documentation. 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, so the baseline is 3. The description adds value beyond the schema by clarifying that blockId must reference a playable and active block, that walletAddress must match the creator/submitter wallet or a session-attached wallet, and that collateralAmount defaults to staged intent or PP0 minimum. These details help the agent select correct parameter values but are not fully comprehensive for all edge cases.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 canonical PP0 block NFT minting and lists specific outputs (approval facts, request, txIntentId, etc.). It distinguishes from sibling finalize_block_mint by naming it as the next action, and the verb 'prepare' plus the resource 'block mint' is specific and unique among siblings.

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

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

The description explains the tool is a public wallet action requiring wallet-owner approval or an agent-owned funded signer, and that it never signs or broadcasts. It mentions the prerequisite that the block must be playable and active, and for agent-created blocks, the agentSessionId must match a wallet attached via attach_wallet_to_session. While it doesn't explicitly state when not to use this tool, it clearly indicates finalize_block_mint as the subsequent step, providing 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, the description fully discloses behavioral traits: requires specific scope, does not sign or broadcast, reservation expires in 15 minutes, and settlement requirements. This covers key safety and operational details.

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

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

The description is a single paragraph, front-loaded with purpose and key details. It is clear and efficient, though slightly dense with multiple clauses. No wasted sentences.

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

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

Despite no output schema, the description explains return values comprehensively (legacy purchaseIntent and ADA-36 envelope with endpoints). It covers prerequisites, behavior, expiration, and follow-up actions, making it complete for agent decision-making.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema; for idempotencyKey it mentions existing PENDING intent but that is already in the schema. No additional parameter insights.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Prepare a SuperBlock purchase reservation.' It details the output based on ADA-36 flag status and distinguishes from related tools like settle_paid_action by noting it does not sign or broadcast transactions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 context: required API scope, flag-dependent behavior, expiration, and post-purchase steps. However, it does not explicitly state when to use this tool versus siblings like quote_superblock_reservation.

Agents often have multiple tools that could apply. Explicit usage 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 'Read-only. No auth required' and lists specific outputs (starter blocks, submission policy, etc.), providing full behavioral transparency in the absence of annotations.

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

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

The description is concise (4 sentences), front-loaded with the purpose, and contains no superfluous information.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers purpose, behavior, return type, and constraints completely.

Complex tools with many parameters or behaviors need more documentation. 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 parameter templateId already well-described. The description adds minimal extra meaning beyond implying the parameter selects the template.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Preview' and the resource 'what a channel template would create,' distinguishing it from siblings like create_channel_from_template and list_channel_templates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 use for dry-run preview and mentions that channel creation is not yet available, but does not explicitly name alternative tools or when not to use.

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

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

With no annotations provided, the description carries the full burden. It clarifies that the tool is a read-only preview (implied by 'preview') and requires specific scope. It does not detail side effects or return format, but the non-destructive nature is evident.

Agents need to know what a tool does to the 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 plus a scope requirement, with no wasted words. It is front-loaded with the primary action and context, making it highly concise.

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

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

Given the tool has 2 parameters and no output schema, the description adequately covers purpose, prerequisites, and parameter sources. It could mention return value briefly, but the tool is sufficiently described for an AI 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 description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning for parameters, simply repeating the source for candidateId. No further elaboration on channelSlug 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 verb 'preview', the resource 'one programming candidate', and the context 'before promoting to Program Queue'. It distinguishes from sibling tools like 'list_programming_candidates' and 'admit_programming_candidates' by specifying the preview action.

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

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

The description indicates when to use the tool (before promoting to Program Queue) and specifies the required scope. It does not explicitly mention when not to use it or provide alternatives, but the context is sufficiently clear for appropriate usage.

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

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

With no annotations, the description fully discloses read-only nature, no auth required, and explicitly lists actions not performed (submit, bypass moderation, mint, etc.). 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?

Two concise sentences with front-loaded purpose. Every sentence adds value with no fluff.

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

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

Covers outcome (previewUrl), constraints (preview-only, no auth), and limitations. Could mention validation role more explicitly but sufficient given complexity.

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

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

Schema coverage is 50% (only channelSettings has description). The description does not add parameter-level details beyond the schema, so baseline score 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 validates and summarizes a SlideBlock package, returning a previewUrl. Distinguishes from siblings by explicitly stating it does not submit, bypass moderation, or modify state.

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

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

Provides clear context for when to use (before operator review) and what it does not do (submit, moderate, etc.). Lacks explicit 'when not to use' phrasing but is implied.

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

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

With no annotations provided, the description carries full burden. It explicitly states 'without mutating anything', which is helpful. However, it does not disclose error handling, permissions failure behavior, or rate limits, leaving some behavioral gaps.

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

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

Two sentences total, front-loaded with key message (suggest, non-mutating), and includes scope requirement. No unnecessary words; highly efficient.

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

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

For a tool with 3 parameters and no output schema, the description covers purpose, non-mutation, scope, and parameter defaults. It lacks explicit return value description, but the tool is simple enough that the context is largely complete.

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

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

Schema description coverage is 100%, so parameters are documented. The description adds value by clarifying that 'programItemIds' defaults to source-score-informed order, which aids understanding beyond the raw schema.

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

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

The description clearly states the verb 'Suggest' and resource 'Program Queue order', explicitly noting it does not mutate anything. This distinguishes it from sibling tools like 'accept_programming_proposal' or 'reorder_program_queue'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 it requires 'propose:programming' scope, but does not explicitly contrast with alternatives like 'reorder_program_queue' or 'publish_program_queue'. However, the non-mutating nature is clearly stated, providing implicit 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 full burden. It discloses authorization and audit side effects but does not mention destructive behavior (e.g., the 'replace_live_queue' mode implies overwriting) or error conditions. Behavioral details are minimal.

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

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

Two sentences, 18 words, front-loaded with the main purpose. Every word 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?

Given no output schema and 4 parameters, the description lacks information about return values, success/error behavior, and idempotency. It is moderately complete but misses key context for a mutation tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning to parameters beyond what the schema provides. No parameter details are given in the description.

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

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

The description clearly states the verb 'Publish' and the specific resource 'Program Queue order' to the target 'live runtime queue'. It distinguishes from sibling tools like 'draft_program_queue' and 'simulate_program_queue_publish' by indicating this is a live runtime action.

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

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

The description mentions required scope ('publish:program_queue') and side effect (audit event), providing context for use. However, it does not explicitly guide when not to use or compare with alternatives like 'draft_program_queue' or 'simulate_program_queue_publish'.

Agents often have multiple tools that could apply. Explicit usage 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 auth scope, idempotency key behavior, return types (x402 envelope, HTTP 402, settlement requirements), and that reservations have short TTL. Could mention expiration/cancellation details.

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

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

A single paragraph covering scope, auth, modes, returns, and idempotency. No unnecessary words, every sentence adds value. Front-loaded with action and required scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, describes return types adequately. Covers auth, two modes, content object binding, and idempotency. Could add TTL details or error handling, but sufficient 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% (baseline 3). Description adds value by explaining required parameters, detailing reserve behavior, and describing content object as 'bound into the reservation content hash'. Goes beyond schema with idempotency key purpose.

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

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

Clearly states the tool quotes or reserves a sponsor/lobby card paid action, distinguishes between pure quotes and inventory-holding reservations, and mentions required auth scope. Differentiates from sibling tools like 'get_sponsor_opportunities' and 'quote_superblock_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?

Provides guidance on when to use reserve=true vs false, explains that pure quotes don't hold inventory while reserve=true creates a short-TTL reservation. Lacks explicit comparison to siblings like 'get_sponsor_opportunities' for browsing before quoting.

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

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

No annotations are provided, so the description carries the full burden. It states the tool is a pure quote (no inventory held) and requires a specific scope. It also describes the return type (payment envelope, settlement requirements). However, it lacks details on quote expiration, idempotency behavior, or whether the quote locks anything.

Agents need to know what a tool does to the 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, front-loaded with the core purpose, no redundant or irrelevant information. Every sentence adds value.

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

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

Given the tool has 4 parameters fully described in schema, no output schema, and no annotations, the description provides needed context: it explains the return value (payment negotiation envelope, settlement requirements) and the prerequisite scope. Could be improved by mentioning output format or error handling, but adequate for a quote tool.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add any meaning beyond what the schema already provides for parameters like offeringId, walletAddress, mode, or idempotencyKey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 quotes a SuperBlock paid action without holding inventory, distinguishing it from prepare_superblock_purchase which creates a payment-required reservation. The verb 'quote' and resource 'SuperBlock paid action' are specific and unambiguous.

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

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

The description explicitly states this is a quote-only tool and directs to use prepare_superblock_purchase for actual reservation. It also mentions the required API scope. However, it does not differentiate from sibling quote_sponsor_reservation or provide guidance on when not to use this tool vs. other quote-related tools.

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

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

With no annotations provided, the description carries the full burden. It discloses the required 'write:live_queue' scope and the side effect of recording an audit event, which is useful behavioral context beyond the input schema.

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

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

A single, front-loaded sentence that efficiently conveys the purpose and key prerequisites. No extraneous words.

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

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

For a removal tool with no output schema, the description is adequate but minimal. It covers the action and side effects, but does not mention potential error conditions, return values, or confirm success.

Complex tools with many parameters or behaviors need more documentation. 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 three parameters. The description adds no additional meaning beyond what is in the schema, 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 action ('Remove an item from the live queue') with a specific verb and resource. It is distinct from sibling tools like 'skip_current_live_item' by implying permanent removal, though it does not explicitly differentiate.

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

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

The description provides a prerequisite (scope requirement) but offers no guidance on when to use this tool versus alternatives like 'skip_current_live_item' or 'insert_live_next'. No context about when not to use it is given.

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