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

With no annotations supplied, the description carries the full burden and does so well. It discloses token cost, the ok/data/error envelope, never-throw dispatch behavior, validation of unknown tools/missing args, concurrency rejection, and the minimum browser version.

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 dense but well-organized: purpose, cost tradeoff, prerequisites, return envelope, and concurrency warning each earn their place. The warning is clearly marked and front-loaded enough to prevent misuse.

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

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

Despite having no output schema, the description covers invocation semantics, error model, concurrency constraints, version requirements, and discovery flow. This is complete for a generic direct-dispatch tool with three parameters.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by telling the agent to populate args per agent_tools params and clarifying that workspaceRoot affects fs_*/run_node/trace persistence, which reinforces the schema rather than merely repeating 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 states a specific action: directly run one browser engine tool, bypassing the DeepSeek worker. It clearly distinguishes this from delegation-based sibling tools like agent_start and agent_send, so an agent can select it correctly.

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

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

The description explicitly tells the agent to look up names/params via agent_tools first, to prefer agent_start/agent_send for cost-saving flows, and to stop any running agent session before direct calls. This is strong 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?

No annotations are provided, so the description carries full burden. It explains automatic behavior (settled + readOnSettled), default values, and the benefit of avoiding long waits. However, it lacks details on error states, side effects (if any), and safety of repeated calls.

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, front-loaded with the English title, and the full text in Chinese is informative with no superfluous sentences. Every sentence adds value, making it 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?

Without an output schema, the description partially covers return value (brief conclusion if settled) but does not specify exact format or structure. Given tool complexity (6 params, 1 required), it is mostly complete but lacks explicit return specification.

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 83% (high), baseline 3. The description adds context beyond schema: explains tid requirement, default timeoutSec=60 and intervalSec=5, and the effect of readOnSettled and stepTail/contentChars on response. This enhances 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 it is a 'short-poll' for a worker turn, specifically for CLI clients, and distinguishes itself from the long wait of agent_wait_for_stop (5400s). The verb 'short-poll' and resource 'worker turn' are specific, and the purpose is 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 recommends calling it in a loop after agent_start, contrasts with agent_wait_for_stop, and suggests timeout ranges (30-120s). It provides usage context for CLI clients but could be more explicit about 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?

No annotations provided, so description carries full burden. Discloses read-only nature, repeatable calls, and internal content. Highlights critical failure mode (confusing drift with conclusion). Does not cover permissions or all failure modes, but 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?

Front-loaded with purpose, then details. Slightly long but every sentence adds value. Could be more concise but still effective.

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

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

No output schema, but description explains return contents (content tail, step tail, progress files, driftHint, runlog). Covers read-only and repeatable use. Lacks explicit return format but complete enough for tool usage.

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

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

Schema coverage is 75% (3 of 4 params described). Description adds context for stepTail (max steps) and contentChars (text limit), but does not introduce new semantics beyond schema. driftHint/runlog advice is behavioral, not parameter-specific.

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

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

Description clearly states it reads the worker's stage conclusion, listing included elements (content tail, step tail, progress.md/ledger.md, driftHint, runlogTail). Distinguishes from sibling tools like agent_send (sends messages) and agent_runlog (reads runlogs).

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

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

Explicitly says when to use (read conclusion for director judgment) and warns about misinterpreting driftHint/runlog. States it is read-only and callable repeatedly, implying no side effects. Lacks explicit alternatives but context suffices.

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 transparently reveals it is an alias for agent_read with specific arguments (includeProgressFile:false, stepTail:5, contentChars:2000). It explains the behavioral trait of avoiding large outputs to prevent CLI blockage, providing sufficient context for an agent without 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 short sentences convey the tool's nature and use case with zero wasted words. Information is front-loaded and efficient.

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

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

Given the simple read operation with no output schema, the description adequately covers the tool's purpose. It could explicitly state the return value (the conclusion text), but the title and equivalence to agent_read imply it. Overall, it is sufficiently complete for an agent.

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

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

Two of three parameters have schema descriptions. The description adds the equivalent call parameters (includeProgressFile:false) but doesn't elaborate beyond defaults. Schema coverage is moderate, and the description provides some context but not extensive value beyond the schema.

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

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

