Loading ToolBench
Greenroom MCP server: human review feedback, readable and answerable by agents
Greenroom MCP demonstrates solid definition quality with well-structured tool names, comprehensive descriptions, and clear parameter schemas. All 7 tools follow verb_noun naming conventions (list_, get_, reply_, mark_, resolve_). Descriptions are detailed (100-300+ chars) and explain WHAT, WHEN, and consequences. Input schemas use proper JSON Schema with types and descriptions. However, output schemas are not documented in the visible code, and some parameter descriptions could be more explicit about constraints and formats. Error handling guidance is present in descriptions but not formalized in tool responses.
Fetch one feedback thread in full: story context (including the CSF importPath), pin, args, and every message. When the reviewer pinned a screenshot, it is returned as an image so you can see exactly what they were looking at.
List human review feedback threads on Storybook stories. Each item carries the story's CSF importPath so you can open the source file the story comes from, the component it belongs to, the viewport it was written in, plus the pin location, story args at comment time, whether a screenshot exists, and the full message history. Defaults to state=open (the feedback still awaiting work). A comment is filed against the component the reviewer was pointing at, which is not always the story they had open — see seenOnStoryId. Fix the component named in story.importPath.
Move a component whose state is changes_requested to addressed, after you have pushed fixes for it. This puts it back in front of the human reviewers for sign-off. State moves at the COMPONENT, not the variant: pass any story id belonging to the component (the CSF file) and every variant in that file moves with it. Reviewers sign off on components, so a single variant cannot be moved on its own.
Mark one feedback thread as addressed after you have done the work it asked for. Optionally post a note first explaining the fix. Humans resolve threads; you only signal that the work is done. Addressed is NOT resolved: the thread still counts as unresolved and still blocks approval of the variant it sits on until a human accepts your fix. That is deliberate — do not read a still-blocked variant as your change having failed, and never try to route around it.
Output schemas not documented. Tools return complex objects (threads with messages, screenshots, story context) but no schema is visible in code. LLMs cannot plan downstream operations without knowing response structure.
Pagination not explicit for list_feedback. Description mentions 'defaults to state=open' but no limit, offset, or cursor parameters visible. Large feedback lists could exceed context window.
resolve_thread lacks confirmation/dry-run pattern. Description warns this is irreversible and recorded under reviewer's name, but no confirmation step or preview mechanism visible. High risk of accidental resolution.
Parameter 'state' enum in list_feedback is clear, but other parameters lack format/constraint documentation. E.g., storyId format, threadId format, body length limits not specified in visible schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Post a reply on a feedback thread. Your reply is recorded as an agent note, visible to the human reviewers. Use it to explain what you changed or to ask for clarification.
Close a thread because the reviewer's point has been settled — they answered their own question, accepted a proposal, or the change they asked for has landed and been confirmed. 🔴 RESOLVING IS A JUDGEMENT ABOUT SOMEONE ELSE'S OBJECTION, and on a connection bound to a reviewer it is recorded under their name. The operator sitting in this session is the reviewer whose name will appear on the resolution.
Report the identity every action you take will be recorded under. Worth checking first: a token bound to a reviewer acts AS THAT PERSON, so replies are attributed to them and resolutions are recorded as theirs. Call this before resolving anything if you are unsure whose name is on it.
Error handling not formalized in tool definitions. Descriptions mention 'agent note' and 'audit trail' but no error response schema or recovery guidance visible. LLMs cannot distinguish retryable vs fatal failures.