PZERO

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

With no annotations provided, the description carries the transparency burden. It discloses an important behavioral nuance: pending USDC is not spendable until confirmed, and low confirmed balances should trigger a call to funding_instructions. It does not mention authentication, rate limits, or exact response shape, but for a simple read endpoint the key behavior is conveyed.

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

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

The description is two sentences with no filler. The endpoint and primary fields are front-loaded first, and the actionable caveat follows immediately. Every sentence earns its place.

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

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

For a zero-parameter, no-output-schema endpoint, this description is complete: it names the endpoint, the returned fields, an important semantic caveat, and the sibling tool to call in a specific condition. An agent has enough context to invoke it correctly and follow up appropriately.

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

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

The tool has zero parameters and the input schema is an empty object with 100% coverage, so there is nothing for the description to document. The baseline of 4 for zero-parameter tools is appropriate, and the description usefully labels what the response covers.

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

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

The description states a specific verb and resource ('GET /v1/agent/me') and names the exact fields returned: balances, key prefix, and max price. It also differentiates itself from the sibling funding_instructions by describing what it returns versus what that other tool is for.

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

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

It gives explicit conditional guidance: 'If confirmed is low, call funding_instructions.' This tells the agent not only what agent_me does but when to route to the relevant alternative. The pending-USDC note adds useful context for interpreting the result.

Agents often have multiple tools that could apply. Explicit usage 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 disclosure burden. It adds genuinely useful behavioral context beyond the schema: the call is 'buffered' (implying it waits for the full response rather than streaming) and it returns cost trace headers, which hints at billing behavior. However, it does not disclose auth requirements, idempotency, potential latency implications of buffering, or error behavior.

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

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

Three tight fragments — endpoint/mode, prerequisite, and return value — with zero filler. The most identifying information (endpoint and buffered mode) is front-loaded, and each sentence contributes distinct operational knowledge an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 relatively simple 4-parameter tool, the description covers the essentials: endpoint, buffering mode, model prerequisite, and return shape. But with no output schema and no annotations, it leaves gaps: no detail on what 'cost trace headers' actually affect, no guidance on which sibling generation tool to select for which kind of generation, and no clarification of the message format beyond the schema's terse 'OpenAI-style messages'.

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

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

Schema description coverage is 50% — model and messages are described, while max_tokens and temperature are bare properties with no description. The description adds real value for the model parameter by specifying it must be a 'live model id from get_models', which is not in the schema. Messages are covered by the schema's 'OpenAI-style messages'. The two undocumented parameters remain unexplained in both schema and description, so the description only partially compensates.

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

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

The description states a specific verb and resource ('POST /v1/chat/completions') and clarifies the operation mode ('buffered'). It also names the key dependency ('Pass a live model id from get_models') and the return shape ('completion plus cost trace headers'). It distinguishes from siblings like generate_image and generate_video by naming the chat endpoint, though it does not explicitly position itself against them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 instruction to pass a live model id from get_models is a clear prerequisite that informs the agent it must first call a sibling tool. However, there is no explicit guidance on when to choose chat_completions over the other generation tools (generate_image, generate_video, video_complete) or when not to use it. Usage context is implied by the endpoint name rather than stated.

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

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

Annotations only state the call is not read-only, not idempotent, and not destructive. The description adds two non-obvious behavioral facts: no USDC credit is granted, and the API key is shown in plaintext only once. This is critical operational context beyond what annotations convey.

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

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

The description is one tight sentence containing the endpoint, the action, and two important caveats. Every clause carries information, and the most critical caveats ('Does NOT add USDC credit', 'Plaintext shown once') are front-loaded after 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?

For a one-parameter creation tool, the description covers the essential operational facts: endpoint, creation action, no credit grant, and single plaintext display. It does not detail the full response format, but 'Plaintext shown once' partially signals the return behavior, and there is no output schema requiring additional detail.

Complex tools with many parameters or behaviors need more documentation. 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 single 'name' parameter is already documented in the schema as 'Label for the new API key.' The description adds no parameter-level meaning, so it stays at the baseline for full schema coverage.

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

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