The description clearly states it reads a compact worker conclusion via a specific parameterization of agent_read. It distinguishes itself from agent_read by being CLI-friendly and avoiding large outputs, making its 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 specifies usage after 'settled' and for quickly giving the main model a conclusion, avoiding progress.md/ledger.md or large steps. While not explicitly listing when not to use it, the context implies it's for lightweight reads, with agent_read as the 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?

No annotations provided; the description carries full burden. It describes the log contents but does not explicitly state that the tool is read-only or has no side effects. The behavior is implied as safe, but lack of explicit safety declarations is a gap.

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 with a bullet-like list, but it is somewhat lengthy and complex. It could be more structured for easier parsing by an AI agent, though no extraneous information is present.

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

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

For a tool with no output schema, the description lists the log contents (timing, retries, etc.) which provides basic completeness. However, it lacks details about output format, pagination, or how to interpret results, which are important for a diagnostic 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% (one optional parameter 'tid'). The description does not add meaning beyond the schema's description. 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 it provides engine-level run logs for diagnostic purposes, listing specific content types (timing, retries, timeouts, etc.). It subtly distinguishes itself from sibling agent action tools by its diagnostic nature, but does not explicitly compare.

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

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

Explicitly states when to use: before drawing conclusions about tool execution failures, to differentiate between worker decision and model-side issues. Implicitly avoids usage for non-diagnostic tasks, but does not list alternatives or 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?

The description discloses the full internal process: the server appends the worker's previous conclusion as an assistant turn, appends the guidance as a new user turn, persists, and reruns with the current mode. It also notes the rejection behavior when a round is active. This is highly transparent, especially given no 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 somewhat lengthy and mixed in language, but it is front-loaded with the core purpose and logically structured: purpose, behavior, usage guidance. Every sentence adds value, though some redundancy could be trimmed.

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 4 parameters, no output schema, and no annotations, the description covers behavioral details, rejection conditions, and usage tips comprehensively. Missing formal descriptions for 'tid' and 'maxRounds' are minor gaps, but the overall context is 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?

The description adds significant semantic value to the 'guidance' parameter with practical writing tips ('具体、有序、只做第1+2+3步' etc.), going beyond the schema description. For 'tid' and 'maxRounds', the schema provides coverage but the description lacks explicit details, though the context implies 'tid' is a thread 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?

The description clearly states the tool's purpose: '把方向纠正作为下一条 user 消息发出去并起下一轮', which translates to sending a direction correction as the next user message. It explicitly labels itself as the director's core move and distinguishes from sibling tools like agent_read or agent_stop.

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

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

The description provides usage context: it mentions that if a round is still running, the tool will reject and advises to 'wait or stop' first. It also gives detailed guidance on how to write the 'guidance' parameter, including concrete examples. However, it does not explicitly compare with alternatives 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?

Without annotations, the description carries the behavioral burden. It explains that 'assist' pauses for director review at each phase gate and 'auto' runs to completion without stopping. It mentions a prerequisite ('route locked') for using 'auto'. However, it does not describe side effects, permission requirements, or what happens to existing state, which is a minor gap.

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-loaded with the action ('Switch conversation mode'), and efficiently defines both mode options and use cases. No wasted words.

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

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

For a state-changing tool with two parameters and no output schema or annotations, the description covers the core functionality and use cases. However, it lacks explanation of the 'tid' parameter, return behavior, and potential errors, leaving some gaps for an agent to infer.

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 description must explain parameters. It explains the 'mode' parameter well (meanings of assist and auto). However, it does not mention the 'tid' parameter (task ID) at all. The description adds value for half the parameters but leaves the other half undocumented.

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: switching conversation mode between 'assist' and 'auto'. It uses a specific verb-resource combination ('切会话模式' meaning switch mode) and distinguishes from sibling tools by focusing on mode control, not reading or running logs.

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 concrete usage guidance: switch to 'auto' after route is locked for unattended completion, and switch back to 'assist' if stuck. It explains default behavior ('assist' for cost). However, it does not explicitly mention when not to use or contrast with alternatives like agent_start or agent_stop.

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

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

With no annotations, the description fully carries the burden. It details configuration steps (worker model, confirm gate, navigation, directory creation), return value (tid), key handling (only check hasKey), and mode behavior (assist vs auto). Slightly lacks explicit blocking/non-blocking behavior, but overall transparent.

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

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

