Loading ToolBench
Captures browser and server logs in one place and exposes them to AI tools via MCP.
Six read-only tools with clear, well-written descriptions (avg 180 chars, well within 10-1024 range). All tools have explicit input schemas with typed parameters and descriptions. Naming follows verb_noun pattern (recent_*, search, logs_*). However, output schemas are not documented in the visible code, only input schemas are defined. No error handling guidance, no recovery hints, and no tool annotations (readOnlyHint missing despite all being read-only). Parameter descriptions are good but could specify ranges/constraints more formally (e.g., limit 1-500 is mentioned in descriptions but not as JSON Schema constraints). Tools are well-composed and single-purpose.
Every log of one page load by pageLoadId, browser and server interleaved - the full correlated story, noise included. Use it after another tool gave you a pageLoadId, typically to find the server request behind a client-side error.
Only what arrived since your previous call to this tool (the first call returns the recent tail as a baseline). This is the tool to reach for after you changed code or asked the user to click something: it shows what the app did in response, without re-reading logs you have already seen. Framework noise excluded by default.
The fastest way to find out what broke: the most recent errors from browser and server, with stack traces. Start here whenever the user says something is broken, blank, failing or behaving oddly. Framework noise is excluded by default; set includeNoise to see everything.
Recent log entries, optionally filtered by level, source (browser or server) and start time. Use it for the context around an error, or to see what the app did during a specific window. Framework noise is excluded by default; set includeNoise to see everything.
Case-insensitive substring search across log messages. Use it when you know a marker to look for - a message, an id, a route, a component name. Framework noise is excluded by default; set includeNoise to see everything.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'log entries', 'status'), but the actual response structure (field names, types, pagination) is not visible in the code. LLMs cannot plan downstream operations or extract fields without knowing the response schema.
No tool annotations. All six tools are read-only (no side effects), but readOnlyHint is not set. This forces LLMs to reason about safety; explicit annotations would improve planning and reduce unnecessary caution.
No error handling guidance. Tools accept parameters like 'limit' (1-500) and 'level' (enum), but no error responses are documented. If an LLM passes limit=1000 or level='invalid', what happens? No recovery hints provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Which project's logs you are about to read, and whether its dev server is still running. Call this when you are unsure where the logs come from, when the user works across several projects, or when a query comes back empty and you want to know whether that means "no errors" or "no logs at all".
Parameter constraints not formalized in schema. Descriptions mention 'limit (1-500, optional)' and enums for 'level' and 'source', but JSON Schema minimum/maximum and enum constraints are not visible. LLMs rely on descriptions; formal constraints are safer.
logs_since_last_check naming is vague. 'logs_since_last_check' does not clearly indicate what 'check' means or that this tool maintains stateful cursor. Consider 'get_new_logs_since_last_call' or 'fetch_logs_incremental' for clarity.