TestMyVibes

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

Discloses that publishAs overwrites existing files, that the tool is charged on success only, and returns a 24h signed URL. Annotations (readOnlyHint=false, destructiveHint=false) are consistent; description adds significant behavioral context beyond 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?

Two sentences: first defines functionality and output, second lists use cases and pricing. No redundant words; all information is front-loaded and essential.

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

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

Given the tool's complexity (multi-segment video assembly), the description fully covers behavior, return value, pricing, segment options, and use cases. Output schema exists for further details, so no gaps remain.

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

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

Schema coverage is 100%, but description adds value by grouping segment types (a, b, c) and explaining the current unused status of titleText. It also clarifies defaults for videoStartSec and videoEndSec and the purpose of publishAs and outputAspect.

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

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

The description clearly states it stitches video clips and voiceover into a single MP4, distinguishes from sibling tools like submit_test and synthesize_voiceover, and specifies the output format (Spaces, 24h signed URL).

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

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

Explicitly lists use cases: marketplace catalog submissions, tutorial videos, and when you'd otherwise use screen-record + iMovie. Provides context for each segment type (a, b, c) and notes pricing (charged on success only).

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 indicate readOnlyHint=false and destructiveHint=false, but the description adds valuable behavioral details: paid credit jobs are refunded once, internal-use runs cancel without refund. This goes beyond what annotations provide.

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

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

Three sentences, each earning its place: states what it does, specifies statuses, explains refund policy, and gives a use case. No redundancy or extraneous text.

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

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

Given the tool's simplicity (2 parameters, output schema exists), the description covers purpose, usage context, and behavioral nuances. It does not need to detail return values since an output schema is present.

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

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

Schema coverage is 100%, so baseline is 3. The description references jobId by noting its source (submit_test, etc.) and reason as 'Optional short reason', but this largely repeats schema information without adding significant new 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 title and description clearly identify the verb (cancel) and resource (test), specifying the applicable statuses (pending, claimed, in_progress, expired). It is distinct from sibling tools which cover different operations.

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

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

The description provides a concrete use case ('when a site needs to be published or reconfigured before the test should continue') and explains behavior for paid vs internal-use jobs. It does not explicitly state when not to use, but the 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?

The description adds behavioral details beyond annotations: pricing model, output URL validity (7 days), and non-fatal click path failure. Annotations lack destructive or idempotent hints, but the description compensates well. No contradiction.

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

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

The description is a single well-structured paragraph. It front-loads the core action, then covers optional features, pricing, use cases, and output. Every sentence adds meaningful information without redundancy.

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

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

The description fully covers the tool's capabilities, including optional click paths, pricing, output format, and use cases. With an output schema present, the mention of signed Spaces URLs is sufficient. No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by specifying viewport resolutions (e.g., iPhone 14 for mobile), default settleMs behavior, and non-fatal nature of clickPaths. This goes beyond the schema descriptions.

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

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

The description clearly states the tool drives headless Chromium to capture screenshots of a URL for specified viewports (mobile, tablet, desktop). It distinguishes itself from siblings like 'assemble_demo_video' or 'submit_test' which serve different 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?

The description explicitly lists use cases: marketing screenshots, design QA, regression-watch baselines. It also mentions pricing per viewport and the requirement that the URL be publicly reachable. However, it does not explicitly state when not to use it or name alternative tools for full AI tests.

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 claims 'Read-only validation' but the annotation readOnlyHint is false, a direct contradiction. The description adds useful context (does not return password) but the contradiction undermines trust. Per rules, a contradiction forces a score of 1.

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, directly stating purpose and a key behavioral constraint. No extraneous information; 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?

Given the contradiction, missing parameter explanations, and that the tool has an output schema (requiring no return value doc), the description is insufficient for correct invocation. It omits parameter semantics and contradicts annotations, leaving the agent with incomplete guidance.

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 0%, and the description does not explain the two parameters (targetUrl, testIdentityId). It fails to add meaning beyond the schema, leaving the agent unclear on how to correctly 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 this tool performs 'Read-only validation' for a managed identity, listing specific checks (ownership, expiry, authorization, credentials) and explicitly noting it does not return the password. This distinguishes it from sibling tools like create_test_identity, delete_test_identity, and renew_test_identity.

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 used for validating a managed identity without modifying it, which contrasts with create/delete/renew siblings. However, it does not explicitly state when not to use it or provide alternative tool names for specific scenarios.

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

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

The description discloses atomicity, return of checklist and SLA deadline, ownership transfer, and expiration behavior. Annotations already indicate mutation, but the description adds valuable context beyond what annotations provide.

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

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

The description is three sentences, front-loaded with the key action, and contains no unnecessary words. It efficiently conveys purpose, usage, and behavior.

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 core behavior, return values, and workflow (claim, submit, expire). It does not mention error scenarios (e.g., job already claimed), but overall it is complete for a claim tool.

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

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

Schema coverage is 100%, and the schema already describes the jobId parameter ('from list_available_jobs'). The description does not add additional parameter semantics beyond the schema, meeting the baseline.

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

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

The description clearly states the tool's purpose: 'Atomically take ownership of a pending job.' It uses a specific verb+resource and distinguishes from siblings like list_available_jobs and submit_job_results by explaining the workflow.

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 the tool (to claim a pending job) and references submit_job_results as the follow-up. It does not explicitly exclude alternatives, but the 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?

Disclosure goes beyond annotations: states synchronous charge and credit. Annotations indicate not read-only, not idempotent, not destructive; description aligns. No contradictions.

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

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

Two sentences, front-loaded with key context and action. No unnecessary words. Efficiently conveys purpose and flow.

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

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

Covers main behavioral flow and parameter linkage, but lacks detail on error conditions or prerequisites for buyer/payment_data. Output schema exists, so return values are covered.

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 33%; description adds meaning for checkout_session_id (links to top_up_credits). Other parameters (payment_data, buyer) rely mostly on schema descriptions. Partial compensation.

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

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

The description clearly states the tool completes checkout after user clicks Pay, using SPT, charging via Stripe, and crediting TMV account. It distinguishes from sibling top_up_credits by referencing its output.

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

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

Specifies caller context (ChatGPT/agent runtime) and timing (after Pay click). References prerequisite top_up_credits via checkout_session_id. No explicit exclusions, but context is clear.

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

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

Annotations show readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds context: the tool is a creation operation that returns a projectId for later use, and it does not contradict annotations. It adds behavioral details beyond the flags.

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

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

Two sentences, front-loaded with purpose, zero waste. 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?

