Open a URL in the shared browser session, or specify a named profile to keep cookies separate.
Open a URL in the shared browser session. A named profile keeps its own cookies.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| profile | No |
Changes observed during successful MCP inspections.
v0.2.8Input schema / properties / profileAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Profile"
+}v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already capture open-world and idempotency traits. The description adds meaningful behavioral context by noting the shared browser session and that a named profile keeps its own cookies. It does not contradict the annotations, though it does not detail navigation side effects or page-load 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 two short sentences with no filler. The core action and session context are front-loaded, and the profile/cookie note earns its place as useful additional context.
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 two-parameter navigation tool with annotations covering safety and side-effect class, the description supplies the session and cookie context an agent needs. It omits return-value details, but no output schema exists and the action's result is reasonably self-evident, so this 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'profile' parameter by explaining cookie isolation, and 'Open a URL' implicitly defines the url parameter. However, it does not provide format, allowed values, or behavior for the required url 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 action ('Open') and the resource ('a URL') and adds that it operates in the shared browser session. This distinguishes it from the interaction-focused sibling tools like click, type, and scroll, though it does not name a sibling explicitly.
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 useful context: use this when you want to open a URL in the shared browser session. However, it does not explicitly contrast it with alternatives such as browser_search or browser_run, nor does it state when not to use it. The usage is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.