Loading ToolBench
MCP server for GitHub Projects V2 - manage projects, items, fields, and views
Server provides 17 well-structured tools with consistent naming (verb-noun pattern), comprehensive Zod schemas with descriptions, and clear type definitions. All tools follow action-verb conventions (list_, get_, create_, update_, delete_, add_, remove_). Schemas are complete with proper enum constraints and typed parameters. However, tool descriptions are somewhat generic and lack context about WHEN to use each tool, recovery guidance for errors, and operational guidance about consequences (e.g., which operations are safe to retry). Output schemas are not documented in the visible code, responses are not formally specified. Error handling exists but lacks recovery guidance. Security considerations (permissions, rate limits) are not apparent in tool definitions.
Add a new draft issue to a GitHub Project V2
Add an existing issue or pull request to a GitHub Project V2
Create a new field in a GitHub Project V2
Create a new GitHub Project V2
Delete a field from a GitHub Project V2
Delete a GitHub Project V2
Get detailed information about a specific GitHub Project V2
Output schemas not documented. Tool descriptions define inputs but responses are not formally specified. LLMs cannot determine what fields to expect from each call, breaking chaining and increasing hallucination risk.
Destructive operations (delete_project, remove_project_item, delete_field) lack confirmation/dry-run mechanisms. No guidance on whether operations are idempotent or retryable. Agents cannot safely retry on transient failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 74 | 2026-07-28+ | v2 |
Get detailed information about a specific item in a GitHub Project V2
Get detailed information about a specific view in a GitHub Project V2
List all fields in a GitHub Project V2
List all items (issues, pull requests, draft issues) in a GitHub Project V2
List all views in a GitHub Project V2
List GitHub Projects V2 for a user or organization
Remove an item from a GitHub Project V2
Update a field in a GitHub Project V2
Update a field value for an item in a GitHub Project V2
Update a GitHub Project V2 (title, description, readme, visibility, or closed status)
Tool descriptions lack operational context. Examples: create_project does not state whether title must be unique; update_project does not explain which fields trigger side effects; add_existing_issue does not clarify if contentId must be from the same repo. Missing these details forces LLMs to guess and retry on failures.
No error handling or recovery guidance visible in tool definitions. If a GraphQL call fails, what should the agent do? Retry? Call a different tool? Escalate? LLMs receive no guidance.
Tool descriptions do not indicate which operations modify state and should be retried cautiously. No distinction between read-only and write operations in the schema or description, only in Risk metadata. LLMs cannot infer consequences from the description text alone.
Parameter descriptions lack constraint details. Example: 'first' parameter says 'Number of projects to return (default: 20, max: 100)' but does not forbid values outside [1, 100]. LLMs may pass -1, 999, or non-numeric values. Validation rules should be explicit and machine-parseable.
No tool permissions or scope declarations visible. Cannot determine if a tool requires 'repo' scope, 'admin:org_project' scope, etc. Audit trail and least-privilege configuration are impossible.
Pagination support present but inconsistent documentation. list_projects and list_project_items accept 'after' cursor but do not specify how to detect end-of-results (hasNextPage field? null cursor?). Agents cannot reliably paginate.
update_item_field value parameter is a union object with optional text/number/date/singleSelectOptionId/iterationId. No guidance on which field must be set for which field type. Type mismatch (e.g., passing 'text' to a NUMBER field) will silently fail.
create_field accepts singleSelectOptions array with name/color required but description optional. No constraint on color format (hex? named?). No max length on option names. LLMs will pass invalid options.