The tool is simple with three parameters and an output schema; the description adequately covers the core operation and return value. However, it lacks any reference to related tools (e.g., update_project, delete_project) which would improve completeness for an agent.

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

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

Schema coverage is 100% with clear descriptions for all three parameters (url, name, defaultJobType). The description does not add new meaning beyond the schema, but it does contextualize parameters by mentioning the returned projectId and linkage to submit_test. 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 states a specific verb ('Register') and resource ('a new site for testing'), and uniquely mentions the return value ('projectId') that differentiates it from sibling tools like list_projects or submit_test.

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

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

No guidance on when to use or not use this tool versus alternatives. Among 50+ siblings, there is no mention of when to create vs. list, update, or submit, leaving the agent to infer usage from name alone.

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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. Description adds that the identity is retained, has expiry and auto-renewal, and credentials can be saved on first signup. No contradictions. Provides good behavioral context beyond 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?

Two sentences only; first sentence defines purpose and scope, second sentence provides usage guidance and optional parameter behavior. Every sentence adds value with no redundancy or fluff.

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

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

Covers purpose, usage, and key parameter behavior. References submit_test for additional context. Output schema exists (not shown) which likely details return value. Could mention output briefly, but overall sufficient for selection and 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 has 75% description coverage (6 of 8 parameters described). Description adds critical semantics: explains the interplay between username/password omission and submit_test, and scoping of customerSite. This goes beyond schema descriptions, enhancing understanding of parameter relationships.

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

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

Clearly states the tool creates a managed test identity with persistent inbox and persona, scoped to account and customer-site origin. Differentiates from sibling tools like check_test_identity and renew_test_identity by specifying its use for multi-run/multi-user tests requiring history persistence.

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

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

Explicitly states when to use: before multi-run or multi-user tests requiring account history survival. Provides alternative behavior when username/password are omitted, referencing submit_test with identityMode='reuse'. No sibling tools are named for exclusion, but the 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?

The description reveals behavioral traits beyond annotations, such as the earnings split (75% worker, 25% TMV), price constraints (whole number, ≥15), and the ceiling condition for uncapped accounts. This adds significant value without contradicting annotations.

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

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

The description is concise (three sentences), front-loaded with the core purpose, and every sentence adds necessary information without fluff. It efficiently communicates the tool's usage, constraints, and business rules.

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

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

Given the tool's complexity (5 parameters, output schema exists), the description covers critical business logic: pricing, earnings split, worker eligibility conditions, and what customers see. This is sufficient for an agent to invoke the tool correctly.

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

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

Schema description coverage is low (20%), and the description partially compensates by explaining pricing rules for 'creditsCharged' and customer visibility of 'name', 'description', 'creditsCharged', and 'estDurationHr'. However, 'specialties' is left unmentioned, and required parameters like 'name' and 'description' lack detail beyond schema.

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

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

The description clearly states the tool's purpose: 'Add a named, priced offering to your worker menu.' It specifies the verb 'Add' and the resource 'offering', distinguishing it from sibling tools like 'list_worker_offerings'.

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

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

The description provides clear context on when to use (to publish a service offering) and includes constraints like minimum price and ceiling for new workers. However, it does not explicitly state when not to use or mention alternative tools, losing one point.

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 adds behavioral context beyond annotations by explaining that the tool only affects TMV's retained credentials and does not guarantee deletion inside the customer app. This clarifies the scope of the action, which annotations alone do not 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 concise (two sentences) and front-loaded with the core action, followed by a critical caution. Every sentence adds value with no redundancy.

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

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

Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description adequately covers the tool's purpose, scope, and limitations without needing to explain return values.

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

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

The input schema has one parameter (testIdentityId) with no description in the schema (0% coverage). While the parameter name is self-explanatory, the description does not add any additional meaning or usage details beyond the schema.

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

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

The title and description clearly state the tool deletes TMV's retained credentials for a managed test identity, and explicitly distinguishes what it does not do (customer-site cleanup), differentiating it from siblings like check_test_identity or create_test_identity.

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

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

The description provides explicit guidance on when to use this tool (to delete TMV credentials) and when not to rely on it (for customer-site cleanup), with a suggested alternative: 'run an account-deletion test first.'

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 claims the tool is 'Idempotent,' but the annotations set 'idempotentHint' to false, creating a direct contradiction. While it correctly identifies the tool as destructive, the contradiction undermines transparency.

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

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

The description is two sentences long, with the first sentence immediately stating the core action. No extraneous information, and it is well-structured for quick parsing.

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

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

The description covers the tool's purpose and usage context, but the contradiction regarding idempotency introduces significant confusion. The existence of an output schema partially mitigates the need for return value details, but the misleading claim reduces completeness.

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

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

With 100% schema description coverage and a single parameter 'cardId' clearly described as 'The test card ID returned by provision_test_card,' the description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('Cancels') and resource ('card'), and distinguishes the tool from siblings like provision_test_card and list_test_cards by focusing on cancellation. The mention of idempotency and auto-freeze provides additional clarity.

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

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

The description explicitly advises calling this tool to freeze immediately after a successful checkout test, and notes that auto-freeze handles cards past their 24h expiry. This provides clear guidance on when to use the tool, though it does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details about what data is returned (per-leg breakdown, bug counts, threshold proximity, time remaining) and notes it is free. This expands beyond annotations without contradiction.

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

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

Two sentences: first lists return content, second gives usage advice and cost note. No wasted words, front-loaded with key info.

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

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

Given the simple input (one param) and presence of output schema, the description covers purpose, return values, usage alternative, and cost. It is complete for the tool's complexity.

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

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

Schema coverage is 100% with a detailed description of comboId. The tool description does not add further parameter semantics, so baseline score of 3 is appropriate.

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

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

The description clearly states it provides combo status with per-leg breakdown, cumulative bug counts, pause threshold proximity, and estimated time remaining. It distinguishes itself from polling individual jobIds, addressing the sibling context.

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

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

Explicitly advises 'Use this instead of polling N individual jobIds for a combo.' This gives clear when-to-use guidance. No explicit exclusions are given, but the advice is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's a safe read. The description adds value by detailing the return components (total valid credits, raw batches, warning flag) and the condition for the warning flag, providing behavioral context beyond the annotations.

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

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

The description is two sentences long, with the first sentence front-loading the purpose. It contains no filler words and every sentence adds value.

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

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

For a no-parameter tool that returns credit balance info, the description is fully adequate. It explains what is returned and mentions the threshold condition. Given the presence of an output schema (not shown), the description does not need to elaborate on the return format.

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

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

