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

Annotations provide readOnlyHint, idempotentHint. Description adds key behaviors: returns final_answer for narration, handling of timeout/error, and trace spawning when agent_id is set. 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, front-loaded with purpose, followed by usage and error handling. Every sentence earns its place with no redundancy.

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

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

Covers purpose, usage, error handling, and delegation behavior. No output schema exists, but final_answer is mentioned. Minor gap: final_answer structure could be detailed, but sufficient for agent 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% with detailed descriptions. The description adds only minimal context (e.g., task_description should include everything). Baseline 3 is appropriate; no significant extra value.

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

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

The description clearly states it delegates multi-step tasks to a planner, contrasting with direct-answer tools. It specifies the verb 'delegate' and the resource 'full agentic planner', distinguishing it from sibling tools like agents_ask.

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 says 'use when a user ask needs more than a direct answer' and provides error-handling guidance ('Do NOT re-trigger... acknowledge and offer to retry'). While no alternative tool is named, the context is clear.

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

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

Discloses that the tool returns chunk_count which may be 0 while indexing, and that the file is agent-specific. Annotations minimal but description adds useful behavioral context about processing delay.

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?

Five sentences, front-loaded with purpose, then workflow, then return value explanation. 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?

Explains return value and workflow, but lacks error handling or additional notes on idempotency. Still sufficiently complete for a tool with good annotations and schema coverage.

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

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

Input schema has 100% description coverage. Description mentions parameters but adds no significant new meaning beyond schema definitions.

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

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

Clearly states the tool attaches a file to an agent's private knowledge, specifying it is agent-specific and not shared. Distinguishes from siblings like agents_remove_file and agents_list_files.

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

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

Provides a three-step workflow (upload, ingest, attach) and explains that chunk_count of 0 means processing, with suggestion to check later. Does not explicitly state when not to use, but workflow guidance is strong.

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

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

Adds meaningful behavioral context beyond annotations: mentions sending to a real person, optional editing, and warning about real-world impact. 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?

Concise, front-loaded with main action, includes examples and a warning. Slightly repetitive but efficient overall.

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

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

Complete description for a simple tool: explains action, outcome, optional edit, and provides usage examples. No output schema 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 descriptions fully cover both parameters (100% coverage), so baseline is 3. Description reinforces optional edit but doesn't add new details beyond schema.

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

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

Clearly states the action: approve a pending agent draft and send the message. Distinguishes from sibling tools like agents_reject_draft and agents_list_drafts.

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 user phrases for when to use (e.g., 'Approve this draft'), offers context for usage, but lacks explicit when-not-to-use guidance.

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

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

Beyond the basic annotations, the description discloses execution time (10-60s), return structure including status conditions ('replied'/'silent'), detailed attributes of messages (attachments, IDs), and how response_text and messages relate. This comprehensive behavioral disclosure adds significant value beyond the annotations.

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

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

The description is front-loaded with the purpose, followed by detailed return information. While every sentence adds value, the detailed enumeration of return fields could be slightly more concise. Overall, it is well-structured and informative without being excessively long.

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 absence of an output schema, the description provides a thorough explanation of the return format, including edge cases (status='silent'), token usage, and execution time. It also covers the behavior of send_mode relative to agent config. This makes the tool's behavior fully predictable for an 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?

Schema description coverage is 100%, so each parameter (message, agent_id, send_mode) is already well-documented in the input schema. The description does not add new information about parameter usage or constraints beyond what the schema 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's function: 'Send a message to an AI agent and get its response.' It further clarifies use cases: 'Use this to test agents or have them process a task.' This distinguishes it from sibling tools like agents_create (creating agents) or agent_handoff (handoff actions), providing a specific verb and resource.

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

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

The description provides clear usage context by stating the tool is for testing agents or processing tasks. It does not explicitly exclude scenarios or name alternatives, but the purpose is well-defined, and the context is sufficient for an AI agent to decide when to use this tool over other agent-related tools.

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

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

Annotations indicate it is a write operation (readOnlyHint=false). The description adds context about execution modes and defaults (send_mode), but does not cover return values or side effects. 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?

Description is front-loaded with the main purpose and organized with bullet points. A few minor verbose parts but overall 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?

Missing information about return values (e.g., created agent ID) and required permissions. With no output schema, the description should cover what the tool returns. Otherwise adequate for a creation 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 value by explaining execution modes beyond enum labels, and provides usage context for parameters like send_mode and execution_mode.

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 'Create a new AI agent in the workspace' with a specific verb and resource. It distinguishes from sibling tools like agents_update and agents_delete.

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 each execution mode (ai_assisted for keyword filtering, agentic for complex tasks, rule_based for simple). Does not explicitly state when not to use the tool, but the context is clear.

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

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

The description discloses that deletion is permanent and removes triggers, but the annotation destructiveHint=false contradicts this, indicating a serious inconsistency. Scoring is low due to contradiction.

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

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

Two sentences: the first states the purpose, the second provides a critical warning. No unnecessary words, 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 simple destructive action with no output schema, the description covers the action, irreversibility, and what is removed. It could mention the return value or confirmation, but it is reasonably 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 is one parameter (agent_id) with a schema description, and the tool description adds no additional meaning beyond that. Schema coverage is 100%, 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 'Permanently delete an AI agent' with a specific verb and resource, and it distinguishes from sibling tools like agents_create and agents_update.

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

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

The warning 'This cannot be undone' hints at use when irreversible deletion is intended, but it lacks explicit guidance on when to use this tool versus alternatives or when not to use it.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, but description adds value by enumerating exact return fields (execution config, tool config, etc.). No contradictions. Provides 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?

Description is appropriately sized; first sentence clearly states purpose, followed by a bulleted list of return fields. No fluff. Every sentence adds value. Could be slightly more compact but is 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 tool has only one parameter and strong annotations, the description fully covers what the tool does and what it returns. No output schema, so the detailed list compensates. Complete enough for an agent to use correctly.

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

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

Single parameter agent_id with schema description 'ID of the AI agent to fetch'. Schema coverage is 100%, so description doesn't need to add more. Description does not elaborate on the parameter, but 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 starts with clear verb 'Get' and resource 'detailed information about a specific AI agent'. Lists specific return fields, distinguishing it from siblings like agents_list (for listing) and agents_create (for creation). This provides exact, unambiguous purpose.

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

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

Usage context is implied by purpose ('specific' vs list), but no explicit mention of when to use this tool vs alternatives (e.g., agents_list). No guidance on prerequisites or when not to use it. Adequate but minimal.

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, and idempotentHint=true, which cover safety. The description adds valuable context: it ends the turn, and that narrated silence would be delivered verbatim to the guest. This goes beyond 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 four sentences, each carrying weight: core action, use cases, warning about alternative, and emphasis on correctness. No wasted words, and the key point is front-loaded.

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

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

