PZERO

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that pending USDC is not spendable until confirmed, and that low confirmed balances should trigger funding_instructions. It could add more about authentication or response shape, but the key caution is present.

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

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

The description is two crisp sentences, front-loads the endpoint and returned fields, then adds the critical pending-USDC caveat and the funding fallback. 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 simple zero-parameter GET endpoint with no annotations and no output schema, the description covers endpoint, returned data categories, a behavioral nuance, and a follow-up action. An agent has enough context to call it correctly.

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

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

The tool has zero parameters and the schema fully documents this with an empty object, so the baseline of 4 applies. The description adds no parameter details, but none are needed.

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

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

The description names a specific verb and resource, 'GET /v1/agent/me', and explicitly lists what the tool returns: balances, key prefix, and max price. This clearly distinguishes it from sibling tools like funding_instructions or list_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?

The description gives a concrete conditional routing rule: 'If confirmed is low, call funding_instructions.' It does not fully state when to choose agent_me over all alternatives, but the endpoint and contents make the primary use case evident.

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 discloses that the request is buffered (not streaming), that a live model id is required, and that the response includes completion plus cost trace headers. This is useful behavioral context beyond the bare endpoint name, though it omits auth, rate-limit, or error 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, front-loaded sentence that packs in the endpoint, buffered behavior, model prerequisite, and return value with zero filler. Every clause 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?

The description is adequate for a straightforward chat completion call: it identifies the endpoint, the required model source, and the high-level return shape. However, with no output schema and no annotations, it leaves some gaps around max_tokens/temperature semantics, authentication, error handling, and what exactly the cost trace headers contain.

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 only 50%: model and messages are described in the schema, but max_tokens and temperature are not. The description adds no new meaning for those two parameters and mostly repeats the schema's existing 'live model id from get_models' note. It therefore does not compensate for the undocumented 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 names a specific endpoint (POST /v1/chat/completions), states what it returns, and notes the buffered behavior, making the tool's purpose immediately clear. It also differentiates itself from sibling tools like generate_image and video_complete by being the chat-completion tool.

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

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

The description gives a useful prerequisite ('Pass a live model id from get_models'), which implies the agent should fetch current model IDs first. However, it does not explicitly state when to choose this tool over alternatives or when not to use it, so usage guidance remains implicit rather than fully explicit.

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

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

Annotations are minimal (only hint flags), so the description carries the behavioral burden. It adds useful non-obvious facts: no USDC credit is added, and the plaintext key is shown only once. This meaningfully helps the agent avoid misusing the tool, though it could say more about side effects or persistence.

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 compact: endpoint, purpose, a pricing/funding caveat, and a security-relevant warning in just three short clauses. Every fragment adds value, and the most important 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 single-parameter creation tool with no output schema, the description is nearly complete: it names the endpoint, states the key's one-time plaintext visibility, and clarifies the funding limitation. It doesn't explain what happens on duplicate names or other error cases, but those are minor 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 input schema already documents the single parameter 'name' with a clear description, and schema description coverage is 100%. The tool description adds no additional parameter-level detail, 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 uses a specific verb ("mint") and resource ("another key") and even gives the exact endpoint, making the tool's function unmistakable. It also distinguishes itself from sibling tools like list_keys and revoke_key by positioning itself as a key creation operation.

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

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

The description clearly implies use when the agent needs to create a new API key, and it explicitly states a when-not: this tool does NOT add USDC credit. However, it does not name an alternative tool for adding credit, so it stops short of the explicit cross-referencing that would earn a 5.

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

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

With no annotations, the description carries the full burden and does well by disclosing a key behavioral constraint: MCP never accepts payment or wallet keys. It also explains the intended funding mechanisms and the required Authorization Bearer format, giving useful behavioral context beyond a bare summary.

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 core purpose and then delivers the essential funding and authentication details without fluff. Every clause earns its place.

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

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

Given the tool has no parameters and no output schema, the description provides the necessary operational context: how to fund, how to authenticate, and what not to send. It is slightly truncated at the bearer-token example, but the guidance is sufficient for an agent 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 and an empty input schema, so there is nothing for the description to compensate for. The funding/auth context does not relate to parameters, but no information is lost; this matches the baseline for parameterless tools.

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 covers how to fund a PZERO account and authenticate MCP, naming the resource ('PZERO account') and the goal ('fund' and 'authenticate'). It does not explicitly contrast itself with sibling tools, but its instructional nature is evident among the operational 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 implies usage when the agent needs funding or authentication guidance, and even lists concrete funding paths ('Studio x402 top-up or agent HTTP signup/refill'). It does not explicitly state when to use this tool versus alternatives or mention any exclusions, so the guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It does add useful behavioral disclosures: the tool rejects enable_web_search and returns images plus a cost trace. However, it does not disclose whether the operation is asynchronous, whether it consumes credits, or what the failure behavior might be.

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

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