There are no parameters, so the description does not need to add parameter semantics. With zero parameters, the baseline is 4. The description focuses on the output details, which is appropriate.

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

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

The description clearly states the tool gets the credit balance for the current account. It uses a specific verb+resource pattern and distinguishes itself from the sibling tool 'top_up_credits' which performs a different 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 mentions a threshold condition ('below the threshold a typical test costs') which hints at when checking is useful, but does not explicitly state when to use this tool versus alternatives or when not to use it. Some guidance is implied by context with 'top_up_credits'.

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 readOnly, idempotent, and non-destructive. The description adds that it is a reference guide with no side effects, but does not reveal any additional behavioral nuances beyond what annotations imply.

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

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

Three sentences, each earning its place: describes content, advises when to use, and provides a URL. No wasted words.

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

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

For a zero-parameter, read-only information tool with an output schema, the description covers content, audience, timing, and a reference URL. No gaps remain.

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

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

No parameters exist; schema coverage is 100%. The description adds no parameter information, which is unnecessary and appropriate. The tool is self-contained.

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

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

The description clearly states it returns the canonical integration guide for TMV in a coding-agent context, listing specific topics covered. This uniquely identifies the tool among siblings like 'submit_test' or 'get_test_results'.

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

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

Explicitly advises to call this tool first if new to a project, saving debug time. This provides clear when-to-use guidance and differentiates from all other tools.

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

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

