Critical failures across all dimensions. Tool definitions exist only as static JSON objects in tools.ts with name and description fields, but NO input schemas, parameter types, or output schemas are visible in the provided source. Descriptions are minimal (10-50 chars) and lack actionable context. No parameter documentation, no error handling guidance, no security annotations. Tools are inferred from a static array rather than explicitly registered via MCP SDK. This is a REST API wrapper, not a proper MCP server implementation.

• Add explicit JSON Schema input definitions for every tool parameter. Example for github_create_pr_comment: { type: 'object', properties: { pr_id: { type: 'string', description: 'GitHub PR ID (e.g., 12345)' }, comment_text: { type: 'string', description: 'Comment body (markdown supported)' } }, required: ['pr_id', 'comment_text'] }
• Expand tool descriptions to 100-200 characters with WHAT, WHEN, and RETURN info. Example: 'Create a comment on a GitHub PR. Use this after reviewing code to provide feedback. Returns comment ID and URL for reference.'
• Document all parameters with type, constraints, and examples. For jira_search_issues, document the JQL parameter: 'JQL query string (e.g., project=PROJ AND status=Open). See Jira JQL docs for syntax.'
• Add destructiveHint and readOnlyHint annotations to tool definitions. Mark github_trigger_workflow, slack_send_message, jira_create_issue as destructive. Mark github_list_repos, slack_get_channel_history as readOnly.
• Implement error handling that returns structured error objects with error_code, message, and recovery_hint. Example: { error_code: 'CHANNEL_NOT_FOUND', message: 'Slack channel not found', recovery_hint: 'Call slack_list_channels to see available channels' }

Inferred effective spec: <=2025-11-25.

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