Loading ToolBench
Model Context Protocol server for Linear issue tracking integration
The server defines 4 tools with complete input schemas and descriptions visible in internal/handlers/tools.go. Naming follows verb_noun convention (create_issue, update_issue, get_issue, list_teams). Descriptions are present but generic (10-50 chars); parameter descriptions are adequate but lack actionable constraints. Schemas are well-formed with type info and required flags, but lack output schema documentation. Error handling returns structured ToolResult with IsError flag and text explanations, but errors are generic and don't guide recovery. No tool annotations (readOnlyHint/destructiveHint) are declared despite clear read vs write semantics. Missing pagination on list_teams despite it being a discovery tool. create_issue and update_issue accept only system IDs (team_id, assignee_id) rather than human-friendly identifiers, forcing extra lookup calls.
Create a new issue in Linear
Get details of a specific issue by ID
List all teams in the Linear workspace
Update an existing issue in Linear
Output schemas not documented. LLMs cannot plan downstream tool calls without knowing what fields to expect from create_issue, update_issue, get_issue, and list_teams responses.
Tool descriptions are too generic and under 50 characters. 'Create a new issue in Linear' does not explain WHEN to call this vs searching/updating, what permissions are needed, or what the response contains. Baseline is 194 chars for production tools.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) declared. create_issue and update_issue are clearly destructive writes, but this is not signaled to the LLM via annotations. The server sets Risk:WRITE tags but these are not reflected in MCP tool definitions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
create_issue and update_issue require system IDs (team_id, assignee_id) with no fallback to human-friendly names or emails. Users say 'assign to john' not 'assign to U12345'. This forces agents to call lookup tools first, wasting tokens and latency.
list_teams has no pagination support (no limit, offset, or page_size parameters) and returns unbounded results. For workspaces with many teams, this bloats response size and wastes tokens. Should accept limit (default 20, max 100) and return total_count.
Error messages are generic text only ('Failed to create issue', 'Issue not found'). They do not tell the LLM what to do next or provide actionable recovery guidance. Example: 'Failed to create issue: team_id U123 does not exist. Available teams: engineering, product, support.'
Parameter 'priority' accepts integer 1-4 with description '1 is highest', but no enum constraint forces LLMs to reason about the range. Should declare enum: [1, 2, 3, 4] with descriptions like '1=urgent, 2=high, 3=medium, 4=low'.
No confirmation or dry-run support for write operations (create_issue, update_issue). Agents can make irreversible changes without a safety checkpoint. Should implement pattern:confirmation-request for destructive ops.