TestMyVibes

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

Annotations (readOnlyHint=false, destructiveHint=false) are consistent; description adds details like returning a 24h signed URL, charging on success only, and optional stable publishing path.

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

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

Single paragraph of five sentences, front-loaded with core operation, efficient with no 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?

Covers segment types, constraints (max 12 segments, ~3 minutes), output (signed URL), use cases, and pricing; sufficient given presence of output schema.

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

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

Schema coverage is 100%, but description adds rich context: explains three segment types, defaults for voiceId, common videoUrl source, minDurationSec for title cards, and publishAs usage for persistent URLs.

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 stitches video clips and voiceover into an MP4, specifies three segment types, and distinguishes from siblings like synthesize_voiceover by focusing on video assembly.

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 mentions charging on success, but does not explicitly state when not to use or compare with sibling tools.

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

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

The description adds valuable behavioral context beyond annotations: it mentions headless Chromium, pricing model (1 credit per viewport, 5 for triple), output as signed Spaces URLs valid for 7 days, and click path behavior (non-fatal missing selectors). 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?

Four sentences, front-loaded with action and purpose, each sentence adds value (what, how, pricing, output, use cases). No superfluous content.

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 output schema exists, description need not detail return structure, but it does mention signed URLs with 7-day validity. All key aspects are covered: input url, viewports, optional clicks, timing, pricing, and intended use.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning beyond schema by explaining pricing logic for viewports, that clickPaths are non-fatal for missing selectors, and provides default settleMs coverage for SPAs.

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 drives headless Chromium to capture screenshots across specified viewports, with optional click paths. It distinctly differentiates from sibling tools (none are screenshot-related) and uses specific verbs ('Drive', 'return a screenshot').

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 recommends use cases: marketing screenshots, design QA, regression baselines. While it doesn't list when not to use or alternatives, the sibling tools are sufficiently diverse and unrelated, making the guidance 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 atomicity, the return of checklist and SLA deadline, and the consequence of expiry—all valuable beyond annotations (which only show non-readonly and non-destructive). 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 sentences, front-loaded with the core action, followed by essential workflow details. Every sentence adds necessary information without redundancy.

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

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

Given the output schema exists (so return values are documented), the description covers the claim's effect, result contents, and post-claim expectations. For a simple one-parameter tool, this is complete.

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

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

Schema coverage is 100% for the single parameter 'jobId', which already includes a description. The description adds context by specifying that the jobId comes from 'list_available_jobs', helping the agent understand provenance. This lifts it above the baseline of 3.

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

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

The description uses specific verbs ('take ownership') and names the resource ('pending job'), clearly distinguishing it from siblings like 'list_available_jobs' (listing) and 'submit_job_results' (submitting). It fully captures the tool's atomic claim action.

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

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

The description contextualizes the tool by mentioning that the job comes from 'list_available_jobs' and that results must be submitted via 'submit_job_results', implying the workflow. It also warns about SLA expiry. However, it does not explicitly state when not to use the tool (e.g., if already claimed).

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 that the tool charges via Stripe and credits the user's TMV account synchronously, which adds behavioral context beyond the annotations. Annotations indicate non-readOnly and non-destructive, but the description clarifies the specific side effects. 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 concise, consisting of three sentences that efficiently convey the purpose, trigger, and key parameter relationship. It is front-loaded with the core functionality and contains no unnecessary words.

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

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

Given the tool's complexity and the presence of an output schema, the description covers the essential flow and references the prerequisite tool. However, it lacks details on error handling, idempotency, or rate limits, which would be helpful for an AI agent. It is minimally 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 description coverage is low (33%), and the tool description only adds context for the checkout_session_id parameter, mentioning it comes from top_up_credits. It does not provide additional meaning for buyer or payment_data beyond what the schema already includes. The description should compensate more for the low 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's function: completing a checkout by charging a Stripe payment token and crediting a TMV account. It specifies the trigger ('after user clicks Pay') and the source of the checkout_session_id, making the purpose unambiguous and distinguishing it from sibling tools like top_up_credits.

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

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

The description explicitly states when the tool is called ('after the user clicks Pay in an inline payment widget') and refers to the prerequisite call to top_up_credits. However, it does not explicitly mention when not to use it or alternative tools, leaving some room for improvement.

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 it is a non-read-only, non-destructive, non-idempotent creation operation. The description adds the return value (projectId) but no further behavioral details like duplicate handling or validation.

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

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

The description is a single, front-loaded sentence with no wasted words, efficiently conveying purpose and output.

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 parameters and presence of an output schema (implied by returning projectId), the description is adequate. It could mention which parameter is the site identifier but 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?

All parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning. Baseline of 3 is appropriate.

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

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

The description clearly states the tool creates a new site for testing and returns a projectId for future use, distinguishing 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?

The description explains the tool should be used before submit_test to get a projectId, but does not explicitly state when not to use it or suggest alternatives like reusing existing projects.

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

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

Beyond annotations (readOnlyHint=false, etc.), the description details economic behavior: worker earns 75%, TMV keeps 25%, floor-rounded credits, and per-offering ceiling conditions. It also explains the cap removal criteria, providing full behavioral context.

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

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

The description is three sentences, each delivering essential information: purpose, customer visibility, economics, and constraints. It is front-loaded and concise without unnecessary detail.

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

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