The description names the exact endpoint action ('POST /v1/agent/keys') and uses a specific verb+resource ('mint another key'), making creation unambiguous. It clearly separates this tool from siblings like list_keys and revoke_key without requiring schema inspection.

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

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

The description gives an explicit when-not: this tool does NOT add USDC credit, so it should not be chosen for funding workflows. It does not name an alternative tool like funding_instructions, but the negative guidance is enough to steer an agent away from a likely 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states a critical safety trait: "MCP never accepts payment or wallet keys," warning against a tempting misuse. It also discloses the authentication flow (Bearer pzero_…), which is relevant behavioral context for an agent preparing to call other tools.

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

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

Three short sentences, each earning its place: the first states the purpose, the second prevents a critical misunderstanding, and the third gives the concrete funding and authentication steps. The key directive is front-loaded in the opening phrase, making it immediately scannable for an agent.

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

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

For a zero-parameter instructional tool with no output schema, the description covers the essential content: funding methods, authentication token format, and a key constraint. It could elaborate on what exactly Studio x402 or the HTTP signup/refill endpoint entails, but that level of detail is likely unnecessary for an agent deciding how to proceed.

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

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

The tool has zero parameters, so per the rubric the baseline is 4. The description adds no parameter-level detail because there is nothing to document. It does mention the Authorization Bearer format, which is an implicit authentication detail beyond the empty schema, adding slight extra value.

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

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

The description opens with "How to fund a PZERO account and authenticate MCP," a clear statement of the tool's purpose as an instructional guide. It distinguishes itself from all sibling tools, which are operational API calls (e.g., chat_completions, generate_image, create_key), by being the only funding/authentication reference. The verb is explicit (fund, authenticate) and the resource scope (PZERO account, MCP) is specific.

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

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

The description provides actionable guidance: "MCP never accepts payment or wallet keys" tells the agent not to attempt payment through MCP, and "Fund via Studio x402 top-up or agent HTTP signup/refill, then use Authorization Bearer pzero_…" gives concrete steps. It does not explicitly contrast with alternative tools, but since this is a unique instructions tool, the implied usage 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 provided, the description carries the full burden of behavioral disclosure. It does add useful behavior: it rejects enable_web_search and returns images plus a cost trace. However, it omits important context such as authentication requirements, cost side effects, rate limits, and any failure modes, so transparency is only partial.

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

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

The description is short and front-loaded, with the endpoint and core purpose in the first clause. Every sentence carries some information and there is no filler. It is concise without being merely a tautology, even if brevity leaves gaps that other dimensions capture.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 eight parameters, no output schema, and no annotations, this description is materially incomplete. It does not explain how the many optional parameters interact, what constraints exist, or what the response structure looks like beyond 'images plus cost trace'. An agent would likely need to inspect related tools or experiment to call this reliably.

Complex tools with many parameters or behaviors need more documentation. 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 only 25%, so the description must compensate by explaining parameter meaning. It adds only that enable_web_search is rejected, while leaving prompt, quality, resolution, aspect_ratio, and hide_watermark semantically unexplained. The schema provides descriptions for n and model, but the description itself does not add meaningful detail for most parameters.

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

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

The description clearly identifies this as an image generation tool, naming the endpoint and stating it returns images plus cost trace. It is distinct from generate_video by domain, though it doesn't explicitly compare itself to siblings. The phrase 'intent tool' is slightly ambiguous but does not undermine the clear resource and action.

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

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

The description provides almost no guidance on when to choose this tool over chat_completions, generate_video, or other siblings. It only states a rejection condition (enable_web_search) rather than explaining intended call scenarios or alternatives. An agent must infer usage from the tool name and endpoint.

Agents often have multiple tools that could apply. Explicit usage 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 goes beyond annotations by explicitly disclosing that the tool spends prepaid USDC, settles before enqueuing, and returns cost. This adds meaningful context to the destructiveHint=true annotation, clarifying the exact side effect and the payment flow. The description does not contradict any annotation; in fact, it reinforces them with concrete 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 concise and well-structured, packing essential information into two sentences: the endpoint, behavior, return values, confirmation requirement, and polling alternatives. The most critical facts (spending USDC and confirmation) are front-loaded, and every sentence earns its place 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?

