browser-automation

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

No annotations are provided, and the description gives zero behavioral information. It does not mention side effects, navigation behavior, or anything that happens when the tool runs.

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 text is extremely short, but this is under-specification rather than purposeful conciseness. There is no meaningful sentence or structure that helps an agent act.

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 four parameters and no output schema, the description is completely inadequate. It provides nothing about inputs, behavior, return values, or how it differs from sibling tools.

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 any of the four parameters (url, waitMs, actions, fullPage). The agent is left to guess their meanings and formats entirely.

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 'V1 Browse' simply restates the tool name with a version identifier. It contains no verb, no resource specification, and no explanation of what the tool does, so an agent cannot infer its 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?

There is no guidance on when to use this tool versus the siblings fetch, web_crawl, or captcha_solve. The description provides no context whatsoever about appropriate invocation 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 the full burden of behavioral disclosure, but 'V1 Interact' discloses nothing about side effects, requirements, mutations, or operational 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 extremely short, but this is under-specification rather than concise efficiency. There is no front-loaded, useful content to 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?

For a tool with three undocumented parameters, no output schema, and related sibling tools, this description is completely inadequate. It provides none of the information needed to invoke the tool correctly.

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

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

Schema description coverage is 0%, and the description adds no meaning to actions, extract, or sessionId. The agent is left with only bare type names and no understanding of what values mean.

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 'V1 Interact' merely restates the tool name and a version label; it does not state what the tool actually does, what resource it acts on, or how it relates to 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?

No guidance is given about when to use 'interact' versus sibling tools like browse or session_create. The agent receives no context for selecting this tool over 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It discloses nothing about side effects, session persistence, TTL enforcement, state changes, or lifecycle implications of creating a session.

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 words long, but this is under-specification rather than concise effectiveness. No sentence earns its place because no substantive information is conveyed at all.

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

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

For a tool with one meaningful parameter, no output schema, and no annotations, the description must explain what a session is, how TTL minutes behave, and how the result is used later. It does none of this, leaving the agent completely uninformed.

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 adds no meaning to the single parameter 'ttl_minutes'. The agent cannot learn what the TTL controls, the units (though implied by the name), what null default means, or how the value affects session behavior.

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 'V1 Session Create' is a tautology that merely restates the tool name with a version prefix. It does not state what a session is, what creating one accomplishes, or how it differs from the sibling 'screenshot' tool.

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

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

There is no guidance on when to use this tool versus alternatives. The sibling tool 'screenshot' exists, but no conditions, prerequisites, or routing context are provided to help an agent decide which to invoke.

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 exist, so the description must carry the full burden of behavioral disclosure. It only repeats the destructive action implied by the name and does not mention irreversibility, side effects, current-session versus specified-session scope, or error 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 only four words long, but this is under-specification rather than conciseness. There is no sentence structure or contextual detail that earns its place as a useful tool definition.

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 destructive action with one optional parameter and no output schema, the description should clarify the scope of deletion, the role of sessionId, and what happens when it is omitted. None of this is present, so the tool is not safely callable based on the description.

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

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

The schema has one optional sessionId parameter with a default of null and 0% description coverage. The description never mentions sessionId, so the agent cannot tell whether omitting it deletes the current session or whether a specific session must be supplied.

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 'V1 Session Delete' is essentially a versioned restatement of the tool name. It does not state in a sentence what the tool does, nor does it distinguish itself from session_create or session_list beyond the delete verb.

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 context is provided. There is no indication of when to call this tool, what prerequisites exist, or how it relates to sibling tools such as session_create and session_list.

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 of behavioral disclosure. It reveals nothing about whether this is a read or write operation, what a session is, pagination, 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 text is short but this is under-specification, not conciseness. The three words add no information beyond the tool's name and provide no structure or front-loaded 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?

Even for a single-parameter tool, the description is wholly inadequate. With no output schema, no annotations, and no parameter documentation, an agent cannot determine what to pass or what the tool returns.

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 required parameter 'extra' has 0% schema description coverage and the description adds zero meaning to it. An agent has no way to know what value to supply.

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 'V1 Session List' restates the tool name nearly verbatim. It names the resource (sessions) but provides no verb, no stated action, and no differentiator from the sibling session 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?

No guidance is given on when to use session_list versus its siblings (session_create, session_delete, browse, interact). Nothing distinguishes this tool's role beyond its title.

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