Given 5 parameters and an output schema, the description covers all critical aspects: what the tool does, how customers see it, economic split, pricing limits, and conditions for lifting caps. It is sufficient for an agent to correctly invoke the 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 low (20%), but the description adds meaning by explaining how parameters (name, description, creditsCharged, estDurationHr) are used by customers. It specifies pricing rules for creditsCharged, which is not in the schema description. However, optional parameters like specialties are not discussed.

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 adds a named, priced offering to the worker menu, using specific verbs like 'Add' and 'publish'. It distinguishes from sibling creation tools (e.g., create_project, submit_job) by focusing on service offerings for workers.

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 when to use the tool: to add an offering that customers see and pick. It provides pricing constraints (minimum 15 credits, ceiling 50 for new accounts) and notes the revenue split, but does not explicitly list when to avoid using it or alternatives.

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

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

Description claims 'Idempotent' but annotations set idempotentHint=false. This is a contradiction. Additionally, annotations have destructiveHint=true which matches the cancel action, but the idempotency claim is inconsistent and misleading.

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 are efficient and front-loaded with the core purpose. 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 annotations and output schema existence, the description is largely complete for a simple mutation. It explains behavior, idempotency (though contradictory), and usage context. Lacks mention of return value but output schema likely covers that.

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

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

Schema covers 100% of parameters with adequate description for cardId. The tool description does not add extra parameter semantics beyond the schema, so baseline 3 is appropriate.

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

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

Description clearly states the tool cancels a test card and prevents further authorizations. The verb 'Cancels' and resource 'card' are specific. It distinguishes from sibling tools like provision_test_card and list_test_cards.

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?

Explicit guidance on when to use: 'call this explicitly to freeze immediately after a successful checkout test.' Also mentions the alternative auto-freeze that runs daily for expired cards.

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, idempotent, and non-destructive behavior. The description adds value by explaining the composite nature of the response, including cumulative bug counts and estimated time remaining. It also notes the tool is 'Free', providing cost transparency.

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

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

The description is two sentences, front-loaded with the tool's purpose and key features. Every word adds value, with no redundant or filler content.

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 parameter) and the presence of an output schema, the description provides sufficient context. It outlines the major output categories (breakdown, bug counts, threshold, time remaining) and usage guidance, making the tool's functionality clear.

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 the single parameter 'comboId'. The tool description does not add further semantic meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns a composite status for a combo bundle, listing specific output elements (per-leg breakdown, bug counts, pause threshold, time remaining). It distinguishes from siblings by explicitly advising to use this instead of polling individual jobIds.

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 directly tells when to use the tool: 'Use this instead of polling N individual jobIds for a combo.' While it doesn't specify when not to use, this explicit guidance is strong and 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 the tool is read-only, idempotent, and non-destructive. The description adds valuable context about the return data (total valid credits, raw batches, warning flag), which goes beyond what annotations provide. There is 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 two sentences long, concise, and front-loaded with the main purpose. Every sentence adds value and there is no extraneous information.

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

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

For a simple read-only tool with no input parameters and an existing output schema (as indicated), the description covers the essential return fields and the threshold warning. It is complete enough for an AI agent to understand the tool's behavior.

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

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

The tool has zero parameters, so no semantic information is needed. The description does not attempt to describe parameters, which is appropriate. The schema coverage is 100% by default, meeting the baseline expectation.

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

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