Given the tool's simplicity (one parameter, no output schema, clear annotations), the description is fully adequate. It covers purpose, usage, and a critical behavioral nuance, leaving no gaps for a typical use case.

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

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

Schema coverage is 100% with the 'reason' parameter described in the schema. The description does not add extra meaning or context for the parameter beyond what the schema provides, so 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 ends the turn without sending a message, and explicitly distinguishes it from alternative actions like narrated silence. The verb 'end' and resource 'turn' are specific, and the purpose is unmistakable.

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 lists explicit scenarios for use (after job.escalate, self-resolving, duplicate, observation-only) and warns against using narrated silence as an alternative. This provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns basic info, trigger count, and knowledge collection count, 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?

Description is three paragraphs with front-loaded purpose. The bullet list slightly repeats the first sentence but overall efficient and well-organized.

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

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

For a simple list tool without output schema, the description explains return fields (basic info, counts) and filter option. Covers main aspects adequately.

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

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

Schema coverage is 100% with a clear description for the 'enabled' parameter. The description restates filtering capability but does not add new semantic meaning 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 'List all AI agents configured in the workspace' with a specific verb and resource. It differentiates from sibling tools like agents_create or agents_delete.

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 use cases (see all agents, filter, get IDs) but does not mention when not to use or alternatives. Still clear context.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about draft content (thread info, trigger message, generated response, creation/expiration) beyond what annotations provide, enhancing transparency without contradiction.

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

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

The description is well-structured with a concise introductory sentence followed by bullet points for included fields. It is not overly verbose, and each element serves a purpose, though the bullet list could be slightly more compact.

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

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

The description covers the tool's purpose, input semantics via schema, and output content. It lacks explicit details about pagination or error handling, but for a read-only list tool with good annotations, it is fairly complete.

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

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

Schema description coverage is 100% as both parameters have descriptions. The description does not add additional parameter-level detail beyond what is in the schema, so it meets the baseline without extra value.

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

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

The description clearly states 'List pending agent drafts awaiting approval' with a specific verb and resource. It lists included fields and provides example user queries, distinguishing it from sibling tools like agents_approve_draft and agents_reject_draft.

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 example queries for when to use the tool, offering clear context. It does not explicitly state when not to use it or mention alternatives, but the context makes it clear that it's for listing drafts only.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read. The description adds value by explaining the return fields and that chunk_count=0 means processing. 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?

Three concise sentences: purpose, return fields, and related tool usage. No fluff, 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?

The description covers purpose, return values, and a special case (chunk_count=0). It does not mention pagination or limits, but for a simple list tool this is adequate.

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

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

Schema coverage is 100% with a clear description for agent_id. The description does not add further parameter meaning beyond what the schema provides, so baseline score applies.

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

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

The description clearly states the verb 'List' and resource 'files directly attached to this agent', with explicit differentiation from shared collections. It also specifies the return fields, making the purpose unambiguous.

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

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

The description tells when to use this tool (list agent-specific files) and provides alternatives: 'Use agents.add_file to attach a new file, or agents.remove_file to detach one.' It implicitly distinguishes from sibling list tools by stating 'not shared collections'.

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 every edit is snapshotted to an append-only table, providing behavioral context beyond annotations. It could mention ordering or pagination, but overall sufficient.

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

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

Two sentences, no wasted words. The purpose is front-loaded, and 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?

The description provides a clear use case and hints at return content (versions with prompt_text). No output schema exists, but the tool is straightforward. Minor gap: ordering of results is not specified, but cursor parameter implies descending.

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

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

Schema coverage is 100% with descriptions for all three parameters (agent_id, limit, before_version). The description does not add further meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool lists past versions of an agent's prompt_text, using specific verbs and resource. It distinguishes itself from siblings like agents_prompt_restore by specifying its role in browsing history and finding prior versions.

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

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

The description explicitly tells when to use the tool ('browse history, find a prior known-good version') and how to use it ('copy it into agents.prompt_restore'), providing clear alternatives and highlighting its read-only nature.

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 that it creates a new version pointing to restored content and that history is preserved, which goes beyond annotations (destructiveHint: false, readOnlyHint: false) by explaining the non-destructive behavior.

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

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

Two sentences, no filler. First sentence states purpose, second gives usage guidance. Efficient 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?

Complete for a restore operation: explains what it does, how to use it, and that history is preserved. Lacks return value info but no output schema exists.

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

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

Schema coverage is 100% with descriptions, so the baseline is 3. The description adds minimal extra meaning (e.g., where to get version_number) but mostly repeats schema 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 restores a past version of an agent's prompt_text by version_number, preserving history. It distinguishes itself from siblings like agents_prompt_history (which lists versions) and prompts_prompt_restore (for prompts).

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

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

Explicitly instructs to use agents.prompt_history first to find the version_number. No explicit when-not-to-use, but the context is clear and the sibling tool prompts_prompt_restore provides an alternative for prompts.

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 discloses that 'The draft will be marked as rejected and won't be sent', which is behavioral context beyond annotations. 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?

Concise, front-loaded, with a list of example phrases. No unnecessary 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?

For a simple action with good schema, description adequately explains behavior. No output schema needed. Could mention logging 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%; description adds no extra meaning beyond what schema already provides. Baseline 3 is appropriate.

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

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

Title 'Reject Agent Draft' and description 'Reject a pending agent draft without sending' clearly state the verb and resource. It distinguishes from sibling 'agents_approve_draft'.

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

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

Explicitly states when to use: 'when the generated response isn't appropriate' and provides specific user phrases. Implies not to use when approval is needed.

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 the file is not deleted but only detached, which is important behavioral context. Annotations are non-destructive, so description adds clarity beyond them.

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

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

Two concise sentences with no wasted words. Front-loads the main action and clarifies side effects immediately.

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 removal tool with no output schema, the description fully covers behavior, prerequisite knowledge (agents.list_files), and consequences (detachment). Complete and self-contained.

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

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

Schema coverage is 100% with descriptions. The description adds context for file_id (from agents.list_files), which provides additional meaning 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?

Specifically describes the action 'Remove a file from this agent's private knowledge' and distinguishes it from deleting by noting the file is 'just detached'. Clear verb and resource.

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

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

Clearly states the tool's purpose and references agents.list_files for finding file_id, but does not explicitly mention when not to use or compare to siblings like agents_add_file.

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 discloses behavioral traits: drafts overwritten, auto mode sends real messages, router uses production logic. However, annotations (readOnlyHint=true) contradict the ability to send real messages with 'auto' mode, which is a significant inconsistency. Despite this, description adds value beyond annotations.

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

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