The description is one sentence and front-loads the endpoint and purpose. It also packs in a limitation and return value, though 'intent tool' is jargon that slightly muddies the clarity.

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

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

With 8 parameters, no output schema, and no annotations, the description leaves too much unsaid. An agent would not know which values are valid for quality or resolution, whether the call blocks or returns immediately, or how the cost trace is structured.

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 but only clarifies that enable_web_search is rejected. It does not explain how to set quality, resolution, aspect_ratio, or hide_watermark, nor valid values. The n and model descriptions come from the schema, not 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 states the resource (image generation via POST /v1/image/generate) and that the tool returns images plus cost trace, which distinguishes it from the sibling generate_video. It is clear but somewhat diluted by the vague phrase 'intent tool.'

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

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

No explicit guidance on when to use this tool versus alternatives such as generate_video. The only operational hint is that enable_web_search is rejected, but there is no context about prerequisites, model selection via get_models, or when generation should be preferred over other endpoints.

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?

Beyond the annotations, the description reveals that the call settles a payment, enqueues work, returns queue_id + cost, and consumes prepaid USDC. This is exactly the kind of side-effect and cost disclosure an agent needs before invoking a destructive, non-idempotent tool.

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

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

Three short sentences, each earning its place: endpoint behavior, return value, and cost warning with polling guidance. The critical cost side effect is front-loaded and nothing is wasted.

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 monetary side effect and the follow-up polling path, but it is incomplete for a 6-parameter tool with no output schema and very low schema coverage. It does not explain how to use the optional parameters or what the required prompt field should contain, leaving a meaningful gap for correct invocation.

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

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

Schema description coverage is only 17%, so the description must compensate for undocumented parameters. It does not: no meaning is added for prompt, duration, resolution, aspect_ratio, or audio, and only the schema itself describes model. An agent invoking this tool still lacks semantic guidance for most inputs.

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

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

The description names a specific resource and operation: POST /v1/video/queue, and clarifies that it settles then enqueues a video job. It is clear about the tool's role but does not explicitly distinguish it from the sibling video_queue tool.

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

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

It gives actionable context: confirm before calling because it spends prepaid USDC, and poll with get_generation_status or wait_for_video afterward. It does not explicitly state when to prefer this tool over its video-related siblings, so it stops short of complete alternative routing.

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 includes the HTTP method GET, which signals a read-only lookup, and notes that it happens before funding or spending, implying no mutation is performed. However, with no annotations and no mention of response details, authentication, or side effects, the behavioral burden is only partially met.

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 the endpoint front-loaded and no filler. It efficiently communicates the operation, the returned information, and the usage context in one line.

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, the description gives a reasonable high-level picture of when to use it and what it returns. However, there is no output schema, and terms like 'routable DIEM' are unexplained, so an agent may lack enough context to interpret the response 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 input schema already provides 100% coverage for the single optional parameter, max_price_cents, including its meaning and range. The description itself adds no parameter-specific detail, so the baseline schema coverage is sufficient.

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 a GET operation on /v1/capacity and states that it returns 'routable DIEM and price bands,' which conveys the tool's resource and purpose. It does not explicitly contrast with sibling tools like funding_instructions or set_max_price, but the verb and resource are enough to distinguish it.

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

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

The phrase 'before funding or spend decisions' provides a clear contextual trigger for when this tool should be used. It does not name alternatives or state when not to use it, so it falls 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?

No annotations are provided, so the description carries the behavioral burden. It discloses the HTTP method and endpoint, the one-time call behavior, and the two possible response forms (JSON status or delivered MP4). This is reasonably transparent for a status-retrieval tool, though it omits error and authentication 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 compact sentence that front-loads the endpoint, call count, and response type. Every word contributes useful information and there is no redundant 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 one-parameter status tool with no output schema, the description adequately explains what the tool does, how to invoke it, how many times to call it, and what it returns. It could be slightly more complete by naming sibling alternatives, but it is sufficient for correct invocation.

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

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

There is only one parameter and the schema already documents it fully, including its source context from video_queue/generate_video. The description adds no additional parameter-level meaning, but none is needed given the complete schema coverage.

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

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

