Loading ToolBench
Chrome extension and HTTP/MCP server for capturing console logs and network requests from web pages and backend processes
Local Lens provides 4 tools with basic descriptions and schemas. However, critical gaps limit effectiveness: (1) Descriptions are extremely short (10-60 chars), well below the 194-char baseline for production tools. (2) Parameter descriptions are generic or missing entirely, 'Session ID to filter logs by' lacks context on format/length. (3) No output schemas documented, LLMs cannot infer what fields to expect from get_logs or get_network_requests responses. (4) Write operations (clear_logs, clear_network_requests) lack confirmation patterns or dry-run support, violating the irreversible operation pattern. (5) Input schemas present but minimal, properties lack examples, patterns, or validation ranges. No tool demonstrates the LLM-optimized descriptions (50-200 chars) expected in A/B grade tools.
Delete all stored console logs from the local database. This action is irreversible and will permanently remove all captured console log entries from all web pages.
Retrieve console logs captured from web pages with optional filtering capabilities. Returns logs with timestamp, level, message, page URL, and optional stack trace information.
Retrieve HTTP/HTTPS network requests captured from web pages with optional filtering capabilities. Returns essential debugging information including method, URL, status code, timing, and truncated request/response bodies.
Search console logs using text-based queries to find specific log messages or stack traces. Performs case-insensitive partial matching across log messages and stack trace content.
Tool descriptions are 10-60 characters, well below the 194-char baseline. Descriptions like 'Retrieve captured logs from the Local Lens server' (55 chars) lack WHEN to use, WHY, or prerequisite context. LLMs cannot reliably select tools based on truncated descriptions.
No output schemas documented. get_logs and get_network_requests lack explicit schemas describing returned fields (e.g., log entries structure, network request object shape, pagination info). LLMs cannot plan downstream operations or extract required data reliably.
Parameter descriptions are generic or trivial. 'Session ID to filter logs by' (31 chars) does not specify: format (UUID? string?), length, whether null means all sessions, or how to obtain a session ID. Forces LLM to guess or make API calls blindly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
clear_logs and clear_network_requests lack confirmation or dry-run patterns. These are irreversible WRITE operations that wipe all data. No warn-before-execute mechanism, no rollback option, no per-item success/failure reporting. Agents risk catastrophic data loss.
Input schemas present but incomplete. 'limit' and 'offset' parameters lack min/max bounds. No validation on sessionId format. No enum constraints. No required/optional field declarations. LLMs may pass invalid values (negative limit, huge offset) causing API errors.
No error handling guidance. No documentation on what errors get_logs/get_network_requests return, when to retry vs ask the user, or how to recover if sessionId is invalid. LLMs cannot self-correct on failures.