MCP (Model Context Protocol) server for browser tools integration, providing access to browser logs, network data, screenshots, and Lighthouse audits
Critical gaps across all dimensions. Descriptions are extremely brief (10-30 chars), below the 20-char floor for any credit. No parameter documentation exists. No output schemas documented. No error handling guidance. Tools lack verb-noun naming clarity (e.g., 'getConsoleLogs' vs 'get_console_logs'). No tool distinguishes between similar operations (e.g., getNetworkLogs vs getNetworkErrors). The server is barely functional as a tool definition.
Check our browsers console errors
Check our browser logs
Check our network ERROR logs
Check ALL our network logs
Get the selected element from the browser
Run an accessibility audit on the current page
Run a best practices audit on the current page
All 12 tools have empty input schemas ({}). This violates pattern:constrained-input and pattern:tool-description.
Descriptions are 10 - 30 characters (e.g., 'Check our browser logs'). Baseline is 194 chars. Descriptions lack WHAT, WHEN, and WHY context for LLM selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 26 | 2026-07-28+ | v2 |
Run a PWA audit on the current page
Run a performance audit on the current page
Run an SEO audit on the current page
Take a screenshot of the current browser tab
Wipe all browser logs from memory
Audit tools (runAccessibilityAudit, etc.) have a 'category' parameter with minimal description ('Audit category (accessibility)'). No enum constraint, no format guidance, no explanation of what values are valid or what the parameter controls.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract data without knowing what fields to expect. Violates pattern:tool and pattern:response-shaper.
No error handling guidance. Tools do not indicate what errors are retryable, user-fixable, or fatal. No recovery hints. Violates pattern:recovery-guide and pattern:error-classification.