The description clearly states the tool's purpose: 'Get the current account's credit balance.' It specifies the resource (credit balance) and the action (get). This distinguishes it from sibling tools like top_up_credits (adds credits) and list_credit_packs (lists 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?

The description implies the tool is used to fetch the credit balance, but it does not explicitly state when to use this tool over alternatives or provide any usage restrictions. Since there are no direct alternatives for checking the balance, the lack of explicit guidance is acceptable but not ideal.

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, but the description adds valuable context: it covers the fix-test-retest loop, writing test prompts, reading outputs, and common gotchas. It also mentions the same content is at a URL, which helps the agent understand the nature of the response.

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

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

Two sentences, front-loaded with purpose, followed by content summary and usage hint. Every sentence earns its place. No verbosity.

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 0 parameters and a rich output schema (implied), combined with complete annotations, the description fully covers what the tool does, when to use it, and what to expect. 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?

The input schema has zero parameters and schema coverage is 100%, so the description does not need to add parameter details. Baseline for 0 params is 4, and the description provides no additional parameter info, 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 'Returns the canonical guide for using TMV from a coding-agent context.' It specifies the exact resource (guide) and action (returns), and distinguishes from sibling tools by positioning it as a first stop for new agents.

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 'Call this first if you're a new agent on a project' – providing a clear when-to-use directive. It also references common gotchas and outputs, implying context where it's valuable, and distinguishes from other tools by focusing on integration guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns a hosted URL that the user must open to complete bank linking, providing behavioral context beyond the annotations. No contradictions noted.

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

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

The description is two sentences long, front-loads the primary purpose, and contains no extraneous information. Every word adds value, making it highly 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?

Given the tool's low complexity (2 optional parameters, no required fields, output schema present), the description covers the purpose, parameter usage, return behavior, and expected user action. No gaps remain for an agent to misuse the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful guidance: explaining the workerKind enum values ('ai' for AI-agent operators, 'human' for human checkers) and clarifying that agentOperatorLabel is optional metadata. This exceeds the schema's basic 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 that the tool generates a Stripe Connect onboarding URL for linking a bank account and starting payouts, with a specific verb ('Mint') and resource ('Stripe Connect onboarding link'). It also distinguishes the purpose of opting into worker mode via the workerKind parameter, making it highly 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 for when to use the tool (to set up payouts and optionally opt into worker mode). Although no explicit alternative tools are mentioned, the sibling list does not contain a similar tool, so the absence of exclusions is not a drawback. The context is sufficient for correct selection.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds value by describing the response content but lacks details on error handling, latency, or what happens with invalid sceneIds, which would be helpful.

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

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

The description is two sentences, each earning its place: first sentence defines the tool's 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?

Given the tool's simplicity, the presence of an output schema, and comprehensive annotations, the description covers all necessary context: what the tool does, when to use it, and what the input parameter is. No gaps remain 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?

Input schema coverage is 100% and the description only indirectly explains sceneId by referencing its origin (from submit_interaction_scene). The description does not add significant meaning beyond the schema's existing description, resulting in a baseline score.

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 provides a single-call view of every role in a scene, listing specific data (job status, signals, shared state). It distinguishes from polling individual jobs but does not explicitly differentiate from similar sibling tools like get_combo_status or get_test_status, leaving some ambiguity.

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

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

The description explicitly states to use this tool instead of polling N individual jobIds, providing clear positive guidance. It does not specify when not to use it or mention alternatives among siblings, but the context is sufficient for the intended use case.

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, so the description adds value by disclosing the pending status behavior. 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 that front-load the purpose and include a key behavioral detail. 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?

The description covers the core functionality and the pending state. With an output schema present, return values are not needed. It omits prerequisites like how to obtain jobId, but context is sufficient for a low-complexity 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 jobId described as 'The job ID.' The description does not add additional parameter semantics beyond what the schema provides, resulting in baseline score.

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 fetches full results for a completed test, listing specific contents (checklist outcomes, report summary, AI analysis). It distinguishes from sibling tools like get_test_status by implying this is for full 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 implies usage after a test is complete but does not explicitly guide when to use this tool versus alternatives like get_test_status. It mentions the pending status, which offers some context, but lacks explicit exclusions or alternative recommendations.

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 safety profile is clear. The description adds a behavioral detail (returns current status) but does not elaborate on response format or performance characteristics. With annotations doing most of the work, the description provides marginal addition.

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 with no extraneous information. It is appropriately sized for a simple lookup tool and front-loads the key information.

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

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

Given the tool is simple with one parameter and has rich annotations and an output schema, the description is complete enough. It could mention that this is solely for status and not results, but overall it adequately serves the agent's needs.

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 jobId as 'The job ID returned by submit_test.' The description does not add any further semantic context for the parameter, so it meets the baseline expectation for high schema coverage.

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

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

The description clearly states the action (look up) and the resource (current status of a submitted test job). It distinguishes from other tools like get_test_results (which likely provides full results) and get_scene_status (different resource). However, it does not explicitly differentiate from other status lookups, leaving some ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_test_results or get_scene_status. There is no mention of context or prerequisites, leaving the agent to infer usage without support.

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 readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no further behavioral traits such as authentication requirements or rate limits. It does not contradict 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?

A single sentence that is concise and well-structured, listing all key information without redundancy. Every phrase 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 zero parameters and the presence of an output schema, the description sufficiently covers the tool's purpose and the content of its response. No obvious 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?

There are no parameters, so the description does not add parameter-level meaning. However, it explains the output fields (lifetime earned, paid-out, pending, Stripe status, threshold), which is valuable beyond the empty schema. With 100% schema coverage (no params), a baseline of 3 applies, but the detail on output semantics elevates it.

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 including lifetime earned, paid-out, pending, Stripe Connect status, and auto-payout threshold. It specifies the verb 'Show' and the resource 'worker earnings', effectively distinguishing it from sibling tools which involve other 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 implicitly indicates usage for checking the calling worker's personal earnings, but lacks explicit guidance on when to use this tool versus alternatives like get_credit_balance or get_combo_status. No when-not-to-use or alternative mentions 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 readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns the freshest jobs first and excludes owned/claimed jobs, providing context beyond 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?

Three sentences, each providing essential information without redundancy. Front-loaded with the core action. No wasteful 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?

The tool has an output schema (not provided but referenced), so return values need not be explained. It covers filtering and ordering. Minor omission: no mention of pagination, but the maxResults parameter implies a limit. Overall adequate for a simple list tool.

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

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

Schema coverage is 50% (one parameter described, one not). The description does not add meaning beyond the schema; the schema already explains 'jobType' filter and 'maxResults' default/max/min. Hence baseline 3.

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

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

The description clearly states the tool returns the queue of pending jobs available for the calling worker to pick up, specifying exclusions (jobs owned by the calling account or already claimed). It distinguishes from siblings like 'list_my_claimed_jobs' by noting that owned jobs are excluded.

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 for listing available jobs to claim, and implicitly contrasts with 'list_my_claimed_jobs' by excluding owned jobs. However, it does not explicitly state when not to use this tool or provide direct alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Read-only; charges nothing', confirming no side effects or cost. It also describes output details (legs, cost, duration, threshold), providing 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, no wasted words. First sentence establishes purpose with specific examples, second details contents. 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 has an output schema and no parameters, the description provides a comprehensive list of what the output contains (legs, cost, duration, threshold, recommendation). It is 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?

Input schema has 0 parameters, so no parameter semantics are needed. Schema coverage is 100%. The description adds no parameter info, but none is required. Baseline score of 4 applies.

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

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

Title 'List packaged AI-agent combo bundles' and description 'Returns the full combo catalog' clearly state the tool lists all combos. The description further details what each combo contains, distinguishing it from sibling tools like get_combo_status.

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

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

The description implies usage for browsing the catalog but does not explicitly state when to use this tool vs alternatives like get_combo_status or list_available_jobs. Since it has no parameters and is read-only, the need for guidelines is lower, but explicit guidance would improve clarity.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the exact fields returned (pack index, credit count, USD price, per-credit cost). 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?

Two sentences pack all necessary information without redundancy. The critical action (list) and key return fields are front-loaded, and every sentence contributes value.

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

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

Given no parameters and an output schema (implied), the description is complete: it states what the tool does, what it returns, and how to use the result. No missing 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 and schema coverage is 100%. The description adds meaning by detailing the output structure, which compensates for the absence of parameters. Baseline for 0 parameters 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?

The description clearly states it lists credit packs for purchase, with the verb 'List' and specific resource 'credit packs'. It distinguishes from sibling tools like top_up_credits by indicating the returned packIndex is used with that tool.

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

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

It explicitly advises using the returned packIndex with top_up_credits, providing clear usage context. While it doesn't list when not to use it, the tool's simplicity and zero parameters make this guidance 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, and destructiveHint=false, so the description adds value by noting the tool is free and that emulation runs as part of the base test cost with no markup. This provides behavioral context beyond safety profiles.

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

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

The description is three sentences long, front-loaded with purpose and immediate keywords like 'Returns the device presets'. Every sentence adds essential detail 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?

The output schema exists, so return values are covered. The description still adds useful context about what each entry includes (viewport, deviceScaleFactor, etc.) and mentions cost implications. Given the simplicity of the tool, this is thoroughly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the effect of the featuredOnly parameter: returning a curated subset vs. all devices. This goes beyond the schema description's generic phrasing.

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

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

Description clearly states the tool returns device presets for use in submit_test, submit_test_batch, and retest_job. It specifies the resource (device presets) and the action (list), and distinguishes from sibling submission tools by being a preparatory listing action.

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

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

The description provides explicit guidance on when to use each parameter value: use featuredOnly=true for the 15 most common devices and featuredOnly=false for all 131. It also implies the tool should be used before submitting tests, though it does not explicitly state alternatives or when not to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Beyond that, the description adds behavioral context: staff-only access, triage view, and default ordering (most recent first). This provides sufficient transparency for safe invocation.

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

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

The description is three sentences long, each serving a distinct purpose: stating the tool's role, listing filtering options, and giving a real-world usage example. No redundant or vague phrases.

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 that an output schema exists (context signal: has output schema = true), the description is not required to detail return fields. It covers purpose, filtering, ordering, and usage tip; the only minor omission is the lack of mention of pagination via the limit parameter, but it 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 coverage is only 40% (2 out of 5 parameters have descriptions). The description mentions status, category, and sinceIso, adding meaning to those, but does not cover limit or severity. It partially compensates for the low coverage but still leaves gaps.

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 a staff-only triage view that returns feedback items, optionally filtered by status/category/since. It explicitly distinguishes itself from sibling mutating tools like submit_feedback or update_feedback by emphasizing read-only triage.

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 usage guideline: 'Use status="new" at session start to see what came in unaddressed.' This tells the agent when to apply the filter, though it does not explicitly mention when not to use or alternative tools.

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

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

The description adds significant behavioral context beyond annotations (readOnlyHint, idempotentHint, destructiveHint): auto-expiry after 30 days, retest bumps expiry, and what fields are returned. 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?

Three sentences, each earning its place: first states the action, second describes the return data structure, third explains auto-expiry behavior. No filler or 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 explains the purpose, output (personaId, customer site, credential expiry), and key behavior (auto-expiry, retest bump). Given 0 parameters and an existing output schema, this is complete.

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

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

There are 0 parameters and schema coverage is 100% (empty object), so no parameter documentation is needed. The baseline for 0 parameters is 4, and the description does not add unnecessary parameter info.

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

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

The description clearly states it returns all kept-alive personas, specifying their origin (submit_test with keepTestAccount=true) and what each entry includes (personaId, customer site, credential expiry). This distinguishes it from sibling list tools like list_test_cards or list_projects.

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 when to use the tool (to retrieve kept-alive personas for retesting) and provides important context about auto-expiry and retest behavior. It does not explicitly list alternatives or when not to use, but the context is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond annotations by specifying the included job states (claimed but not submitted, plus in-progress). 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 concise sentence that front-loads the purpose and scope. Every part is essential and 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 tool has no parameters, annotations cover safety and idempotency, and an output schema exists, the description is complete. It clearly defines the set of jobs returned without missing critical 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?

The input schema has zero parameters, so the baseline is 4. The description does not need to provide parameter details as none exist.

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

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

The description uses the specific verb 'list' and resource 'my claimed jobs', clarifying it returns jobs the worker currently holds. It distinguishes from sibling tools like 'list_available_jobs' and 'claim_job' by specifying the state: claimed but not submitted plus in-progress.

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 (to see current workload) but does not explicitly contrast with alternatives like 'list_available_jobs' for unclaimed jobs. No explicit when-not-to-use or prerequisite information is provided.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds that returned offerings lock step budget, inbox provisioning, personality, and price – useful 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?

Three sentences, no fluff. Front-loaded with purpose, then explains usage flow, then gives recommendation. 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?

Has output schema (mentioned but details not in description, which is fine). Description covers what the tool returns and how it integrates with submit_test. Adequate for a simple filtered list tool.

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

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

Schema description coverage is 100% (both parameters described in schema). Description mentions 'Optional filter by personality tier' and 'ceiling on credit price', aligning with schema but adding no new meaning beyond the schema's own 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?

Description specifies 'List all packaged AI tests TMV publishes' – clear verb+resource. Distinguishes from sibling 'submit_test' by explaining the role of the returned ID. Also distinct from other list tools by focusing on personality offerings with presets.

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 want a deterministic, named test product rather than tuning maxSteps / useTestInbox by hand.' Provides context on when to choose this tool over manual configuration. Doesn't state when not to use, but implication 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 provide readOnlyHint=true and idempotentHint=true, so the description adds minimal behavioral context beyond clarifying that projects are 'sites under test'. 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?

A single, clear sentence with no unnecessary words. It 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?

For a parameterless list tool with full annotation coverage and an output schema, the description is complete. It explains the resource being listed and serves its purpose.

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 baseline is 4. The description does not add parameter info, which is appropriate as there are none.

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 projects, specifying they are 'sites under test'. This distinguishes it from other list tools like list_test_cards or list_feedback, which list different resources.

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

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

No explicit guidance on when to use this tool versus alternatives, but given its simplicity and parameterless nature, the context is implied. It does not mention exclusions or alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds value by explaining that PANs are never returned and that this is an audit view, which is 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?

Two sentences, front-loaded with purpose, no wasted words. Every sentence earns its place.

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

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

Given zero parameters and an output schema (presumably detailed), the description fully covers purpose, return values, and use case, leaving no gaps for the AI 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?

There are no parameters, so the schema provides full coverage. The description adds context about what is returned, which aids understanding of the output schema.

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

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

The description clearly states it lists test cards for the account, specifies exactly what fields are returned (last4, funded amount, status, expiry), and explicitly notes that PANs are never returned, distinguishing it from other tools.

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

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

The description provides a concrete use case ('reconciling Stripe Issuing balance against TMV spend') and implicitly suggests when to use it for auditing. No alternative tools with overlapping functionality exist among siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is safe. The description adds behavioral context by stating it lists only active offerings and explains the output structure (bio, tags, employment type, price), which is 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 two sentences long with no extraneous information. It starts with the main purpose, provides filtering guidance, and lists key output fields. Every sentence is valuable and well-structured.

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

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

Given the presence of an output schema, the description does not need to explain return values. It already covers the main output fields and the filtering option. For a read-only listing tool with annotations indicating safety, this is complete.

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

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

Schema coverage is 67%, and the description adds value for the 'specialty' parameter with examples and substring match explanation. However, it does not mention 'limit' or 'includeInHouse' in the description, though the schema covers them adequately. 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 lists active worker offerings and provides filtering by specialty, with examples. It distinguishes from siblings like 'list_personality_offerings' and 'create_worker_offering' by focusing on workers and listing output fields.

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

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

The description gives clear context on when to use the tool (to browse worker offerings) and how to filter by specialty. It does not explicitly state when not to use, but the sibling list provides implicit alternatives. It also does not cover the 'includeInHouse' parameter, but the schema covers 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?

Discloses key behaviors beyond annotations: card auto-freezes 24h, PAN/CVC returned once and never persisted, credit charging, fees. 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?

The description is concise (110 words) yet densely informative. Every sentence adds value—fee breakdown, credit cost, sandbox usage, data privacy. Front-loaded with main action.

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

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

Given the presence of an output schema, the description adequately covers cost, expiration, use case, and privacy. No missing critical behavioral context for a provisioning 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 descriptions already cover both parameters (fundedUsd, testJobId). The description adds extra context: cost calculation (25% markup + $2 fee), credit conversion rate, and purpose of testJobId for surfacing via runContext.

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 issues a single-use Stripe-Issuing virtual card, specifying the resource and action. It distinguishes from siblings like freeze_test_card and list_test_cards by detailing unique behaviors (auto-freeze, one-time PAN/CVC).

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

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

The description provides clear usage context: 'perfect for verifying customer checkout flows without real money' and mentions sandbox mode. However, it does not explicitly exclude alternatives or state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it is a 'free preview' and sums costs, which is consistent. However, it does not provide additional behavioral context (e.g., rate limits, response format) beyond what annotations convey.

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

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

The description is concise (three short sentences) and front-loaded with the key action. However, given the complexity of the parameter, it could be slightly more detailed without being verbose. It earns its place but misses some clarity.

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

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

The description covers the main idea (cost preview for a multi-segment video) but lacks specifics on segment configuration, cost factors beyond narration, and the output schema. Given the existence of an output schema, the description does not need to detail return values, but it should still guide input usage.

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 a single complex parameter 'segments' with 8 properties, but schema description coverage is 0%. The description only mentions 'narration cost' without explaining which fields affect pricing (e.g., narrationText). It adds minimal value for parameter understanding.

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

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

The description clearly states the tool's function: a free preview of assemble_demo_video pricing, summing Hume Octave narration costs and adding a 10-credit assembly fee. It distinguishes itself from the sibling tool 'assemble_demo_video' by being a quote-only 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 says 'Useful before committing to a longer video,' which implies using this tool before assembly to check cost. It indirectly references the sibling 'assemble_demo_video' as the alternative. However, it does not explicitly mention when not to use or other related siblings like 'quote_voiceover'.

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

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

The description explicitly states 'No credits deducted,' which aligns with the readOnlyHint and destructiveHint annotations. It also details the return values (funded, markup, service fee, total charged), providing behavioral clarity 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 short sentences, each adding value: first states purpose, second explains input/output, third provides constraints. No fluff, 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?

The description covers input, output, range, and side-effects. Given the tool's simplicity (1 param, no nested objects) and the presence of an output schema, the description is complete and self-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?

The description fully explains the single parameter 'fundedUsd' by stating its purpose ('amount you want loaded onto the card') and range ('$1-$200'), compensating for the 0% schema description coverage. It also clarifies what the tool returns, adding value beyond the schema.

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

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

The description clearly states it provides pre-flight pricing for provision_test_card, specifying the input (USD amount) and the output components (funded, markup, service fee, total charged). It distinguishes itself from the sibling provision_test_card by being a read-only pricing check.

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 as a precursor to provision_test_card ('Pre-flight pricing for provision_test_card'), giving clear context. However, it does not explicitly state when not to use it or provide alternatives among siblings, though 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the cost calculation details (rate conversion) and stating it's free, which goes beyond the annotations without contradicting 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?

The description is extremely concise with two short sentences, front-loading the key purpose. Every word serves a purpose 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, output schema exists), the description fully covers all necessary context for an agent to use it correctly. It explains the cost calculation and that it's a preview.

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 'text' is fully described in the schema (100% coverage), so the description adds minimal extra meaning. The baseline of 3 is appropriate as no additional parameter semantics are 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 explicitly states it is a 'read-only cost preview for synthesize_voiceover' and details the cost calculation, making the purpose unmistakably clear. It distinguishes itself from the sibling 'synthesize_voiceover' by indicating it only provides a cost estimate.

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

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

