github-issues-mcp has well-structured tool definitions with complete input schemas and clear descriptions. All 10 tools are explicitly registered with proper JSON Schema. Naming follows verb_noun convention (list_issues, get_issue, create_issue, etc.). Descriptions are concise (10-100 chars) and action-oriented. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are minimal (e.g., 'Repository owner' lacks context on format/constraints). Error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Missing pagination guidance for list_issues and list_project_items. No confirmation pattern for destructive operations (create_issue, update_issue, add_to_project).

• Document output schemas for all tools. E.g., list_issues returns {issues: [{number, title, state, labels, created_at, updated_at}], total_count}. Include all fields agents need for downstream chaining.
• Add tool annotations: mark list_*, get_* with readOnlyHint=true; mark create_*, update_*, add_*, move_* with destructiveHint=true. This enables agents to reason about side effects.
• Enhance parameter descriptions with format/constraint details. E.g., 'owner: GitHub username or organization name (alphanumeric, 1-39 chars)'; 'issue_number: positive integer, 1+'; 'labels: comma-separated string or array of label names'.
• Add pagination to list_issues and list_project_items: include limit (default 20, max 100), offset/cursor, and total_count in response. Document in description: 'Returns up to 20 items per call. Use offset to paginate.'
• Add error recovery hints in descriptions. E.g., create_issue: 'If labels are invalid, call list_labels first to see available options.' update_issue: 'State must be open or closed; invalid values will be rejected.'