Open a single URL to retrieve status, title, load time, and console errors for website bug verification.
Open a URL once and report status, title, load time and console errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| error | Yes | ||
| title | Yes | ||
| status | Yes | ||
| final_url | Yes | ||
| reachable | Yes | ||
| page_errors | Yes | ||
| load_time_ms | Yes | ||
| console_errors | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool opens a URL once and reports specific data, but it does not mention side effects, authentication needs, rate limits, or what happens on failure. This is minimal but adequate for a simple probe, though it lacks depth about edge cases.
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?
A single, well-structured sentence that front-loads the action and lists the key outputs. No fluff or redundancy; every word contributes to the meaning.
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 parameter) and the presence of an output schema, the description covers the essential purpose and reported data. It doesn't mention error handling or session independence, but for a one-off probe, these are minor gaps. The description is largely complete for an agent to use it 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%, so the description must compensate. The description clearly states 'Open a URL once,' defining the url parameter as the target URL. It adds meaning by indicating the action and the one-time nature, though it does not specify URL format or required protocols.
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 uses a specific verb ('Open'), a clear resource ('a URL'), and explicitly lists the reported outputs (status, title, load time, console errors). This clearly distinguishes it from sibling tools like session_open or session_inspect, which imply persistent sessions or element discovery.
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 a one-time probe scenario but does not explicitly state when to use this tool over siblings like session_open or server_info. No exclusions or alternative routing is provided, leaving the agent to infer the appropriate context from the one-time nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.