The description implies usage is for previewing costs before calling 'synthesize_voiceover', and mentions it is 'Read-only' and 'Free'. However, it does not explicitly state when not to use it or suggest alternatives beyond the implied main 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 indicate idempotent and non-destructive behavior. Description adds that it keeps original test configuration, implying no side effects. Could further state that it does not alter original results, but still good.

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

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

Two sentences: first states purpose, second provides use case and retained config. No wasted words, front-loaded with key information.

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

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

Given single parameter, output schema availability, and clear annotations, the description covers all needed context: purpose, usage trigger, preserved config, and parameter source.

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

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

Only one parameter (jobId) with schema coverage 100%. Description adds meaning by stating that the original configuration is preserved, reinforcing the parameter's role in identifying the test to re-run.

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 'Re-run an existing test job against the latest deployment' with specific verb and resource. It differentiates from sibling tools like submit_test and get_test_results by focusing on re-running completed tests.

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

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

Explicitly says to use after pushing a fix surfaced by get_test_results to verify bug fix. Also notes that it keeps original configuration (URL, goal, prompt, inbox), providing clear context for when it is appropriate.

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

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

Discloses beyond annotations: fan-out ordering, +15% parallel premium, auto-cancellation with refunds on pauseOnBugThreshold. Annotations already indicate non-destructive, non-idempotent, open world; description adds valuable behavioral context.

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

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

