Linear-server defines 4 read-only tools with basic schemas and descriptions. All tools have input schemas with type definitions and descriptions present. However, descriptions are generic (avg 60 chars, well below the 194-char baseline for A+ tools), parameter descriptions lack actionable detail, and output schemas are not documented. No error recovery guidance. Tools accept string parameters that should be enums (status, assignee, team), LLMs will hallucinate invalid values. No pagination support despite fetching lists. Missing tool annotations (readOnlyHint). Composition is reasonable (single responsibility per tool), but parameter design forces unnecessary lookups (e.g., 'assignee' as free-form string instead of enum or ID).

• Convert 'status', 'assignee', and 'team' parameters to enums or provide explicit valid-value lists in descriptions. E.g., status: enum ['Todo', 'In Progress', 'Done', 'Cancelled'] with description 'Workflow state name (case-insensitive).'
• Document output schema for each tool. E.g., get_tasks returns array of {id, title, status, assignee, team, url, createdAt, updatedAt}. This enables LLMs to chain calls and extract IDs.
• Add pagination to get_tasks: accept 'offset' (default 0) and 'limit' (default 20, max 100), return {tasks: [...], total: N, hasMore: bool}. Prevents context window exhaustion.
• Expand tool descriptions to 100 - 200 chars. Include WHEN to use (e.g., 'Call this to list all tasks in a team before filtering by assignee'), WHAT it returns, and dependencies.
• Add readOnlyHint: true to all tool definitions (via tool annotations in capabilities). Signals to agents these are safe, non-destructive calls.