The description clearly identifies the action and resource: it retrieves video generation status via POST /v1/video/retrieve and returns either JSON status or a delivered MP4. This conveys the core purpose well, though it does not explicitly differentiate itself 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' gives useful guidance that this is a single status check rather than a polling operation, and the schema ties queue_id to video_queue/generate_video. However, it does not explicitly name alternatives or state when another tool such as wait_for_video should be preferred.

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 communicates that the operation is a read-only GET, returns a list or a single public row, and exposes live model ids that can change over time. It doesn't describe the exact response shape or pagination, but for a simple retrieval tool the disclosed behavior is sufficient.

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

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

Two sentences, no filler. The primary purpose and HTTP verb are front-loaded, the optional parameter behavior is stated compactly, and the anti-hardcoding warning is a single clear directive. Every clause earns its place.

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

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

For a tool with one optional parameter and no output schema, the description covers everything an agent needs: when to use it, how the parameter changes behavior, what kind of object is returned, and the critical constraint against hardcoding. Nothing essential 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?

The schema provides 100% coverage for the single optional id parameter, so the baseline is 3. The description adds value by explaining the behavioral consequence of providing id ('retrieves one public row') and clarifying that the single-row object matches the object found in the list. This goes beyond the schema's bare parameter description.

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

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

The description opens with 'GET /v1/models — resolve a live model id before inference,' which names a specific verb (resolve), a specific resource (model id via the models endpoint), and its use case (before inference). This clearly distinguishes it from sibling tools like chat_completions or generate_image, which consume model ids rather than listing 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 phrase 'resolve a live model id before inference' tells the agent when to use this tool: ahead of inference calls, to obtain a current id. 'Do not hardcode model ids' adds a concrete usage rule. It does not explicitly name alternatives or state when not to use it, but the purpose is focused enough that this is only a minor gap.

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. The description explicitly states it performs a 'GET' and 'recovers' data, indicating a read-only operation with no mention of destructive side effects. It also clarifies what it returns (cost/trace). For a simple retrieval tool, this is transparent and adequate, though it does not discuss error handling or authentication requirements, which are not critical for this simple GET.

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

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

The description is a single, concise sentence that front-loads the essential information: HTTP method, resource path, and purpose. There is no redundancy or fluff. It efficiently communicates the tool's core function and input requirement.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides sufficient context. It states what the tool does and the input needed. It could mention that the support_reference must be from a prior call, but that is already in the schema description. It does not explain what the 'cost/trace' response looks like, but without an output schema that is not strictly required. Overall, it is complete for an agent to call it correctly.

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

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

Schema description coverage is 100%: the schema already fully describes 'support_reference' as 'UUID support reference from a prior call.' The description adds no additional meaning about the parameter beyond what the schema provides. According to the calibration, when schema coverage is high, the baseline is 3, and the description does not augment the parameter semantics further.

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 HTTP verb (GET) and resource path, and specifies the purpose: 'recover cost/trace for a prior request.' This is a specific verb+resource combination that distinguishes it from siblings like get_generation_status (which focuses on generation status) and get_capacity (which likely deals with capacity). An agent can immediately understand what this tool does and how it differs.

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

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

The description implies usage: when you have a support_reference from a prior call and need its cost/trace. However, it does not explicitly mention alternatives or provide exclusions. With 17 sibling tools, it would be beneficial to state when this tool is preferred over others (e.g., when a support_reference is available). The guidance is present implicitly but not made explicit.

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

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

The description discloses two important behaviors: it lists only 'active' keys and it never returns plaintext keys, only metadata. Since no annotations are provided, the description carries the full burden, and it covers the key security aspect. It does not mention side effects or response format, but for a read-only list operation, this is sufficient.

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

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

The description is a single, dense sentence that leads with the HTTP method and endpoint, then states the action and a critical constraint. Every word earns its place, and there is no redundant 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 parameterless list operation, the description covers the essential purpose and a key restriction (no plaintext). It does not specify the exact metadata fields or response structure, but given the tool's simplicity and the absence of an output schema, the description is adequate for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the schema provides no semantics. The description adds context about the output (metadata, not plaintext), which informs what the tool returns. With the baseline for 0 params being 4, this is a solid score given the description complements 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 states a specific action ('list') and resource ('active API key metadata'), and clearly distinguishes from mutation siblings like create_key and revoke_key by emphasizing it only lists metadata and never plaintext. This is a clear, specific purpose with no ambiguity.

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

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