The description is lengthy but well-structured: starts with core purpose, then workflow, then warnings, then recommendations. Every sentence is informative; minimal redundancy. Could be slightly more concise, but highly effective.

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

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

Given 8 parameters, no output schema, and no annotations, the description covers all major aspects: purpose, workflow, behavioral details, parameter semantics, and caveats. It provides sufficient context for correct tool invocation without needing external references.

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% (all 8 parameters described in schema). Description adds value beyond schema: clarifies 'assist' default and its meaning, gives model examples, explains 'targetUrl' effect, and describes default for 'workspaceRoot'. Exceeds baseline 3.

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

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

The description clearly states it starts a new reverse session ('开一个新的逆向会话'), identifies the specific resource (session) and action (start), and is distinct from sibling tools like agent_poll (observation) and agent_read (reading conclusions).

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

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

Explicitly recommends a workflow: after agent_start, use agent_poll/agent_wait_for_stop, then agent_read_brief/agent_read. Also advises against reading/writing worker keys and suggests model selection (standard/fast not reasoning). 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?

With no annotations, the description fully handles behavioral disclosure. It explains the fields, the lightweight nature, and the critical nuance that nSteps may not move for tens of seconds during a healthy turn. It lacks explicit mention of side effects (none expected) or idempotency, but covers enough for a read-only snapshot tool.

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

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

The description is a single paragraph that starts with the purpose and key fields, then gives usage guidance. It is dense but efficient. The mixed language slightly impacts readability, but the information-to-word ratio is good. No redundancy, 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 tool with one parameter and no output schema, the description adequately explains the return fields and usage context. It provides a warning about misinterpretation of nSteps. It does not explicitly list return types or formats, but the field names give sufficient semantic hints. The tool's simplicity limits the need for more 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 one parameter 'tid' (type string, required) with 0% description coverage. The description does not explain what 'tid' represents or how to obtain it. The agent must infer from context or other tools, which is insufficient. The description fails to add any meaning beyond the schema's raw type definition.

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

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

The description states it's a 'cheap liveness snapshot' lighter than agent_read, lists the fields returned (running/settled/nSteps/checkpointSeq/error/contentTail/driftHint), and implies it provides a quick status of the agent. The purpose is clear despite language mixing Chinese and English. However, the mixed language could cause confusion for an AI agent expecting pure English, slightly diminishing clarity.

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

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

Explicitly says 'use in wait loops or before sending guidance to confirm previous turn stopped' and warns against using nSteps as a stuck indicator, stating the only reliable signal is 'settled'. This provides clear when-to-use, when-not-to-use, and behavioral expectations, differentiating it from alternative tools like agent_read.

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?

Without annotations, description discloses that stopping does not lose persistent state, which is key for safety. However, lacks details on side effects, permissions, or error handling.

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 in Chinese, front-loading the action and then the use case. No unnecessary words; efficient and to the point.

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

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

Given the tool's simplicity (1 param, no output schema, no annotations), the description covers purpose and usage adequately but misses parameter explanation. Could be slightly 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?

The only parameter 'tid' is not explained in the description. With 0% schema description coverage, the tool definition fails to clarify what tid represents, leaving the agent guessing.

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 aborts the current worker round (agentSession.stop). It distinguishes from siblings like agent_wait_for_stop by specifying immediate intervention use case.

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 describes when to use: when snapshot shows worker heading wrong, need immediate stop to correct via agent_send. Assures persistent state is not lost, but does not mention alternatives 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?

With no annotations, the description carries the full burden and does so well: it discloses that the tool is read-only and has no side effects, and explains its default operational behavior (cost-splitting via delegating work to a worker). This goes beyond the bare 'list tools' semantics.

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

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

The description is compact but information-dense: purpose is front-loaded, followed by concrete scope and examples, then usage decision guidance. Every sentence earns its place without padding.

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

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

For a zero-parameter listing tool with no output schema, the description fully covers what the agent needs: what will be listed, what categories are included, the default execution path, the alternative direct-call route, and the read-only safety profile. Nothing critical is missing.

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

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

The tool has zero parameters and the schema is complete, so the baseline is 4. The description adds no parameter-specific meaning because none is needed; it appropriately focuses on the output contents instead.

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

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

