Loading ToolBench

Reading the current corpus…

Forge MCP server · C · ToolBench

Forge

AI-native Kanban project management server for Claude Code & Codex, providing MCP tools for ticket and project management

2026-07-28+STREAMABLE_HTTP7 tools

66/100

Definition Quality60

Protocol Readiness82

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: stateless requests, Streamable HTTP

Current-spec patterns detected

Summary

Forge MCP demonstrates solid fundamentals: all 7 tools have clear verb-noun names (list_*, create_*, update_*, get_*, add_*), explicit JSON schemas with typed parameters, and descriptions. However, parameter descriptions are sparse (many lack detail on format/constraints), output schemas are not documented, and error handling lacks recovery guidance. Tool composition is clean (single responsibility), but descriptions average ~40 chars, below the 194-char baseline for A+ tools. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles.

Tools (7)

add_commentwriteauth50/100

Add a comment to a ticket

create_ticketwriteauth50/100

Create a new ticket in a project

get_ticketread onlyauth50/100

Get a ticket by reference with full relations (tags and comments)

list_projectsread onlyauth50/100

List all projects

list_ticketsread onlyauth50/100

List tickets with optional filtering

update_ticketwriteauth50/100

Update ticket fields (title, description, acceptance_criteria, priority)

update_ticket_statuswriteauth50/100

Update ticket status (backlog, in_dev, review, done)

Issues (5)

HIGHconstrained-input ↗

Parameter descriptions lack format/constraint details. E.g., 'Ticket reference (e.g. PI-42)' does not explain the format pattern or validation rules. LLMs cannot infer whether 'PI-42' is the only valid format or if 'PI_42' or 'pi-42' are acceptable.

get_ticketupdate_ticketupdate_ticket_statusadd_comment

HIGHtool ↗

Output schemas are not documented. Tools return structured data (tickets with tags/comments, project lists) but the response format is not visible in the tool definitions. LLMs cannot plan downstream calls or extract required fields without trial-and-error.

list_projectscreate_ticketlist_ticketsget_ticket

MEDIUMtool-description ↗

Tool descriptions are too brief (avg ~40 chars vs 194-char baseline). 'List all projects' and 'List tickets with optional filtering' lack context on when to call them, what data they reveal, or how they fit into workflows. LLMs struggle to select the right tool when descriptions are terse.

list_projects

Recommendations

Expand tool descriptions to 100 - 200 chars. E.g., 'List all projects in the workspace. Call this first to discover available project IDs before creating or filtering tickets.' This guides LLM selection and reduces discovery calls.
Document output schemas for all tools. Add a 'Returns' section to each tool definition specifying field names, types, and meanings. E.g., create_ticket returns {ticket_id, ref, title, status, created_at}.
Add format constraints to reference parameters. E.g., 'Ticket reference in format PROJECT-NUMBER (e.g., PI-42). Use list_tickets() to find valid references.' This prevents invalid input and guides LLM behavior.
Implement tool annotations in the MCP schema. Map Risk metadata (READ_ONLY, WRITE) to readOnlyHint and destructiveHint so clients know which tools are safe to retry and which require confirmation.
Enhance error messages with recovery hints. E.g., 'Ticket PI-999 not found. Available tickets in project PI: PI-1, PI-2, PI-42. Try list_tickets(project_id=...) to see all.' This enables agent self-correction without extra calls.

Score history

Overall score trend

First recorded score · v2 rubric

66/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	66	2026-07-28+	v2