Loading ToolBench
MCP server for generating technical documentation from GitHub PRs and issues
The server exposes a single tool, writeDocumentation, with reasonable naming and a clear purpose. The tool has a documented description and input schema with proper type definitions. However, there are significant gaps in parameter descriptions, missing output schema documentation, and no explicit error handling guidance. The tool conflates two concerns (fetch GitHub data AND generate documentation), and critical metadata fields (owner, repo, number) needed for chaining are not explicitly guaranteed in the output schema.
Fetch GitHub PR/issue data and return a prompt for the client LLM to generate technical documentation. Returns the documentation guide along with GitHub context.
Tool combines two concerns: fetching GitHub PR/issue data AND generating documentation. LLMs expect single-responsibility tools. Split into separate tools: fetchGitHubContext and generateDocumentation.
Output schema is not documented in the source code. While the tool clearly returns documentation and GitHub context, there is no explicit declaration of return field types, structure, or required fields. LLMs cannot plan downstream tool calls without knowing what fields are available.
Parameter descriptions are incomplete. 'notes' parameter has a description, but 'prUrl' and 'issueUrl' descriptions lack detail about when to use each vs the other, whether at least one is required, and what happens if both are provided. Ambiguity forces LLM guessing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
No error handling guidance. The GitHubClient throws errors for invalid URLs, failed API calls, and missing issues, but the tool schema does not document error cases or recovery steps. An LLM receiving 'Invalid GitHub PR URL' has no guidance on what to do next.
Mutual exclusivity not documented. Both prUrl and issueUrl are optional with no explicit statement that at least one is required. The tool will throw an error if both are missing or both are provided, but LLMs cannot know this from the schema.
No pagination or result limits documented. If a PR has thousands of files or hunks, the tool truncates patches (hardcoded 50KB limit) but this is not exposed in the schema or description. LLMs cannot know what truncation behavior to expect.