The description implies when to use this tool – when you need to view active API keys – but does not explicitly contrast it with alternatives or state when not to use it. However, given the sibling set includes create and revoke operations, the purpose is unambiguous enough that an agent can infer usage without further 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?

Annotations already mark the tool as destructive, but the description adds that the deletion is irreversible and may revoke the key powering the current MCP session. This is meaningful behavioral context beyond the structured 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 extremely concise, front-loads the action and resource, and includes only impactful warnings. Every element earns its place 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 single-parameter destructive operation with annotations already covering mutability, the description provides the essential context: irreversibility and risk to the active session. Not describing response behavior is a minor gap given the absence of an output schema and low complexity.

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

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

The input schema fully documents the id parameter as a UUID with 100% coverage, so the description does not need to compensate. The description adds minimal parameter-specific meaning, matching the baseline for well-covered 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?

States the precise action as DELETE /v1/agent/keys/{id} and identifies the resource as an agent key. The 'irreversible' qualifier and the explicit warning make it distinct from sibling tools like create_key and list_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?

The warning not to revoke the key used by the MCP session gives important context, but the description does not explicitly state when to use this tool versus alternatives or provide broader exclusion conditions. Usage is implied rather than fully specified.

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 cover idempotency and non-destructiveness, and the description adds the important caveat 'Does not auto-apply,' which is genuinely useful behavioral context beyond the structured fields. It does not cover authorization or failure modes, but with annotations present the bar is lower.

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?

Every word earns its place: endpoint, action, range, usage trigger, and a behavioral caveat are packed into two short sentences with no fluff. The most important routing information 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 single-parameter setter with no output schema, the description is nearly complete: it identifies when to call it, what it changes, and a key caveat. A minor gap is that it doesn't explain how cheapest_posted_cents should map to the parameter value, but this is inferable from the 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%, and the schema already explains the parameter as 'Buyer ceiling in cents per DIEM dollar, 30-80.' The description repeats the range but adds no new semantic detail about the parameter itself, so the 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?

States a specific action (PATCH endpoint to raise/lower ceiling) and the resource (/v1/agent/max-price). The 30-80 range removes ambiguity about valid scope, and the description is distinct from all sibling tool names.

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?

Gives an explicit trigger condition: 'Use when tools return no_eligible_supply with cheapest_posted_cents.' It does not name alternatives or state when not to use it, but the condition is specific enough to route an agent 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?

With no annotations, the description carries the full burden. 'Optional cleanup' hints at side effects but does not say whether it deletes data, frees capacity, is idempotent, or requires preconditions. The actual behavior after calling retrieve is not disclosed.

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 with no filler words and easy to scan. It loses a point only because the brevity sacrifices semantic completeness, though that is largely a completeness concern.

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 lifecycle tool with no annotations and no output schema, the description leaves major gaps: side effects, return value, idempotency, and relationship to video_retrieve are all unstated. The single parameter is covered, but the operation itself is under-specified.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds no parameter meaning beyond the schema. It does not reinforce that queue_id is the identifier returned by video_queue or generate_video.

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 endpoint and says 'optional cleanup after retrieve,' which gestures at the action but never states what 'complete' actually does or what resource is affected. It does not clearly distinguish itself from siblings like video_retrieve or wait_for_video beyond the vague 'after retrieve' timing.

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 some usage context by indicating the tool is optional and should follow retrieve. However, it gives no when-not-to-use guidance, no alternatives, and no conditions that would make cleanup necessary or unnecessary.

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, readOnlyHint=false, and idempotentHint=false, so the bar for added context is lower. The description adds 'paid' (cost implication) and 'enqueue' (queued/async behavior), which are useful. However, it does not clarify what 'settle' actually does, what side effects occur, or what gets destroyed, leaving the most consequential behavior vague.

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 very short and front-loads the endpoint, payment semantics, and the preferred alternative. Every phrase contributes something, though 'settle+enqueue' is compressed to the point of being cryptic. Still, there is no wasted text.

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

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