The description is thorough but somewhat lengthy (3 paragraphs). It is well-structured, front-loading the main action and then detailing parameters. Could be slightly more concise, but all sentences are informative.

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 6 parameters with nested objects and no output schema, the description provides a complete picture: it explains the return structure for both matched and unmatched cases, covers edge cases (system_message, blockchain), and addresses behavior differences between draft and auto modes.

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

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

With 100% schema description coverage, the description still adds meaning: explains send_mode trade-offs, system_message shape and purpose, blockchain_tx_data usage, and attachment_file_ids for testing image-aware agents. This goes beyond schema descriptions.

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

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

The description clearly states the tool replays an inbound message through the trigger pipeline and returns what would have happened. It specifies the verb (simulate), resource (inbound message routing), and distinguishes from siblings like agents_ask by focusing on verification of routing logic rather than actual message sending.

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

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

Explicitly states when to use: 'verify routing for a thread' and provides alternatives like blockchain_tx_data for simulating blockchain events. Also gives guidance on send_mode: 'draft' for safe simulation, 'auto' for end-to-end testing on test accounts.

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 non-destructive, non-readOnly behavior. The description adds context that the tool reports completion, which implies a state change. It does not contradict annotations and provides adequate behavioral insight for an agent.

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 purpose, and contains no extraneous information. Every sentence serves a clear function.

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 notification tool with no output schema and 100% parameter coverage, the description fully informs the agent about when and why to use this tool. It is complete given the tool's complexity.

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

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

Schema coverage is 100% for all 3 parameters. The description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 applies.

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

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

The description clearly states the tool reports agent task completion, with a specific verb ('Report') and resource ('Claude Code agent task'). It distinguishes from sibling agent tools by specifying the exact event (finishing an agent_task from DialogBrain).

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 'Call this when you finish processing an agent_task from DialogBrain,' providing clear context for when to use it. It does not mention alternatives or when-not-to-use, but the context is sufficient given the tool's narrow scope.

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, idempotentHint=true, destructiveHint=false. Description adds beyond that: default stripping of LLM bodies, WARNING audit log when include_llm_bodies is set, truncation behavior, and that completion_text on failed LLM calls is always returned (capped at 8KB). 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?

Description is extremely concise: one paragraph with clear front-loading of main purpose, then usage guidelines, then parameter details. No wasted words; every sentence adds value.

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

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

Despite no output schema, the description lists what the trace contains (tool executions, events, LLM call spans with error_message) and mentions key behavioral details. This is sufficient for an agent to understand the return value and when to use the tool, making it complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaningful context: trace_id comes from agents_traces_list, agent_id for scope validation, include_llm_bodies triggers audit log, full is for human operator escape hatch. This elevates beyond schema alone, justifying a 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 'Fetch the full execution detail for a single trace — tool executions, events timeline, LLM call spans', with a specific verb and resource. It distinguishes itself from sibling tools like agents_traces_list by specifying that this is for a single trace after identification.

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

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

Explicitly states 'Use after agents.traces_list identifies a specific trace of interest (failed run, slow run, unexpected outcome)'. Provides context for when to set include_llm_bodies and full, offering clear usage guidance and 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?

Discloses edge case of dropped_on_page (should be 0, positive means backend bug) and pagination behavior (offset increment when has_more true). Annotations already declare readOnlyHint and idempotentHint, and description adds important behavioral nuances beyond those.

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

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

Concise at 6 sentences, front-loaded with purpose and usage, then filters and return fields. Every sentence earns its place with no redundancy.

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

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

Despite lack of output schema, description explains return fields and edge case. For a list tool with 8 parameters, it covers purpose, usage, filters, return format, and a specific edge condition. No obvious gaps.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minor value (source comma-separated values, known bug with source='agent' matching voice, ISO-8601 format for dates). Not transformative but helpful.

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 execution traces for an agent, distinguishing from sibling tools like agents_trace_get (for full detail) and agents_traces_stats (presumably stats). It specifies the data source (/admin/requests) and that it's scoped to one agent.

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 when-to-use scenarios (timeout, wrong draft, latency analysis) and pairs with agents_trace_get for further detail. Does not explicitly state when not to use, but the use cases are clear and context is strong.

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

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

Description adds context beyond annotations (e.g., scoped to exact agent match, days capped at 30 due to TTL), but annotations already cover readOnly and idempotent hints.

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; front-loaded with purpose then usage guidance.

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 100% schema coverage and no output schema, the description lists returned metrics adequately, though output format details are omitted.

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 both parameters with descriptions; description adds extra context like the TTL cap and workspace ownership, adding value beyond schema.

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

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