The description covers the action, side effects, and return values, but omits any explanation of the parameters, which is especially problematic given the low schema coverage and absence of an output schema. For a tool with six parameters, the description is incomplete; an agent would not know how to correctly set optional fields like duration, resolution, or aspect_ratio, nor what valid values are.

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

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

The description provides no information about any of the six parameters. With schema description coverage at only 17% (only model has a description), the agent receives no guidance on duration, resolution, aspect_ratio, or prompt content. The description fails entirely to compensate for the schema's lack of parameter documentation, leaving the agent to guess how to populate these fields.

Input schemas describe structure but not intent. Descriptions should explain 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 generates a video via POST to /v1/video/queue, and specifies it settles then enqueues, returning queue_id and cost. It identifies itself as an 'intent tool' and mentions polling with get_generation_status or wait_for_video, giving context. However, it does not explicitly differentiate from sibling tools like video_queue, which serves a similar purpose, so it's not fully distinguished.

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

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

The description gives strong guidance to confirm before calling because it spends prepaid USDC, and instructs the agent to poll with get_generation_status or wait_for_video afterward. However, it does not state when this tool should be used instead of alternatives like video_queue, nor does it provide exclusions or conditions. The usage context is partially covered but lacks explicit decision rules.

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

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

With no annotations, the description must carry the behavioral burden; it partially does by specifying 'GET /v1/capacity', which signals a read-only query, and by framing it as a pre-decision check that should not itself spend. However, it does not explicitly state side-effect guarantees or how the response is structured, leaving some behavior implicit.

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

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

The description is a single, front-loaded sentence with no filler: endpoint first, then the data provided, then the usage context. Every part contributes.

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

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

For a simple one-parameter GET endpoint, the description covers the essential purpose, timing, and a hint at return values ('DIEM and price bands'). However, 'DIEM' is left undefined and no return format or error behavior is described, so an agent may still have to infer some details.

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

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

Schema description coverage is 100% — the only parameter, max_price_cents, already has a description ('Optional buyer ceiling 30-80'). The tool description does not add further parameter-level meaning, so this is at the baseline of 3.

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

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

The description uses the specific verb 'GET' with the resource '/v1/capacity' and states the domain ('DIEM and price bands before funding or spend decisions'), making the core purpose understandable. It distinguishes itself from funding/spend siblings by being the pre-decision capacity lookup, though the unexplained 'DIEM' acronym keeps it from a perfect score.

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

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

The phrase 'before funding or spend decisions' provides a clear situational trigger for calling this tool. It does not explicitly name sibling alternatives or state when not to use it, so it falls just short of full 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 behavioral burden. It discloses that this is a single POST request, that it retrieves status, and that the response is either JSON status or an MP4. It does not cover error cases, idempotency, or how the MP4 is delivered, but it gives the essential one-shot behavior.

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

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

The description is a single telegraphic fragment with no wasted words: it gives the method, endpoint, invocation count, and expected response type. It is concise and front-loaded, though it could be slightly more natural as a full sentence.

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

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

For a simple single-parameter tool, the description covers the core call pattern and response categories. However, without an output schema it does not clarify under what conditions the caller gets JSON status versus an MP4, nor how the MP4 is returned, leaving some ambiguity 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?

The only parameter, queue_id, is already fully described in the schema with 100% coverage. The tool description adds no additional parameter context, which is acceptable because the schema already provides sufficient meaning.

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

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

The description identifies the operation as a one-time POST to /v1/video/retrieve and indicates the outcome is either a JSON status or a delivered MP4. This is clear enough for the tool's purpose, but it does not explicitly distinguish it from sibling tools like video_retrieve or wait_for_video.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 word 'once' implies this is a single status check rather than a polling/waiting operation, which offers some usage context. However, it does not explicitly say when to use this tool instead of wait_for_video or video_retrieve, nor does it state any exclusions.

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

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

No annotations exist, so the description carries the burden. It discloses the HTTP method (GET), the live nature of the data, and the exact behavior of the optional id parameter: it returns one public row identical to that id in the list. This is adequate for a read-only listing 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 compact sentences with no filler. The core purpose is front-loaded, and the optional-id behavior plus the hardcoding warning each earn their place.

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

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