The description states a specific verb and resource: '列出浏览器侧实际可用的工具清单' with explicit output fields (name/description/confirmation/parameters). It also distinguishes itself from agent_call_tool by framing the tool as the listing step before direct invocation, so an agent can tell it apart from its siblings.

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

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

It explicitly says '先看这个再决定委派还是直调' — use this tool first to decide between delegation and direct invocation. It also names the alternative agent_call_tool and explains the default delegation path, giving clear when-to-use and how-to-route guidance.

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

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

No annotations provided, but description covers blocking behavior, timeout handling, auto-backoff, return phase:'running' on timeout (not failure), and typical turn length. Could mention side effects or idempotency, but core behavior is well explained.

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 dense paragraph with informal symbols (★, ;). It contains all necessary info but could be more structured and concise. Some details (e.g., '真实turn常20-30分钟') are useful but add length.

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, so description should detail return values. It only mentions timeout returns phase:'running', but not what a successful wait returns (presumably a settled phase). Also no error handling or status codes. Incomplete for a blocking tool.

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

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

Schema coverage is 67% (timeoutSec and intervalSec have descriptions). The tool description adds context on defaults and auto-backoff but does not clarify the 'tid' parameter, which lacks schema description. Parameter-related info is present but incomplete for required param.

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: blocking poll until the worker is 'settled' (stage gate), and positions it as the signal that the cheap model is done. It distinguishes from sibling tools like agent_stop.

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 guidance: it's the signal to read, default timeout 5400s, and what to do on timeout (check agent_read, decide to wait or stop+correct). States settled is the only stage-end signal, not nSteps.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It merely states the action 'close' without explaining what the operation entails (e.g., abrupt termination vs graceful shutdown, reversibility, side effects on other environments).

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, short sentence that conveys the core purpose without verbosity. However, it could be expanded slightly to add necessary context without losing conciseness.

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 simplicity of the tool (one parameter, no output schema), the description is incomplete. It does not explain what the 'id' parameter refers to, what a successful close looks like, or any error conditions. Essential operational context is missing.

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

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

The schema defines one required parameter 'id' with no description. The tool description does not clarify what 'id' represents (e.g., environment ID, process ID), leaving the AI agent to infer its meaning. With 0% schema description coverage, the description fails to compensate for this 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 'Close the specified environment process' clearly states the verb (close) and resource (environment process). However, it does not explicitly differentiate from sibling tools like frx_env_delete, leaving ambiguity about whether 'close' terminates the process or deletes the environment entirely.

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

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

The description provides no guidance on when to use this tool versus alternatives such as frx_env_delete or frx_env_stop. There are no conditions, prerequisites, or exclusions mentioned, leaving the AI agent without context for appropriate 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?

No annotations are provided, so the description carries the full burden. It mentions that the kernel version and system follow 'Firefox Reverse' and that the default locale is mainland China Simplified Chinese, which offers some behavioral context. However, it does not disclose side effects, resource allocation, required permissions, or what return value to expect, which is a significant gap for a creation tool.

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

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

The description is a single, front-loaded sentence with no unnecessary fluff. It efficiently conveys the core action and a couple of key defaults, though it could be slightly more informative without sacrificing conciseness.

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 optional parameters, no output schema, and no annotations, the description is too sparse to be complete. It does not explain what 'Firefox Reverse' refers to, what happens after creation (e.g., whether it opens automatically or returns an ID), or how parameters interact. This is a substantial gap for a tool with this 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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter context by indicating a default locale, which the schema does not state, but it does not elaborate on any other parameters. No additional syntax or meaning is provided beyond what the schema already gives.

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 '一键新建 Firefox 环境' (one-click create Firefox environment), clearly identifying the action (create) and the resource (Firefox environment). It also distinguishes itself from sibling tools like frx_env_rename and frx_env_delete 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 implies it is for creating a new Firefox environment with defaults, but it does not explicitly state when to use this tool versus alternatives like frx_env_import_json or frx_env_import_capture. No exclusions, prerequisites, or comparison to other creation methods 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?

No annotations provided; the description mentions it returns environment or null but lacks details on side effects, authentication needs, or potential errors.

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

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

Single sentence, front-loaded with key information, no redundant 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 tool with one optional parameter and no output schema, the description adequately explains the core functionality, though it could detail the return structure.

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

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