Annotations indicate readOnlyHint=true and idempotentHint=true. The description adds context that the tool generates a URL (a creation action that is read-only from the caller's perspective) and returns a hosted link. No contradictions; the description clarifies the apparent creation aspect.

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

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

Two sentences, front-loaded with the core action and purpose. Every sentence adds value: the first explains the outcome, the second covers the optional workerKind parameter. No redundant or extraneous 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?

The description covers the tool's purpose, key parameter guidance, and return type (hosted URL). An output schema exists, so return value details are handled there. It does not discuss prerequisites or failure modes, but for a simple URL-generation tool this is sufficient.

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

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

Schema coverage is 100%, with descriptions for both parameters. The description reinforces the workerKind parameter's purpose but adds no additional syntax or behavioral details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool mints a Stripe Connect onboarding URL for bank account linking and payout setup. The verb 'Mint' combined with the title 'Get Stripe Connect onboarding link' makes the resource and action unambiguous. No sibling tool serves a similar purpose, so differentiation is not an issue.

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

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

The description explicitly explains when to pass workerKind='ai' vs 'human', providing concrete guidance for the primary use case. It does not mention when not to use the tool or suggest alternatives, but given the tool's unique function among siblings, this is acceptable.

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, idempotentHint, and destructiveHint. Description adds value by detailing the response content (per-role status, signals, shared state) without contradicting 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?

Two sentences, concise and front-loaded with key information. No superfluous text.

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

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

Given low complexity (1 param, no enums) and presence of an output schema, the description adequately covers what the tool returns. No gaps.

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

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

Schema description coverage is 100% for the single parameter sceneId, but the description does not add any extra meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states 'Single-call view of every role in a scene' with specific items returned (job status, signals, shared state). It distinguishes from polling individual jobIds, which is a clear differentiation from sibling tools like get_job_status.

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

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

Explicitly states 'Use instead of polling N individual jobIds,' providing a direct usage scenario and implicit when-not-to-use. This is clear guidance for the agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to reiterate these. It adds value by disclosing the pending status behavior, which is beyond the annotations. No contradiction.

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

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

Two sentences with no wasted words. The first sentence states the purpose and components, the second covers the pending edge case. Front-loaded and efficient.

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

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

Given the tool's simplicity (1 param, output schema present, annotations complete), the description covers the primary use case and a key edge case. No obvious gaps; the output schema handles return details.

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

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

Schema description coverage is 100% with jobId described as 'The job ID.' The description adds context that it refers to a test job (completed test), giving semantic meaning beyond the schema. This is a slight improvement over baseline 3.

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

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

The description clearly states it fetches full results (checklist outcomes, report summary, AI analysis) for a completed test, distinguishing it from sibling tools like get_test_status which only returns status. The verb 'Fetch' and resource 'full results' make the purpose explicit.

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

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

The description implies usage when detailed results are needed by specifying 'full results' for a 'completed test', and handles the edge case of a pending test. However, it does not explicitly mention when not to use it or alternatives like get_test_status.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds no additional behavioral context (e.g., whether it polls, whether it errors on invalid jobId).

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

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

Single sentence, no fluff, efficient. Front-loaded with the core action.

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

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

For a simple read-only tool with annotations and output schema, the description is adequate but minimal. It lacks context about possible status values or how to interpret results, but output schema covers return.

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

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

With 100% schema coverage, the baseline is 3. The description does not add extra meaning to the jobId parameter beyond what the schema already provides.

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

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

The description clearly states the action (look up) and the resource (current status of a submitted test job). It distinguishes from sibling tools like get_test_results, though not explicitly, by focusing on status rather than results.

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

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

No guidance on when to use this tool versus alternatives such as get_test_results or cancel_test. The description does not provide context for appropriate usage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds value by detailing the returned data (e.g., Stripe Connect status, auto-payout threshold check) without contradicting 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?

Two concise sentences with no filler, front-loading the key action and results. Every sentence earns its place.

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

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

Given an output schema exists (not shown) and the tool has no parameters, the description fully covers what the tool returns and its context. It is sufficient for an agent to understand the tool's purpose and output.

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

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

The input schema has 0 parameters with 100% coverage, so the description needs no parameter detail. Baseline for 0 parameters is 4, and the description adds no redundant info.

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

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

The description clearly states the tool shows the calling worker's payout balance with specific components (lifetime earned, paid-out, pending) and additional status info, using a specific verb 'show' and resource 'worker's payout balance'. It distinguishes itself from all sibling tools, none of which relate to earnings.

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

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

The description implies usage for the calling worker's balance but does not explicitly state when to use or when not to use. There are no obvious alternatives among siblings, but guidance on when this tool is appropriate vs. other tools is lacking.

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 indicate read-only and non-destructive behavior. The description adds useful context: it returns only pending jobs, excludes owned and claimed, and orders by freshness. This supplements the annotations well.

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

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

The description is concise with three efficient sentences, no redundancy, and key information front-loaded. Every sentence adds value.

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

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

Given the output schema exists, the description adequately covers the tool's purpose, behavior, and context. It explains the relevant exclusions and ordering, making it complete for a list tool.

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

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

Schema description coverage is 50%, with maxResults lacking description. The description adds no further parameter details beyond what is in the schema. For the jobType parameter, the description merely restates the schema's 'Filter to a single job-type label' without additional clarification.

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

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

The description clearly states the tool returns pending jobs the worker can pick up, specifying exclusions (owned by caller, already claimed) and ordering (freshest first). It effectively distinguishes from siblings like list_my_claimed_jobs.

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

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

The description explains what the tool does and its filtering, but does not explicitly contrast with alternatives. However, sibling tool names and the exclusion criteria imply when to use this tool (to find jobs to claim) versus others.

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

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

The description aligns perfectly with annotations (readOnlyHint, destructiveHint, idempotentHint) and adds extra behavioral context: 'charges nothing.' It also details the nature of the data returned without contradicting any 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 slightly verbose but front-loaded with the main purpose. Every sentence adds value, detailing what information each combo entry contains. It could be slightly more concise but remains clear.

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

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

Given the tool has no parameters and an output schema exists, the description sufficiently covers the tool's purpose, behavior, and return details. It explicitly states it is read-only and free, making it easy for an AI agent to understand when and why to use it.

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

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

The input schema has no parameters, so the description does not need to explain parameter semantics. It effectively describes the output, which is the whole catalog, compensating for the lack of parameters.

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

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

The description clearly states the tool 'Returns the full combo catalog' and lists specific attributes included, such as legs, estimated cost, duration, and bug-threshold. It effectively distinguishes from siblings like get_combo_status which retrieves a single combo.

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?

While the description implies it is safe to call anytime by stating 'Read-only; charges nothing,' it does not explicitly mention when to use this tool versus alternatives like get_combo_status. However, the context of being a catalog listing 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?

Annotations already indicate readOnly, idempotent, and non-destructive. The description adds value by stating exactly what is returned (fields) and how it integrates with top_up_credits, going beyond 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?

Two sentences, each earning its place: first states purpose and output, second provides usage guidance. No wasted words, front-loaded with key information.

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

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

With no parameters and an output schema present, the description fully explains what the tool does, what it returns, and how to use its result. No gaps in context.

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

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

There are no parameters, so the description does not need to explain them. It adds context about the tool's purpose and output, matching the baseline of 4 for zero-parameter 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 lists credit packs for purchase, specifies the returned fields (pack index, credit count, USD price, per-credit cost), and links to top_up_credits, distinguishing 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 explicitly tells the agent to use the returned packIndex with top_up_credits, providing clear usage context. It does not explicitly list when not to use it, but the sibling context makes it 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?

Adds context beyond annotations: explains the return fields, the free nature, and the number of presets. No contradictions with annotations. Minor gap: no mention of potential limits or caching.

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

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

Two sentences, front-loaded with purpose, parameter guidance, and cost. Every sentence adds value with no repetition.

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

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

For a simple list tool with one parameter and an output schema, the description covers purpose, parameter options, cost, and usage context completely. No missing information.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explicitly linking the parameter to the use case and clarifying the count difference (15 vs 131).

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

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

The description clearly states it returns device presets for use in submit_test, submit_test_batch, and retest_job, with specific fields. It distinguishes from sibling tools by linking to the submission 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?

Provides clear guidance on when to use featuredOnly=true vs false, and mentions cost implications. Could be more explicit about when not to use, but the context is sufficient.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds ordering ('most recent first') and staff-only access, providing useful context without contradicting 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?

Three concise sentences, front-loaded with the core purpose ('Staff-only triage view'), no wasted words. Efficient and easy to parse.

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

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

Covers key aspects for a list tool (purpose, filters, ordering) and hints at a use case. An output schema exists, so return format is handled. Lacks pagination details but overall adequate.

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

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

Schema coverage is 40% (only status and sinceIso described). The description mentions filtering by status, category, and since, adding meaning to those parameters, but omits limit and severity, so it 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 clearly states it lists feedback items with optional filters, noting it's staff-only. It is specific but does not explicitly differentiate from sibling tools like 'submit_feedback' or 'update_feedback', though the context makes it distinct.

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

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

Provides a concrete usage hint: 'Use status="new" at session start to see what came in unaddressed.' Lacks explicit when-not-to-use or alternative tools, but the hint adds practical value.

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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds value by disclosing auto-expiry (30 days after last use), expiry bump on retest, and entry contents (personaId, customer site, credential expiry). No contradictions.

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

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

Two sentences, no waste. First sentence front-loads purpose and conditions; second adds critical details (expiry, retest behavior). Every sentence earns its place.

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

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

With output schema present, description covers key behavioral aspects (expiry, retest interaction) and entry structure. Annotations cover safety. No gaps identified.

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

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

Tool has no parameters; schema coverage is 100%. Description explains output content which serves as implicit parameter documentation. Baseline for 0 params is 4.

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

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

Description clearly states it returns kept-alive personas with precise conditions (created via submit_test with keepTestAccount=true and signed back in). Distinct from sibling tools like list_test_identities.

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

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

Implies usage context by explaining returned personaId can be passed as existingPersonaId for retesting. No explicit alternatives or when-not-to-use, but straightforward for a parameterless list 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the exact states of jobs included (claimed, not yet submitted, in-progress). No contradiction.

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

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

The description is a single, focused sentence that conveys the complete purpose. Every word is necessary and efficiently front-loaded.

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

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

Given the zero-parameter input, rich annotations, and presence of an output schema, the description is fully sufficient. It clearly defines what the tool returns and its scope.

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

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

The tool has zero parameters and schema coverage is 100% (trivially). The description does not need to add parameter details. Baseline 4 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 explicitly states the resource ('jobs this worker holds') and the scope ('claimed but not yet submitted, plus in-progress'). This clearly differentiates from sibling tools like 'list_available_jobs' (which lists open jobs) and 'claim_job' (which claims a job).

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

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

The description implies usage context (checking current workload), but does not explicitly state when to use this tool versus alternatives like 'list_available_jobs' or 'submit_job_results'. No exclusions or conditions are provided.

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

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

Annotations already indicate read-only and non-destructive. The description adds context about locking settings upon submission, though not strictly about the listing behavior itself.

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

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

Three sentences, front-loaded with the main action, no wasted words.

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

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

Given the simple schema and output schema, the description covers purpose, usage, and connection to submit_test, making it fully informative.

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

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

Schema coverage is 100%; description adds value with an example offering structure and explains how parameters filter the offerings, beyond what the schema provides.

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

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

The description clearly states it lists packaged AI tests with service offerings, and contrasts with manual tuning, distinguishing it from sibling list tools.

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

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

The description explicitly says when to use it ('when you want a deterministic, named test product') and contrasts with manual tuning, providing clear context.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds semantic context ('sites under test'), enhancing understanding without contradicting 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?

Single sentence with no unnecessary words. Efficiently conveys the tool's purpose.

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

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

For a simple list tool with no parameters and an output schema present, the description fully covers what the tool does and its scope.

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

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

No parameters exist, so schema coverage is 100%. The description doesn't need to explain parameters; a baseline of 4 is appropriate.

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

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

The description clearly specifies the action ('List'), resource ('projects'), and context ('registered to this account'), distinguishing it from siblings like 'create_project'.

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

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

The description implies usage for viewing all projects under the account. No explicit when-not or alternatives, but the single-sentence clarity suffices for a simple list 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?

The description adds significant value beyond annotations: it reveals that PANs are never returned because they are not persisted, and specifies returned fields (last4, funded amount, status, expiry). This complements the readOnlyHint and idempotentHint 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?

Three sentences with no wasted words: purpose stated first, then critical caveat about PANs, then use case. The structure is front-loaded and efficient.

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

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

Given no parameters and an output schema that presumably documents return fields, the description covers all necessary context: what the tool does, its behavioral constraints, and a concrete use case. It is complete for a simple list view.

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

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

No parameters exist, so schema coverage is 100%. The description does not need to add parameter information, but it provides meaningful context about the return fields, which is incidental to parameter semantics. A baseline of 4 is appropriate.

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

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

The description clearly states it is an audit view of test cards minted by the account, using specific verb 'list' and resource 'test cards'. It distinguishes from sibling tools like provision_test_card (create) and freeze_test_card (modify) by focusing on read-only listing.

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

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

Explicitly states the tool is 'useful for reconciling Stripe Issuing balance against TMV spend', providing clear when-to-use guidance. While it does not explicitly mention alternatives, the context of sibling tools makes its usage context 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that identities are 'owned by this account' (scoping) and 'can be reused' (persistence). These details go beyond the annotations, so the description adds value.

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 that immediately state the purpose and key usage context. No filler or redundant information. Efficient and front-loaded.

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

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

Despite having an output schema (which presumably documents return values), the description omits any explanation of the three input parameters, which are all optional and non-obvious. The tool's filtering capabilities (via customerSite and includeExpired) are critical for correct usage, but not described.

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 parameter schema has 0% description coverage, with three parameters (projectId, customerSite, includeExpired) completely undocumented in the schema. The description does not explain any of these parameters, failing to compensate for the low coverage. Users cannot infer the meaning of these parameters from the description.

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

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

The description clearly states the tool returns managed retained identities and distinguishes it from kept personas by calling them 'first-class successor', which differentiates it from sibling tool list_kept_personas. The verb 'Returns' is specific and the resource is well-defined.

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 over list_kept_personas (for modern identities) and mentions reusability in submit_test and interaction-scene roles, providing clear context. However, it does not explicitly exclude alternatives or list prerequisites, so it's not 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context about the free persona inclusion and billing model for test execution, going beyond the 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?

Three concise sentences, front-loaded with the main purpose, followed by relevant billing details. No wasted words.

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

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

Given the zero parameters and presence of an output schema, the description is complete. It explains what the tool returns and provides billing context, which is sufficient for an agent to understand the tool's purpose and side effects.

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

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

There are no parameters, and schema coverage is 100%. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter 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 clearly states the tool lists monthly subscription plans for managed persistent personas. It distinguishes from siblings like list_test_identities and list_kept_personas, which focus on identities rather than plans.

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 implicitly indicates the tool is used to view subscription plans and pricing, with context on free tier and billing. However, it does not explicitly state when to use it versus alternatives or provide 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat safety. It adds value by detailing the output (bio, tags, employment type, price) and filter behavior, enhancing the agent's understanding of what the tool returns beyond the schema.

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

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

Two sentences, front-loaded with the main action and filter capability, followed by output details. No extraneous information. Every sentence adds value.

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

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

Given the tool has an output schema and annotations covering safety, the description provides sufficient context for typical use. It covers filtering, output fields, and examples, though it omits mention of the limit parameter and pagination behavior. Still, it is adequately complete for a non-mutating listing tool.

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

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

Schema coverage is 67% (2 of 3 parameters described). The description adds context for the specialty parameter with concrete examples ('payments', 'i18n-japanese'), but does not discuss limit or includeInHouse. This partially compensates for the undocumented limit parameter but does not fully cover all parameters.

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

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

The description clearly states the verb 'List', the resource 'active worker offerings', and specifies filtering capability and output fields. It effectively differentiates from sibling tools like list_available_jobs or list_personality_offerings by focusing on worker marketplace offerings with employment types and credit prices.

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

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

The description implies usage context (browsing available workers for hire) but does not explicitly state when not to use this tool or mention alternatives. Given the unique purpose among siblings, the guidance is clear enough for an AI agent to infer appropriate usage.

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

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

Discloses pricing, PAN/CVC handling, auto-freeze, sandbox behavior, and credit cost. Annotations are consistent and the description adds significant behavioral context beyond them.

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

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

Single dense paragraph that front-loads key info. Every sentence adds value; no wasted words.

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

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

Covers purpose, behavior, pricing, authentication context, and return value. With 2 simple parameters and output schema, the description is fully adequate.

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

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

Schema already describes parameters well. Description adds context on usage (e.g., fundedUsd as spending limit, testJobId for surfacing card) and pricing explanation.

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 issues a single-use virtual card with a hard cap, and specifies the resource and verb. It distinguishes from siblings like quote_test_card and freeze_test_card.

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

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

Explicitly states it is 'perfect for verifying customer checkout flows without real money' and mentions sandbox mode. Lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by explaining the pricing logic (sums Hume Octave narration cost, adds flat 10-credit assembly fee) and explicitly states it is a 'free preview', which is not in 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?

Two sentences, no unnecessary words. Front-loaded with the key purpose. Every sentence adds value: first sentence states purpose, second gives usage hint.

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 presence of an output schema covers return values, and annotations cover safety. However, the lack of parameter descriptions in both schema and tool description leaves a gap for the agent to understand the required nested fields, making it slightly incomplete.

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

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

The schema has 0% description coverage for the single 'segments' parameter, which is a complex array of nested objects. The description does not explain the structure or meaning of the nested fields, relying entirely on the schema which lacks descriptions.

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

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

The description clearly states the tool 'quotes' the credit cost for a 'multi-segment demo video', using specific verbs and resources. It differentiates from sibling tools like 'assemble_demo_video' by indicating this is a pricing preview.

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

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

The description provides usage context: 'Useful before committing to a longer video', implying it should be used before assembly. However, it does not explicitly state when not to use it or list alternatives beyond the implied assembly 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying output fields (funded, markup, service fee, total) and stating 'No credits deducted,' providing additional behavioral context beyond 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, using two sentences to convey purpose, usage, parameter info, and output. No unnecessary words or verbose explanations.

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

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

Given the tool is simple with one parameter and has an output schema, the description fully explains the tool's behavior and return values. It is complete for effective use.

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

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

The single parameter fundedUsd has 0% schema description coverage. The description explains it as 'the USD amount you want loaded onto the card' and mentions the range '$1-$200,' adding meaningful context that the schema alone does not provide.

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 this is a pricing preview tool for provision_test_card, specifying it returns funded amount, markup, service fee, and total. It distinguishes itself from the sibling provision_test_card by noting it is 'pre-flight pricing'.

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 before calling provision_test_card by stating 'Pre-flight pricing for provision_test_card.' It provides context on when to use, though does not explicitly state when not to use or list alternatives.

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

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

Goes beyond annotations by disclosing the tool is free, provides the rate ($0.05/1k char, 1 credit=$0.10), and returns credit charge. No contradictions with 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?

Two concise sentences. Front-loaded with the primary purpose. Every sentence adds value with no waste.

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

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

For a simple tool with one parameter and an output schema (implied), the description sufficiently covers what the tool does and what it returns. No gaps given the tool's complexity.

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

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

Schema parameter description is minimal ('Script text to be synthesized'). Tool description adds that cost is derived from script length and provides rate, giving meaningful context beyond the schema.

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

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

Clearly states the tool provides a read-only cost preview for synthesize_voiceover, specifying it returns credit charge based on script length and rate. Distinguishes itself from the actual synthesis 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?

Explicitly says it's a preview for synthesize_voiceover, implying use before synthesis. Mentions it's free and read-only. Does not explicitly list when not to use or compare with sibling tools, but context is clear.

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

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

Annotations already indicate mutation (readOnlyHint=false) and non-idempotency; description adds the concepts of retention window and active marking, but lacks details on irreversibility or limits, providing moderate added value.

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 concise sentence that covers the core action without redundancy, though it could benefit from a more structured presentation.

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

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

For a simple one-parameter tool, the description is adequate but does not mention the existing output schema or prerequisites (e.g., identity must be retained), leaving some gaps.

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

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

The input schema has 0% description coverage and the only parameter 'testIdentityId' is not explained in the description; agents must guess the format or constraints, which is insufficient.

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 ('extends') and resource ('retained identity') and adds detail about the retention window and marking active, clearly differentiating from sibling tools like 'create_test_identity' or 'delete_test_identity'.

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

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

No guidance on when or when not to use this tool, no mention of alternatives or prerequisites, leaving the agent to infer context solely from the description.

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 indicate this is a non-read, idempotent, non-destructive operation. The description adds that it keeps the original test's URL, goal, prompt, and inbox config, providing useful context beyond annotations. Minor gap: it doesn't specify whether a new job ID is created each time.

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

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

Two concise sentences front-load the action, then explain the use case and behavior. Every sentence adds value with no redundancy.

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

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

With an output schema present, the description doesn't need to detail return values. It covers the action, when to use, and what is preserved. Slightly incomplete regarding potential side effects or idempotency behavior, but appropriate for a single-parameter tool.

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

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

Schema coverage is 100% with a description for jobId. The description adds that the jobId comes from submit_test or a prior retest_job, providing source context beyond the schema. It also explains that the original test configuration is preserved, indirectly clarifying the parameter's role.

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 're-runs an existing test job against the latest deployment', using a specific verb and resource. It distinguishes from siblings like submit_test (which creates new tests) and get_test_results (which reads results).

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

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

The description explicitly advises using this tool after pushing a fix surfaced by get_test_results, providing clear context. However, it does not mention when not to use it or alternative tools for other scenarios (e.g., submitting a completely new test).

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 key behaviors beyond annotations: ordered job fan-out, parallel premium, auto-cancel and refund on pauseOnBugThreshold. Annotations only state readOnlyHint false, so the description carries the full burden and delivers rich behavioral context on how the combo execution works.

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

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

Three sentences, each earning its place: main action, fan-out/parallel behavior, auto-cancel mechanism, and a usage tip. No redundancy or fluff. Front-loaded with the primary verb and object.

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

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

Given the tool's complexity (7 params, combo bundling, auto-cancel logic), the description adequately covers the core behavior and provides a usage tip. It does not explain projectId/projectLabel, but those are common context fields. With an output schema present (not inspected), return values are not required in the description.

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

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

Schema coverage is 71% (5 of 7 params described), so the schema already explains most parameters. The description adds minimal parameter insight beyond restating 'URL' and 'named combo'. It does not clarify pages vs. stories, nor projectId/projectLabel. Meets baseline but does not compensate for undocumented params.

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

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

The description clearly states the action ('Queue a named combo against a URL') and specifies the resource (combo bundle). It distinguishes from siblings like list_combos and other submit tools by using terminology like 'fans into N ordered jobs' and 'batchId', making the tool's purpose unambiguous.

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

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

The description explicitly advises to browse the catalog first with list_combos, providing a concrete alternative. It implies this is for combos rather than individual tests, but does not explicitly mention when not to use it (e.g., for single tests use submit_test). Good context but could be more explicit about exclusionary 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 provide basic hints (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds significant behavioral context: real WebRTC call with real audio, TTS and STT usage, default LLMs, and output details. No contradiction with annotations.

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

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

The description is concise yet comprehensive, covering purpose, mechanics, and outputs in a few sentences. It front-loads the key action and resource, making it efficient for an AI agent to parse.

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

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

Given the tool's complexity (7 parameters, 1 required, 100% schema coverage, output schema exists), the description provides thorough context: real audio, end-to-end verification, demo purpose, and return values. It is complete for an informed agent.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the default persona pairing and the purpose of the scenario parameter, but does not significantly expand on parameter meaning beyond what the schema provides. A score of 4 reflects the added context without over-justifying.

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

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

The description uses specific verbs ('Spawns', 'driven', 'runs', 'talks', 'listens') and clearly identifies the resource ('two-AI voice conversation through Paradise Comms'). It distinguishes from siblings by focusing on voice conversation testing with real audio, which is unique among the listed sibling tools.

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

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

The description explicitly states the tool is 'Used to verify Paradise Comms end-to-end... and to demo agent-to-agent voice.' This provides clear context for when to use it. However, it does not mention when not to use it or provide alternatives, which prevents a higher score.

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

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

Annotations already indicate non-readonly, non-idempotent, and non-destructive. The description adds valuable behavioral context: items sit in status='new' and are worked through with the operator, clarifying the asynchronous nature. No contradictions with annotations.

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

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

The description is a single paragraph with front-loaded key purpose. It is information-dense without excessive verbosity. A more structured format (e.g., bullet points) could improve scannability, but it remains concise and effective.

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

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

Given the tool's complexity (7 parameters, 2 required, output schema exists but not shown), the description covers workflow, best practices, and relevant context. It adequately explains queuing behavior and parameter usage, making it complete for a feedback submission tool.

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

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

Schema description coverage is 86%, and the description adds practical meaning beyond schema fields: e.g., 'name the surface affected' for title, 'include reproduction steps in the body' for body, and 'so the operator can pull screenshots' for relatedJobId. This enhances 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 title and description clearly state the tool files feedback (bug, feature request, UX nit) for operator triage. It uses a specific verb-resource pair ('submit_feedback') and distinguishes itself from siblings like 'list_feedback' and 'update_feedback' through its submission context.

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

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

The description provides explicit usage guidance: items are not acted on automatically, one issue per submission, include surface name and repro steps, pass relatedJobId for context, and optional reporterEmail for follow-up. It lacks explicit when-not-to-use or alternatives, but the 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?

Annotations declare openWorldHint=true and destructiveHint=false, indicating it interacts externally but is not destructive. The description adds value by detailing parallel execution, browser-per-role, persona assignment, signal/wait_for_signal communication, and the return mapping. It does not contradict annotations and provides context beyond structured fields.

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

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

The description is three sentences, front-loaded with core functionality, then use cases and output/billing details. Every sentence adds value without redundancy.

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

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

Given the complexity of a multi-agent orchestration tool, the description covers high-level behavior and output but lacks detail on parameter options like identity modes, device presets, session cookies, and video call testing, leaving gaps for an agent unfamiliar with 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?

With schema description coverage at 25%, the description should compensate but only generically mentions 'browser, persona, goal' and signal actions. It does not explain the many properties inside roles (e.g., url, steps, identityMode, sessionCookies) which have detailed schema descriptions but are not highlighted in the tool-level description.

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

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

The description clearly states the tool queues 2-10 AI agents in parallel as coordinated roles. It provides specific use-case examples (publisher+viewer, buyer+seller) and distinguishes from single-agent tests by emphasizing multi-agent orchestration and signal-based communication.

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

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

The description explicitly lists appropriate scenarios (livestream, marketplace, multi-user chat) and implies when not to use (e.g., single-agent tests). It provides billing context (15% parallel premium) but does not explicitly name alternative sibling tools like submit_test or submit_conversation_test.

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 indicate non-read-only and non-destructive behavior. The description adds value by disclosing side effects: triggers earnings, report, client notification pipeline, and returns report id and pass/fail status. No contradictions with 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?

Two concise sentences with no wasted words. Purpose is front-loaded, and every sentence adds necessary information. Example of efficient description.

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

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

Given the tool's complexity (4 parameters, nested objects, output schema exists), the description is adequate but incomplete. It does not explain the `createdIdentityCredentials` parameter, error handling, or idempotency guarantees. The output schema covers return values, so that gap is acceptable.

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 75%, so a baseline of 3 is appropriate. The description does not add extra meaning to parameters beyond what the schema provides; it only mentions 'worker's outcomes' and 'claimed job' without detailing the items or summary structure.

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

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

The description clearly states it submits worker outcomes for a claimed job using a specific verb ('Submit') and resource ('job results'). It mentions the triggered pipeline, distinguishing it from read tools, but does not explicitly differentiate from sibling submission tools like 'retest_job' or 'submit_conversation_test'.

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

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

No guidance on when to use this tool versus alternatives. It implies it should be used after claiming a job, but does not state prerequisites, when not to use it, or mention related tools like 'claim_job' or 'retest_job' for comparison.

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

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

The description discloses numerous behavioral traits beyond the annotations: queueing behavior, run times (~1-5 min AI, slower human), effects like video recording, identity provisioning, SMS inbox, and cookie injection. It also mentions polling for results and credit costs. No contradictions with 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 fairly concise for the complexity (37 params). It is front-loaded with the core purpose and runner options. Some detail could be trimmed (e.g., repeating 'Returns a jobId' is clear from context), but overall it is well-structured and efficient.

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

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

Given 37 parameters, 2 required, 100% schema coverage, and existence of output schema, the description is remarkably complete. It covers parameter relationships, dependencies, and edge cases (e.g., viewport vs devicePreset, offeringId vs personalityOfferingId). It also explains nuanced features like video call testing and synthetic visitors.

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

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

Schema coverage is 100%, but the description adds substantial meaning. For example, it explains the purpose of runner, goal, useSmsInbox, recordVideo, and agentInstructions, including constraints and best practices (e.g., 'Without a goal the AI runs out its step budget'). This goes well beyond the schema descriptions.

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

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

The description clearly states it queues a test job for a URL, explains the two runner types (AI agent vs human checker), and indicates the return value (jobId). It distinguishes from sibling tools like submit_test_batch or submit_conversation_test by focusing on a single test job with explicit runner choice.

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 clear guidance on when to use AI vs human runner, e.g., 'AI agent... fastest, deterministic for well-specified goals' and 'human checker... slower, better for visual/UX judgment calls'. It does not explicitly mention when to use this tool over siblings, but the contrast is implied.

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

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

Description adds cost detail ('1.15× its base credits'), output structure ('batchId and a per-test breakdown'), and concurrency limit (from input schema note). Annotations are minimal; description provides significant behavioral context beyond 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?

4 sentences, front-loaded with action and key constraints. Each sentence adds value: definition, cost, return value and polling, usage guidance and exclusion. No waste.

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

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

Given the presence of an output schema (referenced), detailed input schema, and behavioral details (parallel execution, concurrency, cost, exclusions), the description is complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for the two parameters; it only mentions batch size and cost, which are not parameter-specific. No additional semantics provided.

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

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

The description clearly states the verb 'submit' and resource 'AI tests as a parallel batch', and distinguishes from serial submission with 'instead of one-after-another'. It also notes the batch size limit of 20. This differentiates it from the sibling tool 'submit_test'.

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

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

Explicitly says 'Use this when you have an independent set of tests to run... and want them done in minutes rather than queued through a serial worker.' Also specifies 'AI runner only — human-runner batching ships separately,' giving clear when-to-use and when-not-to-use guidance.

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

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

Annotations indicate a write operation (readOnlyHint=false) and no destructive or idempotent guarantees. The description adds context: creating a subscription requires human payment approval and covers specific resources. It does not contradict any annotation.

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

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

Three sentences succinctly convey the tool's purpose, workflow, and constraints. No extraneous words.

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

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

For a tool with 3 params, an output schema, and annotations, the description adequately covers the key behavioral aspects: human approval needed, scope of subscription, and that it returns a checkout URL. Prerequisites are not detailed but openWorldHint allows for exploration.

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 67%. The description does not provide additional meaning for the parameters beyond what the schema offers (planId enum, cancelPath/successPath redirect paths). Baseline is appropriate given coverage.

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

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

The description clearly states the tool creates a Stripe Checkout subscription for persistent persona seats, specifying the verb and resource. It distinguishes its scope by noting what the subscription covers and excludes (test runs still require credits), but does not explicitly differentiate from sibling tools.

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

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

The description explains that MCP clients can initiate the subscription flow and return a checkout URL, but human approval is required for payment. It also clarifies that the subscription only covers persona storage, inbox, and credential retention, implying when other billing methods are needed. No explicit alternatives are named.

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

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

Describes charging credits upfront based on script length, signed URL with 24h TTL, and non-real-time nature. Annotations are generic, so description provides necessary behavioral context without contradictions.

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

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

Concise paragraph with front-loaded action, no fluff. Every sentence adds value: purpose, usage, alternatives, parameter hints, and limitations.

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

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

Covers behavior, usage, parameter details, credits, TTL, and output (audio URL). With output schema present, return values are documented. Complete for a TTS tool.

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

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

Schema coverage is 100%, so description adds no new meaning beyond schema. It reiterates default narrator for voiceId and optional prosody steering, but schema already captures these. Baseline 3 is appropriate.

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

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

Clearly states it generates a voiceover from text using Hume Octave TTS, specifies return of audio URL, and distinguishes itself from sibling tools like quote_voiceover and Hume EVI.

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

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

Explicitly lists best use cases (demo-video narration, tutorial audio, one-shot batch TTS) and explicitly says NOT for real-time conversational voice, directing to Hume EVI. Also references quote_voiceover for credit preview.

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

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

Discloses that Stripe Checkout URL requires human interaction, explains webhook credit addition, and references Stripe's policy, adding value beyond 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?

Three sentences, front-loaded with purpose, no wasted words, logically flows from action to behavior to follow-up.

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?

Explains return type, next steps, and parameter defaults; no gaps given output schema exists.

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

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

Adds context to packIndex (from list_credit_packs) and default paths for cancelPath and successPath, enhancing schema which already has 100% coverage.

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

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

The description clearly states 'Buy more credits' with specific verb and resource, and distinguishes itself from sibling tools like get_credit_balance and list_credit_packs.

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

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

Provides when to use (need credits) and post-action steps (poll get_credit_balance). Does not explicitly exclude alternatives, but context is clear.

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

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

Discloses key behavioral traits: state machine transitions, note appending, duplicate marking, and that it returns the updated record. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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

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

Very concise: two sentences covering the core purpose, operations, and return value. No fluff, key info front-loaded.

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

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

Covers main operations, access restriction, and return. Could mention prerequisites (e.g., feedback must exist) or error states, but the output schema likely covers return details. Adequate for moderate complexity.

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

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

Schema covers 3 of 4 parameters with descriptions (75% coverage). The description adds value by clarifying the state machine order and the append behavior for notes, which complements the schema.

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

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

Clearly states it's a staff-only write operation for updating feedback status, notes, or marking duplicates. The state machine transitions are explicitly listed, and the tool is distinguished from siblings like submit_feedback (create) and list_feedback (read).

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

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

Describes when to use (updating feedback status, notes, or duplicates) and that it's staff-only. Implicitly differentiates from alternative tools (e.g., submit_feedback for creation), though could explicitly name alternatives.

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

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

The description adds context beyond annotations by stating idempotency (though contradictory to idempotentHint=false) and explaining opt-in/out behavior. It also clarifies payment modes. However, the contradiction with annotations reduces trust. Without the contradiction, transparency would be higher.

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

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

The description is two sentences, front-loading the main purpose and then adding key behavioral details. It is efficient with no wasted words. The slight loss due to the idempotency contradiction is captured in behavioral transparency.

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 7 parameters with full schema descriptions and an output schema, the description covers key use cases and distinctions. However, it lacks details on error handling, rate limits, or required conditions for in_house type. The contradiction with idempotentHint further reduces completeness.

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

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

All 7 parameters have descriptions in the schema (100% coverage). The top-level description reinforces key parameters (bio, specialties, shiftseeUserId) but doesn't add significantly new information. The baseline of 3 is appropriate as the description complements the schema without redundancy.

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 tool name 'upsert_worker_profile' and title 'Create or update your worker profile' clearly indicate the action and resource. The description specifies it's for the calling account's worker profile, distinguishing it from sibling tools like 'create_worker_offering'. The purpose is unambiguous and 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 clear context on when to use (to create/update profile, opt in/out of marketplace) and distinguishes between external and in-house workers, including the requirement for shiftseeUserId. It does not explicitly mention alternatives or when not to use, but the guidance is adequate for most scenarios.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds specific context about returned fields (id/email/role, billing mode) beyond 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?

Two sentences: first describes return values, second explains when to use. No wasted words, essential information front-loaded.

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

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

With output schema present, description sufficiently covers what the tool returns and its purpose as a self-check. No missing gaps.

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

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

Schema describes targetUrl as optional URI. Description explains that it checks billing mode for that URL, adding context that the response includes exact billing outcome. Schema coverage is 100%, so baseline 3; description adds value.

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

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

Description clearly states it returns account id/email/role plus billing-mode eligibility. It explicitly says to use this first in new projects, distinguishing it from siblings like check_test_identity.

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

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

Explicitly advises to use first when bringing TMV into a new project, confirming API key maps to correct account. Does not specify when not to use, but context is clear.

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