For a paid, non-idempotent, destructive-hinted operation with six parameters and no output schema, this description is under-specified. It does not explain return values, job tracking, polling via wait_for_video/video_retrieve, or how to construct the request. The routing hint is useful, but it cannot compensate for the missing operational 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 only 17%, and the description adds no parameter-level meaning. It does not mention model, prompt, duration, resolution, aspect_ratio, or audio, and the only schema description is for model. With six parameters and almost no schema coverage, the description leaves the agent without the information needed to construct a valid call.

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 as 'paid settle+enqueue' on the video queue, which conveys a specific operation, and explicitly distinguishes it from generate_video by saying 'Prefer generate_video for agents.' The phrase 'settle+enqueue' is somewhat jargon-heavy, but the resource and verb are clear enough to separate it from 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 gives direct routing guidance: 'Prefer generate_video for agents' names the alternative and the condition under which it should be chosen. It does not fully explain when video_queue itself should be used, but the paid/queue framing implies a non-agent, payment-settling workflow.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'no settle, no job', which discloses that this operation does not create or commit to a job, implying a read-only or estimation nature. However, it does not reveal side effects, authentication requirements, rate limits, or response behavior. This is minimal but valuable context, yet insufficient for full 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 a single sentence and is appropriately short, front-loading the operation and its key distinction. However, the brevity sacrifices essential details, making it terse rather than effectively structured. While every word earns its place, the description is under-specified, so it is concise but not well-balanced.

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

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

The tool has 6 parameters, low schema coverage, and no output schema. The description does not explain what the tool returns, how parameters should be used, or how it integrates with sibling tools beyond the 'before queue' hint. It does not even outline the decision logic clearly. An agent would lack the information needed to call this tool correctly, so it is highly incomplete.

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

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

Schema description coverage is only 17%, meaning the schema provides almost no parameter explanations. The description must compensate but does not mention any parameters, their format, constraints, or usage semantics. It focuses only on the operation's nature, leaving all six parameters (especially the required 'model' and 'prompt') unexplained. This is a critical gap.

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 a video quote endpoint, with 'POST /v1/video/quote' as the verb and resource. It immediately distinguishes it from related tools by stating 'no settle, no job', which sets it apart from video_queue and video_complete. The operation is positioned as a pre-check ('before queue'), making its purpose specific and unambiguous.

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

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

The description provides clear usage context by indicating this should be used 'before queue', implying it is a prerequisite step to video job submission. It also hints at the decision factors (clears_now vs price ceiling vs funding) that should be checked. However, it does not explicitly name alternatives or state conditions under which to avoid this tool, so it lacks explicit exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the operation has side effects, whether it requires special permissions ('power-user' hints but doesn't specify), whether it consumes the queue, or what the response contains. The word 'poll' suggests a read-only pattern, but this is not explicit.

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

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

The description is compact and front-loaded with the endpoint and a rough functional label. It avoids filler, though 'power-user' is somewhat vague and the terse style sacrifices useful context.

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

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

There is no output schema, and the description does not explain what the tool returns, such as status fields or media URLs. Given the many sibling tools focused on video generation and status, the description is not complete enough for an agent to confidently decide when to call this tool and how to interpret its response.

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 queue_id, and the schema already explains that it comes from video_queue or generate_video. The description adds no additional semantic meaning about the parameter, 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 a specific action ('retrieve'), the resource ('video'), and the purpose ('status/media poll'). It is clear enough to understand the tool's core function, though it does not explicitly contrast it with sibling tools like get_generation_status 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 phrase 'status/media poll' implies this tool is for polling video status or media by queue_id, which provides some usage context. However, it gives no explicit guidance about when to choose this over get_generation_status, wait_for_video, or other sibling tools, and no exclusion criteria.

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

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

With no annotations, the description carries the full burden and provides useful behavioral context: it polls until a terminal state and backs off on HTTP 502. It does not disclose handling of other error types or what occurs when max_polls is exhausted, but these are secondary for a poll 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 with no filler. The first sentence states the core purpose and terminal condition; the second adds a valuable retry behavior. Every word contributes to the agent's understanding.

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 is adequate for a simple poll loop: it states purpose, terminal conditions, and one error-handling behavior, with parameter defaults in the schema. However, it omits what 'delivered' or 'failed' map to in the response, behavior when max_polls runs out, and there is no output schema to explain return values. These gaps matter for an agent deciding whether this is the right 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 67%; max_polls and interval_ms already have descriptions. The description's 'Poll ... until ...' implies queue_id identifies the video retrieve operation, which adds some context to the undocumented parameter, but it does not fully compensate for the missing queue_id 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 states a specific action ('Poll video retrieve') and a terminal condition ('until delivered or failed'). It clearly implies the tool waits on the video retrieval process, distinguishing it from the direct video_retrieve sibling, though it doesn't explicitly name the alternative.

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

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

Usage is implied: the agent should call this when it wants to wait for a previously requested video retrieval to finish. However, there is no explicit guidance on when to prefer this over direct polling of video_retrieve or other siblings, and no exclusions or alternatives are named.

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