Loading ToolBench

Reading the current corpus…

VibeLens MCP server · C · ToolBench

VibeLens

An MCP server that gives AI coding assistants eyes on localhost: screenshots, console errors, and a token-optimized DOM snapshot.

2026-07-28+STDIO1 tools

65/100

Definition Quality88

Protocol Readiness50

Supportability38

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

VibeLens defines a single, well-scoped tool with a clear action verb (inspect_localhost_ui). The description is comprehensive (280+ chars) and explains WHAT, WHEN, and WHY. Input schema is fully typed with Zod, includes enums for viewport, bounds for delay (0-30000ms), and all parameters have descriptions. Output is structured JSON with summary metadata, console logs, page errors, failed requests, and simplified DOM. Error handling distinguishes CaptureError (with code and hint) from unexpected errors. Tool annotations correctly declare readOnlyHint=true. Main gaps: no pagination/limits documented for DOM output (could be very large), no explicit output schema documentation in code comments, and error messages could be more actionable for LLM recovery.

Tools (1)

inspect_localhost_uiread onlysource verified88/100

Gives you eyes on a locally running web app. Opens the URL in a headless Chromium browser and returns (1) a screenshot of the rendered page, (2) any console errors/warnings and failed network requests, and (3) a token-optimized DOM snapshot that preserves ids and CSS/Tailwind classes. Use it to verify or debug UI work instead of guessing: layout and alignment bugs, overflow, spacing, responsive breakpoints, hydration errors and missing assets. Read the classes in the DOM snapshot before proposing a fix so you edit real selectors. Only local addresses (localhost / private network) are permitted.

Issues (3)

MEDIUMtool-output-schema ↗

Output schema not formally documented. buildTextPayload() returns JSON with summary, consoleLogs, pageErrors, failedRequests, and simplifiedDOM fields, but no JSDoc or TypeScript interface describes the structure for LLM consumption.

inspect_localhost_ui

MEDIUMenforce-result-limits ↗

DOM snapshot size unbounded. simplifiedDOM field could be very large for complex pages, risking context window exhaustion. No limit or truncation guidance documented in tool description.

inspect_localhost_ui

LOWrecovery-guide ↗

Error recovery hints are generic. buildErrorPayload() returns 'Retry the call' for unknown errors, but does not suggest specific next steps (e.g., check URL format, verify localhost is running, inspect browser logs).

inspect_localhost_ui

Recommendations

Add a TypeScript interface documenting the output schema (summary, consoleLogs, pageErrors, failedRequests, simplifiedDOM) and include it in JSDoc for the buildTextPayload function.
Document DOM snapshot size limits in the tool description. E.g., 'Simplified DOM is truncated to ~50KB to preserve context. For very large pages, use fullPage=false and inspect sections separately.'
Enhance error hints in buildErrorPayload(). For NETWORK_ERROR, suggest 'Verify the URL is correct and the dev server is running.' For TIMEOUT, suggest 'Increase delay parameter or check if the page is stuck loading.'
Add a note in the tool description about when to use inspect_localhost_ui vs. other debugging approaches (e.g., 'Use this for visual/layout bugs; for backend issues, check server logs directly.').
Consider returning a domTruncated flag in the summary (already present in meta) and document what it means for the LLM.

Score history

Overall score trend

First recorded score · v2 rubric

65/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	65	2026-07-28+	v2