Loading ToolBench
MCP server exposing Backlog project management tools for Claude Desktop
Backlog MCP demonstrates solid fundamentals: all 8 tools have clear action-verb names (get_*, add_*, manage_*), comprehensive parameter descriptions, and well-structured JSON schemas with types. Tool descriptions are detailed (100-200 chars typical), explaining WHAT and WHEN. However, output schemas are not explicitly documented in the source, responses are inferred from API calls rather than formally declared. Error handling is minimal; no recovery guidance or actionable error messages visible. Security is strong (API keys injected server-side via config, never exposed as parameters). Composition is clean: tools are single-responsibility, and chaining IDs are returned (e.g., issue_key from get_comments feeds into add_comment). Parameter constraints are well-described (e.g., 'max 100', 'comma-separated ids'), but some lack formal enum declarations (e.g., activity_type accepts comma-separated ids but no enum list).
Post a comment on an issue, optionally mentioning users AND changing ticket fields in the very same request.
Get the recent activity feed — who changed what, and when.
List the files attached to an issue or wiki page, or download one of them. Call once without attachment_id to see what is there, then again with the id.
Read comments of one or many issues. Several issues are fetched in parallel.
Get the authenticated user's Backlog notifications, or just their count.
Get what the authenticated user looked at most recently — handy for 'the ticket I was just on' without knowing its key.
Output schemas not formally documented. Tool descriptions explain inputs but not return types/fields. LLMs cannot plan downstream calls without knowing what fields to expect.
No error recovery guidance. Tools lack actionable error messages (e.g., 'User not found. Try search_users()' or 'Invalid status: must be one of: open, in_progress, resolved'). Errors are raw API responses.
activity_type parameter accepts comma-separated type ids but lacks enum constraint. Description lists valid ids (1=IssueCreated, etc.) as text; should be a formal enum or pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Edit or delete an existing comment on an issue.
Mark one notification — or every notification — as read.
add_comment combines multiple concerns: posting text, mentioning users, AND updating ticket fields (status, assignee, priority, etc.) in one call. While efficient, this violates single-responsibility. Consider splitting into add_comment + update_issue_fields.
No pagination or result limits documented for list-returning tools (get_activities, get_recently_viewed, get_notifications, get_comments). Default counts are set (20), but no explicit cap or next_cursor guidance for large result sets.