Loading ToolBench
Enhanced Linear MCP server with snake_case tool naming
This Linear MCP server has significant gaps in definition quality. While all 16 tools are registered with names and schemas visible in src/index.ts, descriptions are present but often generic (avg ~60-80 chars, below the 194-char baseline). Naming follows verb_noun convention (list_*, get_*, create_*, execute_*) which is good, but several parameter descriptions are minimal or missing context. Schema coverage is inconsistent: some tools have well-typed parameters (e.g., list_issues with teamId, projectId filters), but others have vague typing or missing parameter constraints. Critical gap: the execute_pipeline tool accepts 'condition' and 'transform' as untyped 'description' fields rather than properly constrained types, this is a code smell for dynamic execution patterns that are hard for LLMs to reason about. Error handling exists but is generic (mostly 'Invalid X arguments'). No output schemas are documented; users must infer return types from the code. The pipeline tool is particularly problematic, it enables arbitrary tool chaining with conditional/transformation logic, but provides no schema documentation or safety constraints for that composition.
Create a comment on a Linear issue
Create a new issue in Linear
Execute a pipeline of Linear tool operations in sequence
Get details of a specific issue within a cycle in Linear
Get a specific cycle by ID from Linear
Get issues from a specific cycle in Linear
Get a specific issue by ID from Linear
execute_pipeline tool allows arbitrary composition with untyped 'condition' and 'transform' fields. These are described as 'Optional condition function' and 'Optional transform function' but have no schema type enforcement, making them impossible for LLMs to reason about or validate. This violates the constrained-input pattern.
Output schemas are not documented. Tools return Linear SDK objects or mapped responses (e.g., list_issues returns {nodes: [{id, title, status}]}, list_users returns {nodes: [{id, name, displayName}]}), but these return types are not formally declared in tool definitions. LLMs cannot plan downstream calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Get a specific team by ID from Linear
Get a specific user by ID from Linear
List cycles from Linear workspace
List comments for a specific issue in Linear
List issues from Linear with optional filtering by team, project, label, state, priority, or assignee
List labels from Linear workspace
List projects from Linear workspace
List teams from Linear workspace
List users from Linear workspace
explore_cycle_issue has an ambiguous name. It could mean 'describe an issue within a cycle' or 'search for cycle issues'. The verb 'explore' is not action-specific and does not clearly distinguish this from get_issue or get_cycle_issues. Per naming guidelines, this should be get_cycle_issue or describe_issue_in_cycle.
Many tool descriptions are under 100 characters and lack context on WHEN to use them. E.g., get_user: 'Get a specific user by ID from Linear' (45 chars), does not explain when to call this vs list_users, what the user object contains, or dependencies.
Parameter descriptions for pagination (first, includeArchived) lack context. 'first' is used in list_users, list_teams, list_cycles, list_issue_comments but descriptions do not clarify: Is this count? Cursor? Is there a next_cursor for continuation? Are results capped? Default=50 for list_issues but no explicit max documented.
Error handling is minimal. Most validation errors throw 'Invalid X arguments' with no guidance on what makes arguments valid. No structured error responses guide LLM recovery (e.g., 'user not found, try list_users() first'). No distinction between retryable, user-fixable, and fatal errors.
create_issue and create_comment are destructive operations but descriptions do not state this or offer dry-run/confirmation patterns. Agents should know these calls have irreversible side effects. No idempotency guidance is provided.
list_cycles, list_projects, and list_labels accept 'first' parameter for pagination but description is omitted entirely (only '{}' shown). Without bounds documentation, LLMs may pass unbounded values.
No tool accepts human-friendly identifiers (names, emails, display names) alongside IDs. All lookups require opaque IDs (teamId, projectId, assigneeId, stateId). This forces extra discovery calls, if user says 'assign to Alice', agent must first call list_users to find Alice's ID, then create_issue.
execute_pipeline is a meta-tool that composes other tools but adds no value over agent-native composition. It increases complexity without clear benefit, introduces validation risk, and its condition/transform logic is underspecified. Consider removing or replacing with a simpler batch_create_issues pattern if bulk operations are needed.