Loading ToolBench
A Model Context Protocol server for Phabricator integration
The server defines 10 tools with consistent naming patterns (verb-first: get_, add_, subscribe_, accept_, request_) and descriptive docstrings. However, several critical quality gaps reduce the score: (1) Parameter descriptions exist but are minimal (typically 30-50 chars, below baseline 72 chars). (2) Output schemas are NOT documented anywhere, tools return formatted strings but the agent cannot reason about response structure. (3) Error handling is present (try/except) but returns generic error messages ('Phabricator API Error: ...') without recovery guidance or classification. (4) API token exposure, while documented as 'Optional API token for personal authentication,' passing tokens as parameters violates secret-injection patterns; should use only server-side environment variables. (5) No pagination support despite tools returning potentially large results (e.g., differential comments, review feedback). (6) Tool descriptions are adequate (50-150 chars, within baseline 34-392) but lack WHEN-to-use context or dependency hints.
Accept a differential revision.
Add a comment to a differential revision.
Add a comment to a Phabricator task.
Get details of a Phabricator differential revision.
Get detailed code review information including comments and code changes.
Get review feedback with intelligent code context for addressing comments. Perfect for understanding what needs to be changed and where to change it. Analyzes comments and correlates them with specific code locations.
No output schemas documented. Tools return formatted strings but agent cannot parse response structure or extract chaining IDs (e.g., task_id from get_task result needed by add_task_comment). Described at pattern:tool and mxe:include-chaining-ids.
API tokens exposed as optional tool parameters (api_token: str = None). Tokens in tool parameters are logged in traces and prompt history, violating secret-injection pattern. Should inject via environment variables only and use ClientManager internally.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Get details of a Phabricator task.
Request changes on a differential revision.
Subscribe users to a differential revision.
Subscribe users to a Phabricator task.
Error messages are generic ('Phabricator API Error: ...') and provide no recovery guidance. Per pattern:recovery-guide, errors should tell the agent what to do next (e.g., 'Task not found. Try search_tasks() with a partial title.').
Parameter descriptions are minimal (30-50 chars, well below baseline 72 chars). E.g., 'Task ID (without 'T' prefix)' leaves the agent guessing whether to pass 'T123' or '123'. Should specify: 'Task ID as a number without the 'T' prefix (e.g., 123, not T123).'
No pagination support. Tools like get_review_feedback and get_differential_detailed may return large results (all comments, code changes, context lines). No page/offset/limit parameters or documentation of result caps. Per mxe:enforce-result-limits, should cap results at 20-50 items and document the limit.
Tool descriptions lack WHEN-to-use context and dependency hints. E.g., get_task vs get_differential are both read operations but serve different Phabricator entities. Description should clarify: 'Use to fetch a bug or task (Maniphest). For code review changes, call get_differential() instead.'
Irreversible operations (accept_differential, request_changes_differential) have no confirmation or dry-run support. Per pattern:confirmation-request, destructive/state-changing tools should support a confirmation step to prevent agent mistakes.
subscribe_to_task and subscribe_to_differential accept user_phids as a comma-separated string rather than an array. Per pattern:constrained-input, should use structured input (array of strings) and validate each PHID format server-side. Current format invites parse errors.