Loading ToolBench
MCP Server for visual test feedback in vibe coding — QA capability as a protocol
yo-bug has 9 tools with generally clear naming (verb_noun pattern) and detailed descriptions (100-300 chars each). However, input schemas are partially visible but lack explicit type definitions for complex parameters (e.g., 'items' in create_checklist is array but element schema missing). Parameter descriptions are present but some lack constraints (e.g., 'limit' has no min/max). Output schemas are not documented. Error handling guidance is minimal. Tool composition is reasonable but some tools combine multiple concerns (e.g., start_test_session auto-detects, starts proxy, opens browser).
Create a test checklist with GROUPED TEST CASES and push it to the user's browser. Each test case is a multi-step scenario. The user follows all steps in sequence, then marks the entire case as passed or failed. This is NOT a flat list of individual items — group related steps into logical test cases. Structure each case with: - title: Brief scenario name (e.g. "Normal login flow") - steps: Sequential actions the user should follow (array of strings) - expect: What the user should see after all steps
Get the current status of the active checklist — which items passed, which failed, and which are still pending.
Get full details of a feedback item, including element info, console errors, network errors, action steps, and annotated screenshot (as image content).
Get historical test records for a module. Shows what was tested before and what failed, so you can focus on weak areas.
List user-submitted test feedback. By default only shows feedback from the CURRENT session — use all_sessions=true to include older feedback. You MUST process ALL open items — fix each one and call resolve_feedback(id). Do not stop until the list is empty.
Complex parameter schemas lack element type definitions. 'items' in create_checklist is declared as array but the structure of each item (title, steps, expect) is not formally specified in the schema.
Numeric parameters lack min/max constraints. 'limit' in list_feedbacks and 'port' in start_test_session have no documented bounds, inviting invalid values.
Output schemas are not documented. Tools return data but LLMs cannot plan downstream calls without knowing response structure (e.g., what fields does get_feedback return?).
start_test_session combines multiple concerns: auto-detect port, start reverse proxy, open browser. Should split into separate tools for composability.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Mark a feedback item as fixed. This pushes a verification request to the browser — the user will confirm whether the fix actually works. Status changes to "verify" until user confirms.
Save a test record to history. Call this after testing is complete to persist results for future reference.
Start test mode. Auto-detects dev server, starts a reverse proxy with injected test feedback SDK, and opens the browser. After calling this, follow these steps: 1. Call get_test_history(module) to check past test records 2. Call create_checklist(title, items) to push a structured test plan 3. Tell the user to test. Shortcuts: Alt+E (element report), Alt+S (screenshot), Esc (exit) 4. Call get_checklist_status() and list_feedbacks() to read results 5. Fix issues, call resolve_feedback(id) for each — user verifies in browser 6. Call save_test_record() to persist results 7. Call stop_test_session() when done
Stop test mode. Shuts down the reverse proxy and any auto-started dev server. Returns a test session summary.
Error handling lacks recovery guidance. No tool description explains what to do if a call fails (e.g., 'If port is in use, try a different port or call get_available_ports()').