Three sentences plus a note, all front-loaded and essential. No fluff. Every sentence adds unique value.

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

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

Given the tool's complexity (7 params, conditional logic), the description covers key aspects: ordering, pricing, cancellation, and prerequisite browsing. Output schema exists, so return values are not needed.

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 good coverage (71%), but description adds meaning around comboId, ordering, pricing, and cancellation logic that are not in schema. Some parameters (projectId, projectLabel) get no extra context, but overall adds value.

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

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

Clearly states it queues a named combo against a URL, with specific ordering and batch ID. Distinguishes from sibling submit tools (e.g., submit_test) by focusing on combos and referencing list_combos.

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

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

Explicitly advises to use list_combos to browse the catalog first. Implicitly tells when to use (for combos) but does not explicitly mention when not to use or alternatives.

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

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

Annotations provide openWorldHint=true and destructiveHint=false. The description adds that it is a real WebRTC call with real audio, TTS, and STT, which is significant behavioral context beyond annotations. No contradictions.

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

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

The description is concise (4 sentences) and front-loaded with the core action. 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?

All 7 parameters are described in schema, output schema exists, and the description mentions return values (transcript and recording hint). Complete for a complex tool.

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

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

Input schema coverage is 100% and descriptions in schema already explain defaults and purpose. The description adds no new parameter-level information beyond the schema.

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

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