Schema covers 100% of parameters with descriptions; the tool description adds no extra meaning to the 'refresh' parameter beyond what's already in 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 returns the environment of the connected Firefox Reverse process, distinguishing it from sibling tools like frx_env_list and frx_env_create.

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

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

The description implies usage when needing the current environment but does not provide explicit guidance on when to use or avoid this tool, nor 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?

With no annotations provided, the description carries the full burden. It discloses the destructive nature (delete) and the safety requirement (must pass confirm:true). It does not detail what happens if the environment is not closed or the result of the operation, but the confirm flag provides notable 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 extremely concise, with two short sentences that are front-loaded with the core purpose. Every word earns its place.

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

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

For a simple deletion tool with two parameters and no output schema, the description is mostly adequate. It states the resource (closed environment) and the mandatory flag. However, it lacks information about return values, error conditions, or whether the operation is reversible, which could be useful.

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 only explains the confirm parameter (must be true), but provides no semantic meaning for the id parameter. The value added is minimal beyond what the schema already provides.

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

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

The description clearly states the verb 'delete' and the specific resource 'closed environment', distinguishing it from sibling tools like frx_env_close which likely closes an environment.

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 requires passing confirm:true to proceed, which is a critical usage guideline. However, it does not mention when to use this tool vs alternatives like frx_env_close or frx_env_create.

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

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

No annotations. Description does not disclose behavior such as whether existing data is overwritten, validation performed, error handling, or environment must be open. Very limited 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?

Single sentence is concise but too brief, lacking necessary context. Could be improved with more structure.

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 2 parameters, no output schema, and no annotations, description is insufficient. Does not explain id, JSON format, or environment state requirements.

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

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

Schema description coverage is 50% (only 'text' has description). Description adds no meaning beyond schema; 'id' parameter is left unexplained.

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 'Import pasted fingerprint capture JSON' and description specify verb (import), resource (JSON text), and source (external browser console). Distinguishes from sibling frx_env_import_json which likely imports from other sources.

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

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

No guidance on when to use this tool vs alternatives like frx_env_import_json. No prerequisites, exclusions, or context 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?

No annotations are present, so the description carries the full burden. It discloses key behavioral traits: only Firefox fingerprints are accepted for new environments, two supported JSON formats are listed, and overwrite:true is required when the ID already exists. It does not mention error behavior or side effects beyond overwrite, but it provides meaningful constraints beyond the schema.

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

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

The description is two short sentences, front-loaded with the core action and resource. It efficiently packs format variants and the overwrite rule without redundancy or irrelevant 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 5 optional parameters and no output schema, the description covers the primary input formats and the overwrite constraint. It lacks explicit success/error behavior and does not distinguish between text and config parameters, but the schema descriptions and title cover most of that ground, making this 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?

Schema coverage is 100% for the 5 parameters, so baseline is 3. The description adds value beyond the schema by specifying accepted JSON structures ({name,id,fingerprint,proxy,generateOptions} or {env,fingerprint,proxy}) and explaining when the overwrite parameter is necessary, enhancing the minimal field 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 a specific action: '导入完整环境 JSON' (import full environment JSON), identifying the resource and scope. It distinguishes from the sibling frx_env_import_capture by focusing on full JSON import rather than capture-based import, and from frx_env_create by the import semantics.

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

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

The description provides usage context: importing a full environment, with explicit constraints that new environments only accept Firefox fingerprints and that existing IDs require overwrite:true. It does not explicitly name alternative tools (e.g., frx_env_create, frx_env_import_capture) or state when not to use this tool, but the context signals are clear enough for selection.

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

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

No annotations are provided, so the description must disclose all behavioral traits. It only implies that listing may involve refreshing status (via the 'refresh' parameter) but does not mention side effects, permissions, or limitations.

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 efficient sentence with no wasted words. However, it is overly brief and could benefit from more information without becoming 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 no output schema and low complexity, the description should detail what the listing returns (e.g., environment names, statuses). It only states the tool's purpose without explaining the output or full 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?

Schema description coverage is 100% (single param 'refresh' with description). The tool description adds no extra meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states the verb 'list' and the resource 'firefox-reverse environments', matching the title. It is unambiguous but does not differentiate from sibling tools like frx_env_open or frx_env_current.

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

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

