Loading ToolBench
Loopback — a project-tagged feedback bus for coding agents (Claude Code, Codex, Gemini CLI) over MCP. Capture UI/backend/usage/UX feedback once; let any agent claim, fix, and write the change back.
Strong tool definitions with complete schemas, clear descriptions, and proper error handling. All 9 tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun convention (submit, list, get, claim, update, add, link, resolve, stats). Descriptions are detailed and actionable (avg ~180 chars), explaining WHAT, WHEN, and WHAT to do next. Parameters use enums for constrained values (status, type, severity). Error responses guide recovery ('Use loopback_list_feedback to see valid ids'). Strict input validation prevents typos from silently failing. Main gaps: output schemas not formally documented in code; some parameter descriptions could be more prescriptive about format/range; no explicit idempotency guarantees stated.
Append a comment to a feedback item's discussion trail. Use for investigation notes, questions back to the reporter, or reasoning worth preserving. Args: id, author, body (markdown ok).
Atomically claim a feedback item for an agent before working on it. Prevents two agents from fixing the same thing. Args: id, agent (your name, e.g. 'claude-code', 'codex', 'gemini'), force (default false). On success the item's assignee_agent is set and status moves to 'in_progress' (from open/triaged). If another agent already holds the claim, this fails with a message naming the holder — pass force=true only if you intend to take over.
Fetch one feedback item with full context: description, repro steps, console lines, network entries, screenshot/replay links, linked change (commit/PR), and the complete comment trail. Args: id (fb_...), response_format (markdown|json). Read this before starting a fix — it contains everything captured at report time.
Attach the fix to a feedback item so the loop is auditable: which repo/branch/commit/PR addressed it and a one-paragraph diff summary. Args: id, plus any of repo, branch, commit, pr_url, diff_summary. Provided fields merge into existing links. Call this right after committing the fix, before updating status to 'fixed'.
Output schemas not formally documented. Tool descriptions explain what is returned (e.g., 'Returns items ordered most-severe first, then newest. Pagination metadata: total, count, offset, has_more, next_offset') but JSON Schema output types are not visible in code. LLMs cannot reliably plan downstream tool calls without knowing exact response field names and types.
Parameter format constraints not fully specified. Descriptions mention 'id (fb_...)' and 'agent (e.g. claude-code, codex, gemini)' but do not formally constrain format (regex, length, allowed characters). LLMs may pass invalid values like 'fb_invalid_id' or 'my-custom-agent' without validation guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
List feedback items, filtered and paginated. This is the entry point for "work the queue". Args (all optional): project, status (open|triaged|in_progress|fixed|verified|wontfix), type (ui|backend|usage|ux), severity (p0-p3), source, assignee_agent, limit (default 20), offset (default 0), response_format (markdown|json). Returns items ordered most-severe first, then newest. Pagination metadata: total, count, offset, has_more, next_offset. Typical agent flow: loopback_list_feedback(project='X', status='open') → loopback_claim_feedback → fix → loopback_link_change → loopback_update_status(status='fixed').
Mark a feedback item as resolved (verified or wontfix) with optional resolution notes. This is the final closure step after a fix is verified or a decision is made not to fix.
Get aggregate statistics on feedback items: counts by status, type, severity, and project. Useful for dashboards and reporting.
Create a new feedback item in the Loopback bus. Use this to file any observation about a running product: a UI defect, a backend error, a usage insight, or a UX papercut. Every item is tagged to a project so the right agent picks it up later. Args: project (slug), type (ui|backend|usage|ux), title, and optionally body, severity (p0-p3, default p2), source, reporter, route, url, dom_selector, screenshot_path, replay_url, console[], network[], repro_steps[]. Returns the created item as JSON, including its generated id (fb_...). New items start with status 'open'. Example: file "Pay button dead on iOS Safari" with project='shop-web', type='ui', severity='p1', route='/checkout'.
Move a feedback item through the workflow: open → triaged → in_progress → fixed → verified | wontfix. Args: id, status, note (optional — recorded as a comment for the audit trail), author (default 'agent'). Use 'fixed' after making the change; use loopback_resolve_feedback for final verified/wontfix closure.
Idempotency not explicitly declared. Tools like loopback_submit_feedback and loopback_add_comment modify state but do not document whether repeated calls with identical inputs produce duplicate records or are safely idempotent. Agents retrying on ambiguous failures risk creating duplicates.
loopback_stats description is minimal (65 chars). Does not explain when to call it, what 'aggregate statistics' means, or what fields are returned. Agents may not recognize this as a discovery/reporting tool.
No explicit permission/scope declarations. Tools like loopback_submit_feedback and loopback_claim_feedback modify state but do not declare required permissions (e.g., 'write:feedback', 'claim:feedback'). Audit trail and least-privilege configuration are unclear.