The description clearly states it spawns two AI personas on a real LiveKit voice call with TTS and STT, not simulation, and returns transcript and recording hint. This distinguishes it from sibling tools like submit_test or submit_test_batch.

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 it is used to verify Paradise Comms end-to-end and to demo agent-to-agent voice. It does not mention when not to use, but the purpose is clear enough.

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

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

Discloses that feedback queues for staff review and is not automated, items sit in status='new'. Adds value beyond annotations which show readOnlyHint=false, idempotentHint=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?

Paragraph is dense but effectively conveys key information. Could be slightly more structured, but each sentence adds value.

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

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

Covers purpose, usage guidelines, parameter semantics, and behavioral notes comprehensively. Output schema exists, so no need to describe return values. 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?

Adds meaning beyond schema: explains relatedJobId usage, reporterEmail for anonymous filers, severity definitions, and title format examples. Schema coverage is high (86%), but description provides usage context.

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

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

Title and description clearly state it's for filing feedback (bug, feature request, UX nit) for operator triage. Distinguishes from sibling tools like list_feedback and update_feedback by specifying it queues staff review.

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?

Explicit guidance: NOT acted on automatically, one issue per submission, name surface, include reproduction steps, pass relatedJobId for context, optional reporterEmail. Could be more explicit about when not to use, but 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?

