The Backlog MCP server presents 64 tools across a well-organized API surface, but suffers from critical deficiencies in schema visibility, parameter documentation, and description quality. While tool naming follows verb_noun conventions consistently (get_*, add_*, update_*, delete_*), the actual input schemas and parameter descriptions are not visible in the provided source code. The sample code shows a sophisticated handler composition system (composeToolHandler, composeNativeContentToolHandler) that wraps tools with error handling, organization context, field picking, and token limits, indicating mature infrastructure, but the underlying tool definitions themselves lack the transparency needed to verify schema completeness, parameter typing, and constraint documentation. Generic descriptions like 'Tools for managing issues and their comments' are reused across dozens of tools, providing zero signal for LLM tool selection. Critical deficiency: no parameter descriptions are visible, violating the pattern:tool-description rule that ALL params must have descriptions.

• Extract tool schemas from src/tools/*.ts files and audit each parameter. Provide sample JSON Schema showing input types, constraints (min/max/enum/pattern), and required vs optional fields. Current code does not display these.
• Replace all 63 generic descriptions with specific, LLM-optimized descriptions (50 - 200 chars) that answer: What does this tool do? When should I call it instead of similar tools? What does it return? E.g. for get_issue: 'Fetch a single issue by ID or key. Returns: id, key, summary, status, assignee, priority, created/updated dates, and custom fields. Use this to retrieve full details before updating. Returns null if not found.'
• For each tool, document all input parameters with: type, constraints (min/max/enum/regex/length), whether required, and what values are valid. E.g. for add_issue: 'summary (string, required, 1 - 255 chars), description (string, optional, max 10000), issueTypeId (integer, required, enum from get_issue_types), projectId (string, required), etc.'
• For paginated list tools (get_issues, get_pull_requests, get_watching_list_items, get_documents, get_wiki_pages), document limit (default/max), offset/cursor, and total count behavior. E.g. 'Returns max 100 items per page. Include offset (0 - based) and limit (1 - 100, default 20). Response includes total_count.'
• For read tools that accept identifiers (get_issue, get_user, get_project, get_wiki, get_document), clarify accepted formats. E.g. 'Issue ID can be integer (12345) or key (PROJ-123). User can be ID (5), email ([email protected]), or name (john).' If only one format is accepted, state it explicitly.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry