Loading ToolBench
Browser overlay + inspector panel + MCP server for visually editing Tailwind CSS classes on a running React app
Convey MCP server has 5 tools with mixed quality. Tool naming follows verb_noun convention (get_, implement_, mark_, list_, discard_). Descriptions are present but vary in clarity, some are verbose and include implementation details (implement_next_change at 280+ chars) while others are terse. Input schemas are visible for all tools, but most are minimal (empty objects or single enums). Critical gap: no output schemas documented anywhere. Error handling is absent, no guidance on what happens on failure, retry logic, or recovery paths. The implement_next_change tool description conflates multiple concerns (waiting, returning instructions, requiring agent action, looping) which violates single-responsibility principle. mark_change_implemented accepts legacy 'ids' array alongside new 'commitId' flow, creating ambiguity. No parameter descriptions for most inputs (e.g., 'status' enum in list_changes lacks explanation of what each status means in the workflow). Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present but not formalized as tool annotations in the schema.
Discards all changes regardless of status
Waits for and returns the next committed change (full commit with all patches). Transitions the commit to 'implementing' status. Returns only the raw commit data — no workflow instructions. Use implement_next_change instead if you want guided implementation with auto-looping.
CONTINUOUS LOOP: Waits for the next committed change (a commit with class-changes and context messages), returns implementation instructions, and REQUIRES the agent to apply all class-changes, mark them done, then call this tool AGAIN. Messages in the commit provide context for understanding intent. The agent MUST keep calling this tool in a loop until explicitly stopped by the user.
Lists changes grouped by commit status. Optionally filter by a specific status.
Marks changes as implemented after the agent has applied them to source code. Accepts either commitId + per-patch results (new) or legacy ids array. After calling this, you MUST call implement_next_change again to continue processing.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
implement_next_change description violates single-responsibility principle, it waits, returns instructions, requires agent action, and loops. This conflates multiple concerns and makes the tool's contract ambiguous.
mark_change_implemented accepts both legacy 'ids' array and new 'commitId' flow. Dual-mode parameters create ambiguity, LLMs will struggle to choose the right path. Deprecate legacy mode or split into separate tools.
Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present in comments but not formalized as tool annotations in the schema. Modern MCP spec supports readOnlyHint, destructiveHint, idempotentHint, use them.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
No error handling guidance. Tools do not document what happens on failure, whether errors are retryable, or what the LLM should do next. E.g., what if get_next_change times out waiting for a change?