The description adds significant behavioral context beyond the annotations, including that roles run in parallel, each billed with a 15% premium, and the tool returns a sceneId and role-to-jobId mapping. There is no contradiction with annotations (readOnlyHint=false, etc.). The description does not mention any destructive or idempotent traits, which is consistent.

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

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

The description is a single paragraph of three sentences, densely packed with key information. It is front-loaded with the core action and provides examples. It could be slightly better structured (e.g., bullet points) but is concise and efficient with no wasted words.

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

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

The description covers the essential purpose and usage examples, and since an output schema exists, it doesn't need to detail return values. However, given the complexity of the tool (multiple nested role options), it lacks details on parameters like projectId and projectLabel, and could better explain the roles array structure. It is adequate but not thorough.

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

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

The schema has 4 top-level parameters with only 25% description coverage, but the description only lightly touches on the roles structure (browser, persona, goal) and does not clarify parameters like projectId or projectLabel. It mentions the output but not the input parameters meaningfully. The description should compensate for low schema coverage but falls short.

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 multiple AI agents as roles in a coordinated scene, with specific examples of use cases (publisher+viewer, buyer+seller) and communication via signal/wait_for_signal. It distinguishes itself from sibling tools like submit_test and submit_conversation_test, which do not handle multi-agent interaction.

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 examples of when to use the tool (e.g., livestream, marketplace, multi-user chat) and explains that each role gets its own browser, persona, and goal. It lacks an explicit statement of when not to use it, but the context is clear enough for an AI agent to differentiate.

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

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

Annotations indicate a write operation (readOnlyHint=false) that is not destructive or idempotent. Description adds beyond annotations by detailing that it triggers earnings, report, and client notification pipelines, and returns report id and pass/fail status. 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?

Three concise sentences effectively convey purpose, trigger effects, and return values. Front-loaded with primary action, 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?

With an output schema present (context has true), the description still adds value by naming specific return fields (report id, pass/fail status) and mentioning pipeline effects. For a 3-param tool with required fields, the description covers enough for an agent to understand invocation and outcomes.

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% (most parameters have descriptions). The tool description does not add new meaning to input parameters, focusing instead on output. Baseline 3 is appropriate as schema already explains parameters sufficiently.

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

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

Description clearly states the tool submits worker outcomes for a claimed job, using a specific verb and resource. It distinguishes itself from other submit_* siblings by mentioning the triggered pipeline (earnings, report, client notification) that matches the human checker submission process.

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 'for a claimed job', indicating prerequisite. Compares to human checker submission, providing context on when this tool is appropriate. No explicit when-not-to-use, but the context is clear enough for an 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 indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false, which already convey mutation and potential side effects. The description adds 'Queue a new job' and polling, but does not elaborate on costs, provisioning side effects (e.g., test inbox, persona creation), or rate limits. Given the complexity and openWorldHint, more disclosure would improve transparency.

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

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

The description is three sentences long and front-loaded with the core purpose. It is concise, though bullet points for runner comparison could improve structure. Still, every sentence earns its place without waste.

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

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

Given the tool has 32 parameters, 2 required, nested objects, and an output schema, the description is brief and does not provide a high-level summary of all use cases or nuances like offeringId, devicePreset, etc. While it covers the core idea, it lacks completeness for such a complex tool.

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

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

Schema description coverage is 100%, so the schema already documents all 32 parameters in detail. The description does not add any parameter-specific information beyond referencing get_test_status. Baseline 3 is appropriate as no extra value is added.

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 a new TestMyVibes job for a given URL, explicitly distinguishes between AI and human runners, and mentions the returned jobId for polling with get_test_status. This provides specific verb and resource, differentiating it from sibling tools.

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

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

The description provides guidance on when to use AI vs human runners based on speed and judgment needs. However, it does not explicitly advise when not to use this tool or mention alternatives like submit_test_batch for batch submissions. The context is clear but lacks exclusions.

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

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

Discloses cost premium (1.15× credits), return structure (batchId + per-test breakdown), and concurrency limit (3 workers). Annotations already indicate non-destructive write; description adds value with cost and parallelism details.

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

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

Compact single paragraph with key info front-loaded. No redundant sentences. Every sentence adds value.

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

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

Covers purpose, cost, return values, concurrency, and usage guidance. Output schema existence is noted context but description sufficiently describes return. Could mention error handling or rate limits but not essential.

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 schema fully describes parameters. Description adds minimal value by linking to sibling tool's input shape. Baseline of 3 is appropriate.

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

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

Description specifies verb 'submit', resource 'multiple AI tests', and distinguishes from serial submission. Mentions batch size limit (20) and AI runner exclusivity. Clearly separates from human-runner batching.

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 tells when to use: independent tests to run in parallel for speed. Also states when not: human-runner batching ships separately. Provides context for decision.

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

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

Beyond annotations (readOnlyHint=false, etc.), the description discloses key behaviors: audio is uploaded to Spaces, signed URL with 24h TTL, credits charged up-front, and voice options (voiceId or default). 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 concise (4 sentences) with the most critical information front-loaded. Every sentence adds distinct value without redundancy or fluff.

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

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

Given the tool's complexity (3 parameters, output schema exists), the description covers all necessary context: purpose, usage, behavioral details, and parameter nuances. It does not need to repeat the output schema as it is already declared.

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?

Despite 100% schema coverage, the description adds valuable context: 'split longer scripts' for the text maxLength, 'omit to use default narrator' for voiceId, and 'biases delivery without changing script' for the description parameter. This enriches the schema-provided 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 it generates a voiceover from text using Hume Octave TTS and returns an audio URL. It distinguishes itself from sibling tools like 'quote_voiceover' (cost preview) and 'Hume EVI' (real-time conversation), making its purpose unambiguous and differentiated.

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

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

The description explicitly states when to use this tool (demo-video narration, tutorial audio, one-shot batch TTS) and when not to (real-time conversation, pointing to Hume EVI as alternative). It also mentions using 'quote_voiceover' for a cost preview, providing clear usage boundaries.

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 behavioral context beyond annotations: it reveals that Stripe requires human payment completion due to their agentic-commerce policy, that credits are added automatically via webhook, and that the user must open the returned URL. This supplements the non-readOnly, non-destructive, non-idempotent annotations effectively.

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

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

The description consists of two concise sentences, each providing essential information without redundancy. It is front-loaded with the purpose and efficiently communicates the workflow and behavioral details.

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

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

The description covers everything needed: it states the return value (Stripe Checkout URL), explains the asynchronous credit addition, and directs the user to confirm via get_credit_balance. No critical information is missing, and the output schema existence is acknowledged.

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 adds value by explaining that packIndex is an index from list_credit_packs and by detailing the defaults for cancelPath and successPath. This extra context justifies a score of 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?

The description clearly states the tool's purpose: 'Buy more credits to fund test runs.' It specifies the resource (credits), the action (top-up), and the return type (Stripe Checkout URL). This distinguishes it from siblings like get_credit_balance, which is for checking balance.

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 when to use this tool: when the user needs more credits. It provides clear context by directing the user to poll get_credit_balance to confirm payment completion. While it does not explicitly state when not to use it, the instruction 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 significant behavioral context beyond annotations: details the state machine transitions, note appending behavior, and duplicate collapsing. It aligns with annotations (non-destructive write) and provides clear expectations.

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, each adding value: context (staff-only), operations (state machine, notes, duplicate), and output (returns record). No redundant or extraneous information.

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

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

Given the tool's complexity (state machine, multiple operations, permissions), the description covers all key aspects. The presence of an output schema means return value is handled externally. 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?

The description explains how each parameter is used in context (status for state machine, duplicateOf for marking, internalNotes for appending). With 75% schema coverage, the description complements the schema well, adding meaning beyond field names.

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

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

The description clearly states the verb (update, move, attach, mark), resource (feedback item), and scope (staff-only, state machine, duplicate). It distinguishes from sibling submit_feedback by emphasizing staff triage and state machine progression.

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

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

It specifies the tool is for staff-only triage and lists operations (status change, notes, duplicates). While it doesn't explicitly say when not to use it, the context of 'staff-only' and the state machine progression implies appropriate use cases. An explicit alternative like 'submit_feedback' would improve clarity.

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

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

The description claims 'Idempotent' but the annotation idempotentHint=false contradicts this, a serious inconsistency. No other behavioral traits (e.g., side effects, required permissions) are disclosed beyond basic upsert behavior.

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

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

Three sentences covering purpose, opt-in/out, and employment types. Concise but the opt-out mention is slightly tangential. Mostly well-structured 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?

Given 7 optional parameters, enums, and an output schema, the description covers main use cases and key constraints. Does not explain return values but output schema exists. Lacks details on limitations or rate limits, but enough for basic usage.

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 explaining the logic of employmentTypes, the need for shiftseeUserId when in_house, and the opt-in strategy (bio + specialties). Provides context beyond schema, such as settlement differences.

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's an 'Idempotent create-or-update for the calling account's worker profile,' specifying the resource, action, and scope. It distinguishes from sibling tools like create_worker_offering by focusing on the profile itself, not offerings.

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

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

Provides explicit guidance on when to use: opt-in by setting bio + specialties, opt-out via offerings (though indirectly). Explains the two employment types and their requirements (shiftseeUserId for in_house, defaultPayoutMode for external). Lacks a direct 'when not to use' statement but is clear in 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds specific information about what data is returned (role, staff flag, free domains, billing outcome) beyond the annotations, making the tool's behavior fully transparent.

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

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

The description is two sentences with no redundancy. The first sentence front-loads the return values, and the second sentence gives immediate usage guidance. Every sentence is necessary and well-placed.

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

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

For a tool with one optional parameter and an existing output schema, the description covers all necessary aspects: what it returns, when to use it, and the effect of the parameter. 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% with a full description for the optional 'targetUrl' parameter. The description reinforces that providing a URL gives the billing outcome, adding context that internal-use eligibility includes domain and billing checks, which goes slightly beyond the schema.

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

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

The description clearly states that the tool returns the calling account's identity (id/email/role) and billing eligibility (staff-flagged domains, billing outcome for a target URL). This specific verb+resource combination distinguishes it from siblings like submit_test or list_projects.

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

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

The description explicitly says 'Use this first when you bring TMV into a new project', providing a clear use case and context. It does not, however, discuss when not to use it or compare with alternatives, so it could be more detailed.

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