For a simple one-parameter read-only tool with no output schema, the description covers purpose, usage timing, optional-id behavior, and a key pitfall. It could explicitly state the response is a model list, but 'GET /v1/models' implies this sufficiently.

Complex tools with many parameters or behaviors need more documentation. 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 the id parameter and that omitting it returns the full list. The description adds a useful consistency guarantee ('same object as that id in the list') but does not significantly extend the 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?

The description names the specific verb and resource ('GET /v1/models') and a concrete purpose: resolving a live model id before inference. This clearly distinguishes it from inference, generation, key, and video 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?

It explicitly tells the agent to use this before inference and warns against hardcoding model ids. It does not name alternative tools or state when not to use it, but the guidance is clear enough for a simple lookup tool.

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

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

With no annotations provided, the description carries the behavioral burden. It usefully discloses that this is a GET operation and that it retrieves cost/trace data, marking it as read-only in spirit. However, it omits details like authentication requirements, error behavior, rate limits, or how the trace data is returned.

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

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

One dense sentence conveys the endpoint, resource, and purpose. No filler or redundant restatement, and the essential action is front-loaded.

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

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

For a simple one-parameter GET tool with no output schema, the description plus schema are mostly sufficient. It states what the operation returns (cost/trace), identifies how to locate the prior request via support_reference, and the GET method implies a safe read. Minor gaps remain around usage context and response format, but the low complexity reduces the need for 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 coverage is 100%, so the schema already documents support_reference as a UUID from a prior call. The tool description adds little beyond placing the parameter in the URL path, so the baseline score of 3 applies.

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

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

The description names the exact HTTP verb and resource, and states the specific outcome: recovering cost/trace for a prior request. This clearly distinguishes it from siblings like get_models or get_generation_status, which target different resources or purposes.

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

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

Use is only implied by the phrase 'prior request' and the support_reference parameter. There is no explicit guidance on when to choose this over sibling tools, no prerequisites, and no mention of invalid use cases.

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

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

No annotations are provided, so the description carries the disclosure burden. It meaningfully states that plaintext keys are never returned and limits scope to active metadata, which is valuable behavioral context. It does not cover auth or response format, but for a zero-parameter GET list tool this is adequate.

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

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

One concise sentence with the endpoint front-loaded, the operation stated, and a critical safety note in parentheses. Every word earns its place and no filler is present.

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

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

For a simple zero-parameter list tool with no output schema, the description provides enough to understand what is returned at a high level and that secrets are not exposed. It could be more detailed about metadata fields, but nothing essential is missing for invoking the tool correctly.

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

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

The tool has zero parameters, so parameter semantics are not applicable. Per the baseline for zero-parameter tools, this is scored 4; there is no missing parameter information to compensate for.

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

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

States a specific verb ('list'), a specific resource ('active API key metadata'), and the HTTP method. It clearly distinguishes this from sibling tools like create_key and revoke_key without ambiguity.

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

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

The description implies the tool is for listing key metadata, which contrasts with create_key and revoke_key, but it does not explicitly name alternatives or state when not to use it. Usage context is clear but relies on inference from the tool name and siblings.

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

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

Annotations already declare destructiveHint=true, and the description reinforces but also extends this with 'irreversible', clarifying that the operation cannot be undone. The warning about the MCP session's own key adds behavioral context beyond the annotations — it discloses a self-harm hazard specific to this tool. No contradiction exists between description and 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 compact sentence with two clauses: the operation and the crucial warning. Critical information (irreversibility, self-key hazard) is front-loaded, and there is zero filler. Every word earns its place.

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

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

