Loading ToolBench
A minimal personal MCP server that can read and write anything on GitHub via a Personal Access Token.
Single generic tool with acceptable schema but significant definition gaps. Tool name 'github_request' lacks action verb clarity (should be 'make_github_request' or similar). Description is verbose (380+ chars, exceeds 200-char baseline for LLM optimization) and reads like API documentation rather than agent guidance. Parameters are typed with Zod but lack individual descriptions for 'query' and 'body', only 'method' and 'path' have descriptions. No output schema documented. Error handling returns raw JSON without recovery guidance. Tool is overly generic, combining read/write/all-methods into one, violating single-responsibility principle. No pagination, rate-limit, or result-limit guidance despite GitHub API returning large datasets.
Make an authenticated request to any GitHub REST API v3 endpoint (read or write). Use this for everything: listing/creating/updating repos, issues, pull requests, comments, files (create_or_update via PUT /repos/{owner}/{repo}/contents/{path}), branches, releases, labels, workflows, etc. Full API reference: https://docs.github.com/en/rest. Path must start with '/' and be relative to https://api.github.com (e.g. '/repos/OWNER/REPO/issues'). For GET requests with query params, either append them to `path` as a query string or pass `query`. For write requests (POST/PATCH/PUT/DELETE), pass a JSON-serializable object as `body`.
Tool name lacks action verb. 'github_request' is generic and does not convey intent. Should be 'make_github_request' or split into 'get_github_resource', 'create_github_resource', 'update_github_resource', 'delete_github_resource' to match LLM verb-noun expectations.
Description is 380+ characters, exceeding 200-char baseline. Reads as API reference, not agent guidance. Should state WHAT (make authenticated GitHub API calls), WHEN (to read/write repos, issues, PRs, files), and PREREQUISITES (valid GitHub token). Remove example paths and API reference links.
Parameters 'query' and 'body' lack descriptions. Only 'method' and 'path' are described. LLMs cannot infer that 'query' accepts key-value pairs for filtering or that 'body' is JSON-serializable. Add descriptions: 'query: Optional query string parameters (e.g., per_page, page, state). Values are strings, numbers, or booleans.' and 'body: Optional JSON request body for POST/PATCH/PUT operations.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
No output schema documented. LLMs cannot plan downstream calls or extract fields. Should document: returns HTTP status, status text, and parsed JSON response body. For errors, returns isError=true with error message. No guidance on pagination, rate limits, or result caps despite GitHub API returning large datasets.
Error handling returns raw JSON without recovery guidance. 'HTTP 404' or 'Request failed: ...' tells agent nothing. Should categorize errors (retryable, user-fixable, fatal) and suggest next steps: 'Resource not found. Verify path is correct or call list_github_repos() to discover available resources.'