The description uses specific verbs ('aggregated trace statistics') and lists concrete metrics (total runs, success rate, etc.), clearly distinguishing it from sibling tools like agents.traces_list and agents.trace_get.

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 this tool ('bird's-eye view before diving into individual traces') and names alternatives (agents.traces_list / agents.trace_get).

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

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

The description adds context beyond annotations, detailing trigger types and complex condition fields. Annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries the burden and does so well.

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

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

The description is front-loaded with the purpose, but the conditions section is extensive and verbose. While structured, it could be more concise by referencing external documentation for detailed conditions.

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

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

Given the complexity of triggers and nested conditions, the description provides substantial detail without needing an output schema. It explains trigger types and condition fields comprehensively.

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

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

Schema coverage is 100%, but the description adds significant value with detailed explanations for the 'conditions' parameter, covering supported fields and their behavior. For other parameters, it repeats schema info but adds clarity.

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 'Create a new trigger for an AI agent' and explains trigger types and their activation conditions. It distinguishes from sibling tools like agents_trigger_update and agents_trigger_delete.

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 lists trigger types and conditions but does not explicitly state when to use this tool vs alternatives like agents_trigger_update. No direct guidance on when not to use it.

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

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

The description includes a strong warning: 'WARNING: This cannot be undone,' which adds critical behavioral transparency about irreversibility beyond the annotations. However, the annotations set destructiveHint=false, which contradicts the implied destructiveness, slightly reducing clarity.

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

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

The description is extremely concise: two sentences, the first clearly stating the action and the second adding a crucial warning. No extraneous words or redundant 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 delete operation, the description covers the essential purpose and the irreversible nature. It lacks details about success/failure conditions or side effects, but given the straightforward nature and full schema coverage, it is largely complete.

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

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

Parameter schema coverage is 100%, and both parameters (agent_id, trigger_id) have clear descriptions in the schema. The tool description does not add any additional semantic information 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 specific action: 'Delete a trigger from an AI agent.' The verb 'delete' and resource 'trigger' are unambiguous, and it distinguishes itself from sibling tools like agents_trigger_create and agents_trigger_update.

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 (e.g., other delete tools or update operations). It does not mention prerequisites, such as ownership or permissions, nor does it indicate when deletion 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?

Annotations indicate readOnlyHint=false, destructiveHint=false, consistent with an update operation. The description adds that parameters are optional, providing some behavioral context, but does not disclose side effects, authorization needs, or other traits beyond what annotations already 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 extremely concise with two short sentences. The first sentence states the purpose, and the second provides a critical usage nuance. Every word is purposeful, 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 high schema coverage (100%) and presence of annotations, the description is largely sufficient. It covers the partial update behavior, which is key. However, it could briefly mention that the 'conditions' parameter replaces existing conditions (though detailed in schema) for completeness.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds that all parameters are optional, which is not explicitly stated in each schema description but is implied. It does not add significant new meaning beyond the schema.

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

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

The description clearly states the tool updates an existing AI agent trigger, which is a specific verb-resource combination. It distinguishes itself from sibling tools like agents_trigger_create (create new trigger) and agents_trigger_delete (delete trigger) by using 'update' and 'existing'.

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

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

The description mentions that all parameters are optional and only provided fields are updated, giving useful context for partial updates. However, it does not explicitly state when to use this tool versus alternatives (create, delete) or provide any exclusions.

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

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

Description goes beyond annotations (readOnlyHint=false, destructiveHint=false) by noting 'All parameters are optional' and flagging prompt_text as 'DESTRUCTIVE', plus detailed parameter-specific behavior like model switching nuances.

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

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

Description is front-loaded with purpose, then optionality note, then bulleted use cases. It is slightly lengthy due to complexity but well-organized; could trim some 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?

For a tool with 45 parameters, description covers major use cases and relationships (e.g., model/prompt_text interplay). Missing output schema info but annotations provide no output schema, so this 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?

With 100% schema description coverage, the tool description adds value by framing optionality and grouping use cases, though it does not detail each parameter. The bullet list helps agents understand which parameters to use together.

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 'Update an existing AI agent's configuration' and lists specific use cases (enable/disable, change name, etc.), distinguishing it from sibling tools like agents_create and agents_get.

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

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

Description explicitly lists 'Use this to:' with bullet points, covering key scenarios. It notes all parameters are optional but does not explicitly exclude when not to use, though context implies for updates only.

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

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

The description goes beyond annotations by explaining the use of Voyage AI embedding API, vector embeddings, cosine similarity, and how the description becomes the reference vector. Annotations only indicate it's not read-only and has side effects, but the description adds rich 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 multi-paragraph but well-structured. It starts with the purpose, then explains the mechanism, gives examples, explains threshold, and notes the external API call. Each section adds value, though slightly verbose.

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

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

Given the complexity of AI filters and no output schema, the description covers the creation process, parameter usage, and external API call. It is sufficient for an agent to understand when and how to use the tool effectively.

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 good descriptions, but the tool description adds significant value: it provides examples for the description field, explains threshold sensitivity with concrete numbers, and emphasizes the critical role of the description in filter accuracy.

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 'Create a new AI filter for semantic intent-based message matching' with a specific verb and resource. It distinguishes from sibling tools like ai_filters_delete, ai_filters_update, etc., by focusing on creation.

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

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

The description explicitly explains when to use this tool (to create an AI filter) and provides guidance on how to write the description and set the threshold. It does not directly mention when not to use it or alternatives, but the context makes it clear.

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

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

Discloses permanence ('cannot be undone') and side effect on triggers ('triggers that reference this filter by ID will no longer match it'). The annotations (destructiveHint=true) align and are supplemented by detailed 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?

Extremely concise: three short paragraphs with no wasted words. The action is front-loaded, and each sentence adds value.

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

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

For a simple delete operation with one parameter and no output schema, the description fully covers purpose, usage, irreversibility, and downstream effects. 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 one parameter filter_id described as 'ID of the filter to delete.' The description adds no further semantics beyond the schema, meeting the baseline for high 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 'Permanently delete an AI filter,' specifying the action and resource. It distinguishes from sibling tools like ai_filters_create and ai_filters_list.

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

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

Provides a clear 'When to use' section: 'User wants to remove a filter they no longer need.' Lacks explicit when-not-to-use or alternatives, but the context is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: it explains that AI filters are semantic intent-based using embeddings and cosine similarity, and that the operation returns all filters. This goes beyond the annotations and provides full transparency.

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

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

The description is well-structured: a purpose statement, an explanation of AI filters, usage scenarios, and return details. Every sentence adds value, and it is appropriately concise.

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

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

Given no parameters and no output schema, the description provides complete information: what it does, what it returns (fields), and contextual understanding of AI filters. It is fully sufficient for an agent to use the tool correctly.

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

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

Input schema has zero parameters (100% coverage), so baseline is 4. The description adds meaning by explaining the nature of AI filters and the output fields, which is sufficient.

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

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

The description clearly states 'List all AI filters for the current workspace' and specifies the returned fields (id, name, description, threshold, is_active). This is specific and distinguishes it from sibling tools like ai_filters_create, ai_filters_delete, etc.

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

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

The description includes a 'When to use' section with explicit scenarios: check existing filters before creating, get filter IDs for triggers, review thresholds and active status. While it provides clear usage context, it does not explicitly mention when not to use or compare with alternatives.

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

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

The description goes beyond annotations by revealing that the tool calls the Voyage AI embedding API and computes cosine similarity. It confirms the tool is idempotent and safe, consistent with annotations, and provides detailed 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 efficient and well-structured: purpose, mechanism, use cases, output format, and a note on API call. No redundant sentences, and every part 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?

Despite lacking an output schema, the description explicitly states the return format {similarity, matched, threshold}. It covers behavioral traits, usage guidelines, and parameter roles, making it fully complete for a test tool.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description adds marginal value by explaining the role of message in embedding and threshold comparison, but the schema already handles the semantics adequately.

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

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

The description clearly states the tool tests a message against an AI filter to check for matches, explaining the embedding and cosine similarity computation. It distinguishes itself from sibling tools like ai_filters_create, ai_filters_delete, etc.

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

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

The description explicitly lists three use cases: verify filter before use, tune threshold, debug production issues. It provides clear context for when to use the tool, though it doesn't explicitly state when not to use it or mention 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 indicate readOnlyHint=false and destructiveHint=false, but the description adds critical behavior: calling the Voyage AI embedding API to re-generate the reference vector when description changes. This goes beyond annotations and helps the agent anticipate side effects. No contradiction with annotations.

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

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

The description is concise with three paragraphs: main action, when-to-use list, and a note about re-embedding. It front-loads the purpose and avoids unnecessary detail. Could be slightly more compact, but every sentence serves a purpose.

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

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

Given no output schema and 5 parameters, the description covers the key aspects: what fields can be updated, the effect of changing description (API call), and the threshold range implied by min/max in schema. It provides enough context for an agent to invoke correctly, though it lacks clarification on whether partial updates are always allowed when some fields are omitted.

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

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

The input schema has 100% description coverage, so baseline is 3. The description adds value by explaining threshold meaning ('higher = stricter matching') and clarifying that changing description triggers an embedding API call. It also reinforces that at least one field must be changed (though schema only marks filter_id as required). This enriches 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 updates an AI filter's name, description, threshold, or active state. It distinguishes itself from sibling tools like ai_filters_create and ai_filters_delete by focusing on modification. The verb 'Update' and resource 'AI filter' are specific and unambiguous.

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

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

The description explicitly lists when to use the tool (rename, refine description, adjust threshold, enable/disable). It also advises to provide only fields to change and that at least one field is required. However, it does not explicitly mention when not to use it or compare to alternatives like ai_filters_test, but the provided guidance is clear and helpful.

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

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

Annotations already indicate mutation (readOnlyHint=false). Description adds key detail: 'If a tag is already applied it will be updated to is_manual=true', which is not obvious from annotations. This enriches behavioral understanding.

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?

Extremely concise: one-line title, brief 'When to use' section, parameter instruction, and a single behavioral note. Every sentence adds value; 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?

For a simple 2-parameter mutation tool with no output schema, the description covers purpose, usage, parameter constraints, and idempotency behavior. Minor omission: no mention of prerequisite (e.g., tags must exist), but overall sufficiently 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?

Both parameters are covered 100% in the input schema. The description restates them without adding new semantic meaning beyond the schema descriptions. Baseline score of 3 is appropriate.

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

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

Clearly states the verb 'apply', the resource 'AI tags to a thread', and adds 'manually' to distinguish from automatic tagging. The purpose is specific and distinct from siblings like 'ai_tags_remove_from_thread'.

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 'When to use' scenarios: user wants to label a conversation or categorize/tag a thread. Lacks direct exclusions or alternatives, but the context is clear and useful.

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

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

Annotations indicate this is not read-only or destructive; description adds that tags run on every incoming message and auto-label threads when criteria match. It also mentions limits (20/50 active tags), providing behavioral context beyond annotations.

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

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

The description is well-structured with a summary, conceptual explanation, usage guidance, tips, and limits. It is front-loaded with the core purpose, and each section adds value. While slightly long, it remains efficient.

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

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

Given the tool's moderate complexity and zero output schema, the description covers purpose, usage, key behavioral details, and parameter guidance. It provides enough context for an agent to decide when to use it and how to fill in the description field correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that the 'description' parameter is a classifier prompt, with tips for specificity and examples. This enhances understanding beyond the schema's brief 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 opens with a clear action verb and resource ('Create a new AI tag'), immediately distinguishing it as a creation tool. It explains the concept of AI tags as lightweight classifiers that auto-label threads, distinguishing it from sibling tools like ai_filters_create which may have different behavior.

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

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

The description includes a 'When to use:' section with two explicit scenarios: auto-classifying incoming messages and reducing costs by pre-filtering. While it does not explicitly state when not to use it compared to alternatives, the context is very 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 destructiveHint: true, so the description adds value by explaining that thread associations are removed automatically and threads are not deleted. It also states the action cannot be undone. This provides behavioral context beyond what annotations offer, without contradiction.

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

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

Four sentences, front-loaded with the main action, followed by a clear usage guideline and consequence statements. No unnecessary words or repetition.

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

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

Given the simple nature of the tool (one parameter, no output schema) and high schema coverage, the description fully explains the operation, when to use it, and its effects. It covers all relevant aspects for an AI agent to invoke correctly.

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

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

Schema coverage is 100% and the parameter tag_id is well-described in the schema. The description does not add extra semantics beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states it deletes a personal AI tag and automatically removes thread associations. It uses the specific verb 'delete' and resource 'personal AI tag'. It distinguishes from siblings like ai_tags_remove_from_thread which only removes tag from a thread without deletion.

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?

Includes a 'When to use' section specifying the scenario for permanent removal. It clarifies threads are not deleted and the action is irreversible. However, it could explicitly mention alternatives like ai_tags_remove_from_thread for when the goal is to just detach the tag.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable context: returns all tags with thread counts for non-archived included threads only, and explains the underlying auto-classification mechanism. 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 well-organized: a one-line summary, a paragraph explaining AI tags, a bulleted 'When to use' section, and a note on return format. 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?

The tool has no parameters and no output schema. The description fully covers what the tool does, when to use it, and what data it returns (tags with thread counts, non-archived, included threads only). No gaps remain for an agent to understand its 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?

No parameters exist in the schema (schema coverage 100%). The description explains what the tool returns (tags with thread counts), which is the relevant semantic information for an agent.

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 'List all personal AI tags' with precise verb and resource, and includes a clear explanation of what AI tags are. Siblings like create/delete/update/add/remove are clearly distinct, making purpose unambiguous.

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

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

The description provides explicit usage scenarios: checking existing filters before creating, getting IDs for add/remove, and viewing thread counts. This guides the agent on when to use this tool versus related tools.

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

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

The description states the removal action, which aligns with annotations (destructiveHint: true). However, it does not add behavioral context beyond what annotations already provide (e.g., no mention of side effects or permissions).

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: one sentence plus a bulleted list. No unnecessary words, and the key information is front-loaded. 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?

The tool has two required parameters and no output schema. The description covers purpose and usage context. It is complete enough for a simple removal operation, though it could mention the lack of return value or error cases.

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

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

Schema coverage is 100% with parameter descriptions already present. The description adds no additional meaning beyond instructing to provide both IDs. 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 verb ('Remove') and resource ('a specific AI tag from a thread'). However, it does not explicitly distinguish from the sibling tool 'ai_tags_add_to_thread', though the name itself provides differentiation.

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 'When to use' examples (un-labeling, correcting tags) and instructs to provide both thread_id and tag_id. It does not mention when not to use or alternatives, but the guidance is sufficient.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false. The description adds context: updates apply to 'existing' tags, at least one field is required. No contradictions. It does not detail side effects, but the mutation is clear.

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

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

The description is concise: two sentences plus a bullet list. It front-loads the purpose, lists when-to-use scenarios, and closes with a usage note. 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?

With 6 parameters (1 required), no output schema, and clear sibling tools, the description covers the essential usage. It lacks details on the return value, but the update context is sufficiently explained for tool selection.

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

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

Schema coverage is 100% with descriptions. The description adds value by stating 'Provide only the fields you want to change' and 'At least one field is required,' which guides partial updates. Baseline for high coverage is 3, but the added guidance lifts 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 explicitly states 'Update an existing personal AI tag's name, description, icon, color, or active state.' This clearly identifies the verb (update) and resource (personal AI tag), and distinguishes it from sibling tools like ai_tags_create or ai_tags_delete.

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 'When to use' bullet points (rename, change icon/color/description, enable/disable). It notes partial updates are allowed. It does not explicitly exclude cases or name alternatives, but the sibling tool names imply creation/deletion.

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

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

The description adds context beyond annotations by explaining that it loads saved cookies and storage. However, the readOnlyHint annotation might contradict the act of modifying the page's identity, though likely not severe. The description is clear about the non-destructive nature of loading saved state.

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 and followed by usage guideline. Every sentence adds value with no redundancy.

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

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

The tool is simple with 2 required params and no output schema. The description covers purpose and usage constraints well, but lacks details on return behavior or potential side effects beyond loading cookies. Still, it is largely complete for its 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?

Input schema has 0% description coverage and the tool description does not explain the parameters (page_id, identity_name). The identity_name is mentioned in guidelines but no added detail on format or purpose. The description fails to compensate for the schema gap.

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

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

The description clearly states the action ('Switch the page's identity') and the mechanism ('loading saved cookies + storage'). It distinguishes from the sibling tool 'browser_open' by specifying when to use which, making the purpose unambiguous.

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

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

The description gives explicit guidance: 'Use only when switching identity mid-page; for first navigation, pass identity_name to browser.open instead.' This clearly states when to use and when not, with a direct pointer to an alternative.

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 says 'Click an element' implying a mutating action, but annotations set readOnlyHint=true, which contradicts the tool's purpose. No additional behavioral context is provided beyond this 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 extremely concise with one sentence and an example, containing no unnecessary words. It is front-loaded with the core action.

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

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

Despite a simple tool and existing annotations, the description is incomplete: it omits return behavior, side effects (e.g., navigation), and fails to resolve the annotation contradiction. Minimal viability is compromised.

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

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

Schema description coverage is 0%, placing high burden on description. The description only explains `ref` as a CSS selector, leaving `page_id` undocumented and adding marginal value for one of two parameters.

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

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

The description clearly states 'Click an element' and specifies that `ref` is a CSS selector, which is a specific verb-resource combination. It effectively distinguishes from sibling browser tools like browser_fill or browser_hover.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., browser_fill, browser_hover). The description lacks context on prerequisites or 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds that the tool only applies to pages opened by browser.open, but does not elaborate on side effects or error behavior, making additional transparency limited.

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

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

The description is a single sentence that conveys the essential purpose without wasted words. Every word is necessary to specify both the action and the constraint on the page's origin.

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

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

Given the tool's simplicity (one parameter, no output schema, annotations covering behavior), the description is largely adequate. It explains what the tool does and when it's applicable. However, it could briefly mention that closing an invalid page may produce an error or no effect, but completeness is high for this simple action.

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

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

The input schema has 0% description coverage for the sole parameter 'page_id'. The description does not explain what page_id represents or how to obtain it (e.g., from browser.open return value). With no param info in the description, the agent must infer from context, adding little value over the schema's type and required flag.

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 closes a page, specifying it must be one opened by browser.open. This verb+resource combination is specific and distinguishes it from sibling browser tools like browser_navigate_back or browser_tabs.

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 browser.open, but provides no explicit guidance on when not to use it (e.g., for pages not opened by browser.open) or alternatives. It lacks exclusions or context about prerequisites like verifying the page exists.

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, non-destructive behavior. The description adds valuable context: buffer cap of 500 entries, oldest dropped first, and the effect of the clear parameter. 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 three concise sentences. The first sentence states the purpose, the second lists filters, and the third adds behavioral details (buffer limit, clear peeking). 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?

The description covers purpose, filtering, and buffer behavior. It does not specify the return format (e.g., structure of events), but for a simple read-only logging tool this is acceptable. Annotations and description together provide sufficient context for correct 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?

With 0% schema description coverage, the description explains three of four parameters: level (with example values), pattern (regex), and clear (peek vs drain). The page_id parameter is not explicitly described but its purpose is implied from the tool name and 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?

The description clearly states the tool returns console messages (log/warn/error) and mentions filtering. It distinguishes from sibling browser tools like browser_click or browser_snapshot by specifying the console event resource.

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: it returns events since last drain, and advises using clear=false to peek without draining. However, it does not explicitly compare to alternatives, though none 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?

Description claims a write operation ('Drag one element onto another'), but annotations declare readOnlyHint: true, which is a direct contradiction. Also no mention of behavioral details like potential side effects or requirements beyond parameter types.

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 extraneous words, front-loaded with action and immediately clarifies parameter purpose.

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

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

Lacks explanation of return behavior since no output schema is provided. Does not cover page_id or potential failure modes. Adequate for a simple drag operation but incomplete given the annotation contradiction.

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?

Description explains source_ref and target_ref as CSS selectors, adding context beyond the schema's property names. However, it does not explain the page_id parameter, which is required, and schema coverage is 0%.

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

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

Description clearly states the action 'Drag one element onto another', explains the two CSS selector parameters, and gives explicit use cases like slider captchas, kanban, and drag-and-drop uploads. This distinguishes it from sibling tools like browser_click or browser_hover.

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

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

Provides clear examples of when to use (slider captchas, kanban, drag-and-drop uploads), but does not explicitly mention when not to use or list 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds beyond that: expression can be a value or arrow function, result is JSON-serialized with non-serializable becoming strings, and a 256KB output cap. No contradiction.

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

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

Two sentences that are well-structured: first sentence states purpose and use cases, second adds syntax details and constraints. No redundant 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 tool with 3 parameters and no output schema, the description covers syntax, serialization behavior, output size limit, and use cases. It provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 0% (no descriptions in schema). The description explains that 'expression' can be a value or arrow function, and the 'arg' parameter is used to pass arguments to the arrow function. This adds meaning beyond the bare schema types.

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 action: 'Run JavaScript in the page context and return the result.' It specifies use cases (state not in a11y tree, captcha iframe inspection, DOM events), distinguishing it from sibling browser 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 specific scenarios for use ('state not in the a11y tree, captcha iframe inspection, DOM events'), implying when to use. It does not explicitly mention when not to use or alternatives, but the context is clear.

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

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

The description states 'Attach files', implying a mutation, but annotations declare `readOnlyHint=true`. This is an annotation contradiction per the rubric, requiring a score of 1.

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

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

Two sentences with no extraneous information. The main action is front-loaded. Every sentence adds value.

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

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

Covers the two input modes, temp file handling, and size limit. Missing details on the required `page_id` and `ref` parameters, but otherwise fairly complete.

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

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

Schema coverage is 0%, so the description must compensate. It explains `local_paths` and `data` but omits `page_id` and `ref`, which are required. Partial compensation.

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

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

The description clearly states the tool attaches files to an <input type=file> and distinguishes the two methods of providing file content. This is specific and separates it from other browser interaction tools.

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

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

The description explains when to use `local_paths` vs `data` but does not explicitly contrast with other browser tools like `browser_fill` or `browser_click`. 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?

The description claims the tool modifies the page by filling a field, but annotations set readOnlyHint=true, indicating no modifications. This is a contradiction. The description does not disclose any behavioral traits beyond the action itself.

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

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

The description is very short (one sentence) and gets to the point, but it sacrifices important details, making it adequate but not well-rounded.

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 3 required parameters and no output schema, the description is incomplete. It misses details about the 'page_id' parameter and the effect of filling (e.g., whether it triggers events).

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 that 'ref' is a CSS selector, adding value beyond the schema. However, it does not explain 'page_id' or 'value' beyond 'given value'. With 0% schema description coverage, the description should compensate more.

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 ('Fill') and the target resource ('input or textarea'), and distinguishes from sibling tools like browser_fill_form and browser_type by specifying a single element via CSS selector.

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 (filling a single input/textarea) but does not explicitly state when not to use or compare with alternatives like browser_type or browser_fill_form.

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 says 'Fill multiple form fields' which is a write operation, but the annotation readOnlyHint=true indicates the tool is read-only. This is a serious contradiction and fails to disclose the behavioral conflict. No additional behavioral details are provided beyond the contradictory annotations.

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

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

The description is two sentences long, front-loads the purpose, and includes essential parameter and benefit information without any 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?

The description covers input and benefit but does not mention expected return values or error handling. Without an output schema, this omission is notable, though the tool's simplicity partially mitigates it.

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

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

The description explains the structure of the `fields` parameter in detail, specifying that each item is a dict with `ref` (CSS selector) and `value` (string or boolean). This adds significant meaning beyond the schema, which has no descriptions and 0% 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 fills multiple form fields in one call, using a specific verb and resource. It distinguishes itself from the sibling browser_fill by highlighting the round-trip savings.

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

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

The description provides a clear usage context by comparing to browser.fill, but does not explicitly state when not to use it or list other alternatives.

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

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

The description adds behavioral context beyond annotations, such as dialog queuing and the return value when no dialog is waiting. However, it contradicts the readOnlyHint annotation, as responding to a dialog is a mutation. This contradiction reduces transparency. The description does not disclose potential side effects like page state changes after dismissing the dialog.

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

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

The description is three sentences, each serving a clear purpose: defining the tool, explaining core parameters, and adding behavioral notes. There is no redundancy or filler, making it highly efficient for the agent to parse.

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

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

Given the tool's simplicity (3 parameters, no output schema), the description covers the main behavior and return value. It mentions the queuing mechanism and the case of no waiting dialog. However, it could be improved by mentioning error states or prerequisites (e.g., ensuring a dialog is actually pending). Overall, it is near complete for this tool.

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

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

The schema has 0% description coverage, so the description must compensate. It explains two parameters (accept and prompt_text) well, providing clear usage. However, it fails to explain the required page_id parameter, which is crucial for specifying which page's dialog to handle. This omission significantly reduces parameter clarity.

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: responding to pending JS dialogs. It specifies the dialog types (alert/confirm/prompt), which distinguishes it from other browser tools like clicking or navigating. The verb 'respond' and resource 'pending JS dialog' are specific and unambiguous.

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

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

The description gives usage hints like 'Pass accept=true for OK or false for Cancel' and explains the prompt_text parameter, but it does not explicitly state when to use this tool versus alternatives (e.g., when a dialog appears). The mention that dialogs are queued at page-open time provides some context, but there is no guidance on when not to use it or how to detect a pending dialog.

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 and idempotentHint. The description adds that hovering reveals UI elements, which is behavioral context beyond the 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?

Two sentences, concise and front-loaded. Every word adds value 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?

The description covers the purpose and one parameter, but omits explanation of 'page_id'. For a simple tool, this is adequate but incomplete given the 0% schema coverage. No output schema, so return values are not addressed.

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

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

Schema description coverage is 0%, so the description must explain parameters. It explains 'ref' as a CSS selector but does not explain 'page_id' at all, leaving a gap in understanding the second required parameter.

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 'Hover' and resource 'element', and explains the effect: reveals tooltips and hover menus. This distinguishes it from sibling tools like browser_click or browser_fill.

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

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

The description implies when to use (to reveal tooltips/hover menus) but does not explicitly state when not to use or provide alternatives. It gives clear context but lacks exclusion criteria.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that navigation modifies the page history (URL changes), which is a behavioral trait not fully captured by annotations. However, it does not disclose edge cases like what happens if there is no history, so transparency is adequate but not exceptional.

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

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

The description is a single sentence, front-loading the action and return value. Every word is necessary, with no extraneous 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the primary action and return value. It does not mention prerequisites (e.g., a page must be open with history) or error states (e.g., no history to navigate). For a straightforward tool, this is mostly complete.

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

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

The input schema has one parameter (page_id) with 0% description coverage, meaning no textual documentation in the schema or description. The tool description does not elaborate on the parameter's purpose or valid values, leaving the agent to infer from the parameter name alone. This is insufficient for confident usage.

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 navigates back in page history, mimicking the browser back button, and specifies it returns the new URL and title. This is a specific verb+resource pairing that distinguishes it from sibling tools like browser_open or browser_click.

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 explicit guidance on when to use this tool versus alternatives (e.g., browser_open with a specific URL). However, the purpose is straightforward enough that usage context is implied, earning a baseline score.

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

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

Annotations already indicate a read-only, idempotent operation. The description adds behavioral details: capacity limit of 200 requests, data recency ('since open or last drain'), and optional filters. It does not explain the 'drain' mechanism but overall improves transparency beyond annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and includes necessary details without extraneous words. Every sentence adds value.

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

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

Given no output schema and moderate complexity (5 params), the description covers the tool's purpose, filters, and capacity. It lacks explanation of the 'clear' parameter and drain behavior, but overall provides a working understanding for a read-only 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?

With 0% schema description coverage, the description partially compensates by explaining filters 'method', 'url_pattern', and 'status_min' with examples. However, it omits the 'clear' parameter and does not fully describe all five parameters. The page_id is implied but not detailed.

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 HTTP requests made by a page, with specific verb 'List' and resource 'HTTP requests'. It distinguishes from sibling browser tools that perform actions like clicking or opening, and adds scope 'since open or last drain'.

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

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

The description implies usage for viewing network requests but does not explicitly state when to use this tool versus alternatives like browser_console_messages. No exclusions or comparisons are provided, leaving the agent to infer context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, non-destructive operation. The description adds behavioral context about attaching login cookies via identity_name, which is not covered by annotations. However, it does not describe other behaviors like whether the browser tab is focused or if a new window is opened.

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

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

The description is two concise sentences with no irrelevant details. Information is front-loaded: the primary action in the first sentence, optional feature in the second. Every word adds value.

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

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

Given no output schema and 3 parameters with 0% schema coverage, the description leaves workspace_id unexplained. Annotations partially compensate for safety, but the tool's return behavior (e.g., whether it returns a success status or tab info) is absent. For a simple open action, it is minimally adequate but could be more 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 0%, so the description should compensate. It mentions 'URL' and 'identity_name' but omits 'workspace_id', which is required. The description adds minimal meaning beyond field names; it does not specify URL format, workspace_id purpose, or identity_name constraints.

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 'Open a URL in a remote browser', specifying the exact action (open) and resource (URL in remote browser). It is distinct from sibling tools like browser_click or browser_fill, which involve interactions within the browser after navigation.

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 hints at a specific use case with 'optional identity_name attaches the workspace's saved login cookies first', but does not explicitly state when to use this tool versus other browser navigation tools like browser_navigate_back or browser_tabs. No exclusions or alternative tool references are provided.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it presses keys or single characters and optionally focuses an element. No contradiction; additional context is useful.

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

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

Two concise sentences, front-loaded with action and examples. Every word adds value.

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

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

Simple tool with no output schema. Description covers core behavior, examples, and optional ref. Annotations cover safety. Complete for its complexity.

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

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

Schema coverage is 0%. Description explains `key` with examples and `ref` as focusing an element, but `page_id` is not mentioned. Compensates partially, but missing explanation for required page_id.

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

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

Description clearly states the action (press a keyboard key), gives specific examples ('Enter', 'Tab', etc.), and mentions optional focusing. It distinguishes from siblings like browser_type (which types strings) and browser_click.

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?

Implicitly suggests using `ref` to focus an element before pressing, and examples show typical keys. Lacks explicit 'when to use vs alternatives', but context with sibling names helps.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, implying no persistent data modification. The description adds value by explaining the effect on viewport and its relevance to page rendering, but it does not disclose potential side effects like triggering resize events or affecting page state beyond viewport dimensions.

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

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

The description is two concise sentences with no wasted words. It front-loads the core action and immediately follows with practical use cases.

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

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

For a simple tool with three required parameters and no output schema, the description is adequate but incomplete. It lacks parameter details and does not describe the return value (or lack thereof). The use cases add context but do not fully compensate for missing parameter semantics.

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

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

Schema description coverage is 0%, so the description must compensate. It provides no information about the parameters (page_id, width, height) such as units, valid ranges, or defaults. The agent cannot infer input details from the description.

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

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

The description clearly states the tool's function: 'Resize the page viewport.' It also provides specific use cases (mobile vs desktop HTML, anti-bot detection) that distinguish it from other browser tools. The tool name reinforces the purpose.

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 (responsive design testing, anti-bot evasion) but does not explicitly mention when not to use it or list alternatives. However, the context is sufficient for an agent to infer appropriate usage.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that the tool targets native select dropdowns and supports multi-select via lists, giving 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?

Pithy two-sentence description with no wasted words. The action is front-loaded ('Pick option(s)') and critical usage details are provided efficiently.

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

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

No output schema is present, and the description does not mention return values, error handling, or prerequisites (e.g., element must be a select). While annotations cover safety, the description lacks complete contextual guidance for a tool with no 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 has 0% description coverage, so the description must add meaning. It explains that 'value' matches the option's value attribute and 'label' matches visible text, and that arrays are allowed for multi-select. However, it does not describe 'ref' or 'page_id', leaving some ambiguity.

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 picks options in a native <select> dropdown, distinguishing it from other browser interaction tools like browser_click or browser_fill. The description explicitly mentions using 'value' or 'label' to specify options.

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?

Explains when to use (for select dropdowns) and how to use (value vs label, lists for multi-select). Does not explicitly state when not to use or mention alternatives, but provides sufficient context for correct invocation.

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, idempotentHint=true, and destructiveHint=false. The description adds that the snapshot is truncated at 32KB, which is important behavioral context. No contradictions; the description complements 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, each serving a purpose: first defines the output, second gives usage guidance. No redundancy or filler. Very efficient.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the essential aspects: output format (YAML aria_snapshot), size limit (32KB), and purpose (finding element refs). It does not detail the snapshot structure, but the term 'aria_snapshot' is self-explanatory. Slightly more detail on return structure could improve completeness.

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

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

Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The description does not explain the 'page_id' parameter, assuming prior knowledge. This is a gap; the tool description should at least clarify that page_id identifies the browser page from which to take the snapshot.

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 a YAML aria_snapshot of the page DOM, truncated at 32KB, and explicitly mentions its use for finding element refs for browser.click and browser.fill. This provides a specific verb and resource, distinguishing it from sibling browser tools.

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

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

The description explicitly states when to use the tool: 'Use the snapshot to find element refs for browser.click / browser.fill.' This provides clear context for usage. However, it does not mention when not to use it or provide alternatives, which could improve clarity further.

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, non-destructive, idempotent behavior. The description adds context about BrowserContext association and return behavior for list and new actions, providing useful supplementary information.

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 action set. No wasted words, though slightly more structure (e.g., bullet points) could improve readability.

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 the core functionality and key actions but omits details on return values for switch/close and the role of optional parameters. Lacks an output schema, leaving some gaps for a 4-parameter tool.

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

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

With 0% schema description coverage, the description partially explains action and page_id but fails to clarify optional parameters like url (likely for new action) and tab_id (for switch/close). This leaves ambiguity for an AI agent.

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 manages tabs within a BrowserContext, listing specific actions (list, switch, close, new) and their outcomes, which distinguishes it from sibling browser tools like browser_open or browser_close.

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 (for tab management actions), anchored to a specific page_id. It doesn't explicitly exclude alternatives, but the action enumeration provides clear 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 indicate read-only and idempotent. Description adds output format (base64) and usage caution, which is helpful but does not detail potential side effects or permissions beyond what annotations imply.

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

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

Two succinct sentences: first captures action and output, second gives guidance. No redundant 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 no output schema, description explains return format. Covers purpose and usage guidelines well, but lacks parameter details and error/limitation information. Mostly complete for a simple 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 has 3 parameters with 0% description coverage. Description only indirectly hints at 'page or specific element' (page_id and ref), but does not explain full_page or ref's format/meaning. Insufficient compensation for missing schema descriptions.

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

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

Clearly states it captures a screenshot (PNG) of a page or specific element and returns base64-encoded image bytes. Distinguishes from sibling browser.snapshot by mentioning preference for structured DOM understanding.

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 sparingly and favor browser.snapshot for structured DOM understanding, providing clear usage context and alternative.

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 contradicts the annotation 'readOnlyHint: true' by indicating the tool modifies the element (types text, dispatches events). According to rubric, score 1 if contradiction exists.

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. Each sentence earns its place.

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