The description mentions a specific use case ('for MCP side environment management button') but provides no general guidance on when to use this tool vs alternatives. No exclusions or context are given.

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

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

With no annotations, the description should disclose behavioral details. It mentions 'independent profile and independent Firefox process' but does not explain side effects of opening an already-opened environment, required permissions, or what 'open' entails (e.g., launching Firefox).

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 but conveys the core purpose. However, it sacrifices necessary detail for brevity. It is not front-loaded with key information beyond the verb.

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 likely involves launching a browser environment, the description lacks completion details like return value, error conditions, prerequisite states, or whether the tool is synchronous or asynchronous.

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% and the description does not explain the 'id' parameter. The agent has no context on what the ID represents (e.g., environment name, path, or numeric identifier).

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 opens a specific environment with independent profile and Firefox process, but does not differentiate from sibling tools like frx_env_create or frx_env_current.

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

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

No guidance on when to use this tool versus alternatives like frx_env_create or frx_env_close. Does not specify prerequisites or conditions.

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

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

With no annotations, the description carries full behavioral disclosure burden. It only states 'rename' but fails to mention if the operation is idempotent, if the environment must exist, or if it affects other resources. Minimal transparency 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 extremely concise (one sentence), which is positive for readability, but it sacrifices necessary detail and structure. It fits the minimal viable format but is too terse to be fully effective.

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

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

Given the simple input schema and no output schema, the description should at least clarify parameter roles and expected behavior. It fails to do so, leaving gaps that reduce completeness for an agent.

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

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

Schema description coverage is 0%, and the description does not explain what the 'id' and 'name' parameters represent. Without any parameter details, an agent cannot reliably use this tool without additional knowledge.

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 indicates the tool renames an existing environment, which is a specific verb+resource. It distinguishes itself from sibling tools like frx_env_create, frx_env_delete, etc. However, it is very brief and lacks additional context about the environment type or scope.

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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like frx_env_create or frx_env_delete, nor does it mention 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?

With no annotations, the description must cover behavioral traits. It lists what is scanned and clarifies the scope (no encryption analysis), but it does not explicitly confirm the operation is non-destructive or describe rate limits, authentication needs, or side effects.

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

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

The description is concise, consisting of two sentences that front-load the action and key details. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity (one optional parameter, no nested objects, no output schema), the description covers the main purpose and usage context. However, it does not describe the return format of the scan results, which is a minor gap.

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

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

The single optional parameter 'saveTo' is fully described in the input schema (100% coverage). The tool description adds no additional meaning or usage guidance beyond the schema, meeting the baseline.

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

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

The description clearly states the tool scans for common automation/environment exposure points in the current webpage, listing specific elements like navigator.webdriver, plugins, WebGL, etc. It distinguishes itself from sibling tools (agent_*, frx_env_*) by focusing on browser automation detection.

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

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

The description provides clear context: it is used to compare manual vs. MCP opening and explicitly states it does not perform single-site encryption analysis. However, it does not mention alternative tools 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?

在无任何注释的情况下，描述明确声明'只读、无副作用'，直接披露了关键行为特性。同时说明返回的note用于引导用户，提供了结果处理方式。这完全承担了行为披露的责任，没有矛盾。

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?

描述虽然较长但信息密度高，每条检查项都是必要的。结构上先给出使用前提，再列举检查点，最后给出条件处理，逻辑清晰，没有冗余内容。

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?

对于零参数且无输出schema的工具，描述覆盖了使用场景、检查内容、结果处理方式（note引导）以及后续动作（agent_start），足够让代理正确调用。虽未详细描述返回格式，但已提及note的存在，在无输出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覆盖100%为空，符合基线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?

描述明确指明了工具的功能：在启动前进行环境自检，列出所有检查项（MCP注册、浏览器启动、marionette连接、worker配置），并说明用途是确保环境就绪后再启动agent。这与兄弟工具如agent_start形成明确区分，因为它是前置检查步骤。标题和描述都强化了这一目的。

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?

描述明确说明使用时机：'开跑前先调这个自检'，并给出条件性指引：未就绪时按返回的note引导用户，就绪后调用agent_start。虽然没有明确列出替代工具或何时不使用，但通过关联agent_start提供了清晰的上下文。

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