Loading ToolBench
Cloudflare Worker MCP server for GitHub issues management via OAuth
GitHub Issues MCP demonstrates solid tool design across 12 well-structured tools. All tools have clear verb-noun naming (list_repos, create_issue, get_issue, etc.), descriptive names that convey action intent, and explicit parameter schemas with type definitions. Descriptions are consistently present and reasonably detailed (80-250 chars typical). However, several medium-severity gaps prevent a higher score: (1) output schemas are not documented in source code or responses, the rubric requires documented output schemas for the LLM to plan downstream calls; (2) parameter descriptions could be more actionable, many lack concrete constraint details ('Repo in owner/name format' but no regex pattern or example of invalid input); (3) error handling strategies are not visible in the schema definitions; (4) no tool annotations (readOnlyHint/destructiveHint) despite clear read-only vs write distinctions (Risk field present but not reflected in schema). The server shows mature patterns (paginated list tools, well-named parameters, schema constraints) but lacks the polish expected of A-grade tools.
Add a comment to an issue (add comment). The comment supports Markdown.
Diagnostic: verify that the GitHub Issues MCP server is operational and OAuth authentication is valid. Use when unsure about the connection.
Create a new issue on a GitHub repo (create issue). Supports title, body, labels, milestone and assignees.
Create a new label on a GitHub repo (create label). Name, hex color and optional description.
Create a new milestone on a GitHub repo (create milestone). Title, description and due date are optional.
Retrieve a complete issue with its comments (get issue detail). Returns the body, labels, assignee, milestone and all comments.
Output schemas not documented. The rubric requires that tool responses document what fields LLMs will receive so they can plan downstream tool calls. No response structure definitions visible in source. For example, list_issues should document: returns array of {number, title, state, labels, assignee, milestone, created_at, updated_at}. This forces LLMs to guess output structure and invites errors when chaining tools (e.g., get_issue → extract issue_number → add_issue_comment).
Parameter constraints lack concrete, actionable detail. Example: 'Repo in owner/name format (e.g. your-username/your-repo)', good start, but should add pattern constraint or validation rule. The description should state: 'Repo in owner/name format: must match ^[a-zA-Z0-9._-]+/[a-zA-Z0-9._-]+$. Invalid input will return 404.' This lets LLMs self-correct on retry without guessing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 57 | - | v1 |
GitHub Issues MCP usage guide. Lists all available tools with examples. Call when unsure how to start.
List issues from a GitHub repo (list issues). Filter by state (open/closed/all), labels, milestone, assignee. Pagination included.
List labels from a GitHub repo (list labels). Returns name, color and description for each label.
List milestones from a GitHub repo (list milestones). Returns title, state, number of open/closed issues and due date.
List authorized GitHub repos for this MCP server (list repositories). Returns metadata for each repo: description, visibility, number of open issues, language. Always call this tool first to see which repos you can work with.
Modify an existing issue (update issue). Can change title, body, state, labels, milestone, assignees.
No tool annotations (readOnlyHint/destructiveHint). The schema includes Risk field (READ_ONLY vs WRITE) but this is not expressed in the MCP tool registration via annotations. Modern MCP tools use destructiveHint:true for write operations (create_issue, update_issue, add_issue_comment, create_label, create_milestone) and readOnlyHint:true for reads. This helps clients and LLMs understand safety properties without parsing descriptions.
Error handling strategy not visible. The descriptions do not state how tools will respond to common failure cases (repo not found, invalid milestone, unauthorized access, API rate limit). Rubric requires error responses to be actionable: e.g., 'If repo is not found, try list_repos() to see available repositories.' None of the tool descriptions include recovery guidance.
Pagination limit enforcement not documented. list_issues, list_labels, list_milestones accept per_page/page but no response states the limit cap or total count. Rubric requires: 'Returns paginated results (max 100 per page). Response includes total_count and current_page so LLM can decide whether to fetch more.' Without this, LLMs cannot predict result cardinality.
Chaining metadata missing. Tools that return lists (list_repos, list_issues, list_labels) do not document that results include IDs needed for follow-up calls. For example, list_issues should note: 'Each result includes issue_number, which you can pass to get_issue, update_issue, or add_issue_comment.' This clarifies the composition path and prevents discovery dead-ends.