AIHawk

Official

Overview Schema Source Related Servers Discussions Admin

browser_open

Destructive

Open or reopen a browser with a chosen identity, proxy, or persistent profile to manage sessions, preserve logins, or route traffic through a different network exit.

Instructions

Open main or support, or reopen one as somebody else.

support is yours to manage: open it when the task needs a second identity, and close it with browser_close as soon as the task no longer needs it, before you answer. It is not saved.

Called on a browser that is already up, this REOPENS it with the settings given, and what it held is gone.

seed the identity; same seed, same fingerprint. Left out, one is drawn. profile a directory keeping cookies, logins and the seed between opens; "" means none. It keeps the SEED too, so a login does not come back on different hardware every visit. proxy the exit, http://user:pass@host:port or socks5://host:port; "" means this machine's own address; left out for support, it shares the exit main has. A profile does NOT pin its exit, and a login arriving from a new country is as visible as one arriving on new hardware.

Input Schema

TableJSON Schema

Name	Required	Description
`seed`	No
`proxy`	No
`browser`	No	Defaults to `main`; `support` is the helper beside it.
`profile`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.68.0Sep 15, 2026
- addedInput schema / properties / browser / description
```
Added value: +"Defaults to `main`; `support` is the helper beside it."
```
First observedv0.43.0Sep 12, 2026

TDQS

A5/5.0

Behavior5/5

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

The description goes beyond the `destructiveHint: true` annotation by specifying exactly what is lost on reopen: the previous browser state is gone. It also discloses that `support` is ephemeral and that a profile does not pin its exit, making cross-device login behavior visible. 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.

Conciseness5/5

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

The prose is dense but purposeful: each sentence introduces a distinct behavioral fact, and the parameters are formatted as a scannable list. It front-loads the core action and lifecycle rule before diving into parameter details, with no filler.

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

Completeness5/5

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

For a stateful, destructive browser tool with four optional parameters, the description covers selection, lifecycle, identity persistence, proxy behavior, and side effects. The presence of an output schema means the return format does not need to be explained here.

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

Parameters5/5

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

Schema description coverage is only 25%, so the description carries the burden for `seed`, `profile`, and `proxy`. It explains each parameter's meaning, the default behavior when omitted, the empty-string semantics, and the interplay between profile and proxy. This far exceeds the bare schema.

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

Purpose5/5

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

The opening sentence specifies the exact resources (`main` or `support`) and the two core actions: open, or reopen as a different identity. This distinguishes it clearly from siblings like `browser_close`, `browser_navigate`, and `browser_status` without needing to inspect them.

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

Usage Guidelines5/5

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

The description explicitly says when to open `support` ('when the task needs a second identity'), instructs to close it with `browser_close` before answering, and states that `support` is not saved. This gives the agent a clear lifecycle policy and prevents resource leaks.

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

Deploy Server