chain_spec_run

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

With no annotations, the description must fully disclose behavioral traits. It lists capabilities and summarization features (console, page errors, network, state diff, evidence) but omits critical details: whether a new browser session is created, side effects on browser state, resource cleanup, or destructive actions. The mention of 'simplified' and 'future extraction' does not clarify runtime 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?

The description is moderately concise, listing capabilities in a single sentence. However, it includes meta comments about implementation ('先做进现有MCP，后续再剥离') that are irrelevant to an agent's use. This adds noise without improving understanding.

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

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

Given the tool's complexity (17 parameters, nested objects, no output schema), the description is insufficient. It does not specify the output format (only mentions 'summary' vaguely), nor does it highlight the only required parameter ('steps'). Important behaviors like error handling, timeout defaults, and template usage are left to the schema alone.

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

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

Schema description coverage is 100%, so baseline is 3. The tool description adds little beyond the schema; it lists high-level actions (e.g., 'open page, click, input') that map to step types already documented in the schema. It does not explain parameter interactions or provide examples for complex nested objects like 'expectations' or 'stateSources'.

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 executes a simplified business chain validation with specific actions (open, click, input, wait, assert, state capture/compare) and summarizes results. It differentiates from sibling tools like 'browser_chain' by emphasizing 'spec' and a structured approach, though it doesn't explicitly distinguish from closely related tools like 'chain_spec' or 'browser_flow'.

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 'browser_chain' or 'browser_step'. It lacks prerequisites, use cases, or exclusions, leaving the agent to infer context from the name and schema alone.

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