For a simple one-parameter destruction tool, the description covers the endpoint, the irreversible consequence, and the most important hazard (revoking the session's own key). No output schema exists, but for a delete operation the return value is low-stakes. It is complete enough for an agent to invoke correctly, though it could optionally note what happens to active consumers of the revoked key.

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

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

Schema description coverage is 100%, with the single parameter 'id' documented as 'UUID of the key to revoke'. The description's '{id}' placeholder merely echoes what the schema already states and adds no new semantic detail. Per the baseline rule for high-coverage schemas, a 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 conveys action and resource via the REST shorthand 'DELETE /v1/agent/keys/{id}', making it clear the tool permanently removes an agent key. It distinguishes itself from sibling tools like create_key and list_keys through the explicit DELETE method and 'irreversible' qualifier. However, it relies on endpoint notation and the tool name rather than a plain-language verb-noun statement, so it stops just short of a 5.

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

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

The description provides a clear caution about when to avoid use ('Do not revoke the key used by this MCP session unless intentional'), which is valuable operational guidance. It does not explicitly state when this tool should be used or name alternatives, though no sibling offers equivalent functionality. The guidance is safety-oriented rather than decision-oriented, so it earns a mid-range score.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the useful behavioral note that the change 'does not auto-apply', which is beyond the structured annotations and helps the agent understand the tool's effect.

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

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

The description is two concise sentences with no filler. It front-loads the endpoint and action, then gives the trigger condition and a key behavioral caveat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 one-parameter mutation tool with 100% schema coverage and idempotence declared, the description covers the essential selection and invocation context. It does not describe the response or error behavior, but that is a minor gap given the tool's simplicity.

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

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

The schema already provides 100% parameter coverage: max_price_cents_per_dollar is described as 'Buyer ceiling in cents per DIEM dollar, 30-80'. The description mostly restates the range, adding no new parameter semantics, 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 identifies a specific action ('raise/lower ceiling') on a specific resource ('/v1/agent/max-price') and states the allowed range (30-80). This is a clear verb+resource statement that leaves no doubt about what the tool does.

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

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

The description gives an explicit trigger condition: use when tools return no_eligible_supply with cheapest_posted_cents. It does not name alternatives or exclusions, but no similar sibling exists, so the condition is sufficient for selection.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'optional cleanup.' It does not reveal whether this is destructive, whether it releases resources, whether it is idempotent, or what happens if the queue_id is invalid. The agent is left guessing about the operation's 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 extremely short and front-loads the endpoint and primary behavioral clue. It wastes no words, though the phrase 'optional cleanup' could be more informative without sacrificing brevity.

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

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

Given the single parameter and no output schema, the description is still incomplete for an agent deciding whether and how to call it. It does not say what success looks like, what 'cleanup' entails, or whether this tool is required after retrieval. The sibling tools video_retrieve and wait_for_video suggest context, but the description itself lacks enough detail.

Complex tools with many parameters or behaviors need more documentation. 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 schema already explains that queue_id comes from video_queue / generate_video. The tool description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description identifies the action ('cleanup') and the timing ('after retrieve'), which is more than a tautology. However, 'cleanup' is vague—it doesn't specify what resource is cleaned up or what completing a video actually does. It weakly distinguishes from video_retrieve by sequence but not from other 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?

'Optional cleanup after retrieve' implies when to use the tool, and 'optional' suggests it can be skipped, but there is no explicit guidance on when to run it versus when to skip it. No alternative tools are named, so an agent must infer usage from the sibling list and the word 'after'.

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

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

Annotations already convey the operation is not read-only, not idempotent, and destructive (destructiveHint=true). The description adds the crucial fact that the operation is paid and involves settlement+enqueue, which annotations cannot express. It does not explain what destructive side effects occur or what 'settle' means.

Agents need to know what a tool does to the 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 admirably brief and front-loaded with the endpoint and action; no filler. The cryptic 'settle+enqueue' reduces clarity, but every sentence carries intent and the routing preference.

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

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

A six-parameter paid queue operation with no output schema needs far more context: what settlement means, preconditions, cost implications, and parameter meaning. The one-line description plus sparse annotations is inadequate.

Complex tools with many parameters or behaviors need more documentation. 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 only 17% (model alone is documented), and the description adds no parameter information. With six parameters and no enums, an agent has no guidance on prompt semantics, duration, resolution, aspect_ratio, or audio from either the schema or 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 explicitly identifies the endpoint and core action ('paid settle+enqueue'), and it points to generate_video as the preferred alternative, which helps distinguish it from sibling tools. However, 'settle+enqueue' is jargon and does not fully specify the tool's purpose or effects.

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

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

It provides one explicit routing cue: 'Prefer generate_video for agents,' which tells an agent that this is not the default choice. It does not specify what conditions would warrant using video_queue over generate_video, video_quote, or video_complete, so the guidance is partial.

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

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

With no annotations, the description carries the burden of revealing side effects. It discloses that the call does not settle a payment and does not create a job, signaling a non-mutating quote operation. However, it does not describe the response content, idempotency, or any failure modes.

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

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

The description is a single dense sentence that front-loads the endpoint and immediately states key exclusions. No filler, but the cryptic 'clears_now vs price ceiling vs funding' could be clearer to an agent without domain knowledge.

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

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

Given no annotations, no output schema, and sparse parameter descriptions, this text leaves important gaps: it does not explain what the quote response contains, how clears_now is computed, or how the price ceiling and funding instructions relate to the result. It is too thin for a six-parameter tool that an agent must call 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 only 17%—only 'model' is documented—and the description itself mentions none of the six parameters. It adds no meaning to prompt, audio, duration, resolution, or aspect_ratio, leaving the agent without guidance on how inputs affect the quote.

Input schemas describe structure but not intent. Descriptions should explain 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 names the POST /v1/video/quote endpoint and frames it as a pre-queue check, with 'no settle, no job' clarifying that this is not a job-creation or settlement operation. It differentiates from generation tools through negation, though it never plainly states that it returns a price estimate.

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

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

'before queue' provides a clear temporal condition for when to call this tool, and the instruction to compare clears_now, price ceiling, and funding defines its role in the workflow. It does not explicitly name sibling tools such as video_queue or set_max_price, but the context is unambiguous.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'status/media poll', which hints at polling behavior, but it does not state whether the call is read-only, whether it blocks or returns immediately, what happens when media is not ready, or what the response contains.

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

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

The description is a single compact line with the endpoint front-loaded and no filler. It is easy to parse, though the phrase 'power-user status/media poll' is somewhat vague and jargon-heavy.

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

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

With no output schema and no annotations, the description should explain what the tool returns and how it fits into the video generation workflow. It only gives a vague 'status/media poll' label, leaving the agent uncertain about return payloads, polling semantics, and relationship to sibling tools.

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

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

The sole parameter queue_id is already fully described in the schema ('Queue id from video_queue / generate_video'), and schema description coverage is 100%. The description adds no additional meaning about this parameter, so the baseline of 3 is appropriate.

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

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

The description identifies the HTTP endpoint and characterizes the tool as a 'status/media poll', which indicates it retrieves video status or media for a queued job. This is more specific than a tautology, though it does not clearly differentiate from sibling tools like get_generation_status or video_complete.

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

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools such as wait_for_video, get_generation_status, and video_complete exist, but the description gives no criteria, conditions, or exclusions to help an agent choose correctly.

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

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

Although no annotations are present, the description discloses that the tool repeatedly polls, stops on 'delivered or failed', and backs off on HTTP 502. This is useful, but it omits what happens when max_polls is exceeded or what the return value looks like, so the behavioral disclosure is only partial.

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

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

Two short sentences with no filler; the main action and termination condition are front-loaded, and the backoff behavior earns its place as operational detail. This is appropriately sized for the tool's simplicity.

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

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

For a simple polling tool with no output schema and no annotations, the description covers the core loop and a notable retry behavior, but it lacks a description of return values, timeout/limit behavior, and when to choose this over sibling tools. It is minimally viable but leaves several operational aspects implicit.

Complex tools with many parameters or behaviors need more documentation. 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 documents max_polls and interval_ms, and the phrase 'Poll video retrieve' connects queue_id to a retrieval request, but the description adds no explicit parameter meaning. The required queue_id remains only implicitly explained, and with 67% schema coverage the description does not go beyond the structured information.

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

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

The description uses a specific verb 'Poll' with a clear resource ('video retrieve') and terminal conditions ('delivered or failed'). It clearly distinguishes itself from one-shot retrieval siblings like video_retrieve by indicating a repeated polling loop, and the backoff note adds operational clarity.

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

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

No explicit guidance is provided about when to use this tool versus alternatives such as video_retrieve or get_generation_status. The description implies its role as a waiting/blocking helper but does not state exclusions or preferred conditions, leaving the agent to infer usage.

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