Diagnose the current state of a page, bridge, or downloads. Verify page load, modals, captchas, and viewport conditions after actions to identify issues.
Diagnostics: kind:"page" (URL/title/modal/captcha/loading/viewport — call after actions) | "bridge" (hub+page …
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Default page |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the diagnostic categories returned for 'page' and partially for 'bridge', but it is truncated, does not mention side effects, response format, or error behavior, and leaves the 'doctor' and 'downloads' kinds unexplained.
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 front-loads the key concept and is compact, but it is truncated mid-phrase and does not form a complete, self-contained explanation. It is concise but at the cost of completeness.
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?
Without an output schema or annotations, the description is the only source of behavioral and contextual information. The truncation leaves the 'bridge', 'doctor', and 'downloads' kinds unclear, and there is no guidance about return values or how this differs from sibling diagnostic 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?
Although schema coverage is 100%, the description adds meaning beyond the enum labels by explaining what 'page' and 'bridge' diagnostics include. This helps an agent select the right kind, even though the description is incomplete for the remaining enum values.
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 identifies this as a diagnostics tool for checking page state (URL, title, modal, captcha, loading, viewport) and bridge state. It is reasonably clear about what the tool reports, though it lacks a specific verb and does not explicitly distinguish itself from sibling diagnostic tools like inspect or network_log.
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 a clear usage cue: call after actions for page diagnostics. However, it does not provide exclusions or mention when to prefer alternative tools, and the guidance appears to apply mainly to the 'page' kind rather than all enum values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.