Loading ToolBench
A Model Context Protocol server that integrates with GitHub, Jira, and Notion APIs, providing tools to interact with these services
This server has 31 tools across GitHub, Jira, and Notion integrations. While all tools have explicit descriptions and input schemas visible in server.go, the quality falls significantly below production baselines. Tool names are generally well-chosen with action verbs (get_, create_, search_, list_), but parameter descriptions are minimal (typically 1-2 words: 'Repository owner', 'Issue title'). Schema definitions are present but sparse, most lack examples, constraints, bounds, or format specifications. No output schemas are documented. Error handling is minimal (generic JSON-RPC error codes with no recovery guidance). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite the server hosting both read-only and destructive operations. The README and inline comments suggest this is a proof-of-concept rather than production-grade tooling. Average tool description length is ~30-40 chars (well below the 194-char baseline); parameter descriptions average 15-20 chars (vs 72-char baseline). The server lacks pagination guidance, output filtering, or field documentation for any tool.
Add a comment to an issue or pull request
Assign users to an issue or pull request
Create a new branch in a repository
Create a new issue in a repository
Create a new pull request
Create a new repository
Get comments from an issue or pull request
Parameter descriptions are critically minimal (15-20 chars vs 72-char production baseline). Examples: 'Repository owner', 'Issue title', 'Pull request number'. LLMs cannot infer parameter constraints, expected formats, or domain-specific context from such sparse text.
No output schemas documented for any of the 31 tools. LLMs cannot plan downstream tool chains or extract required fields without knowing the response structure. Production baseline: 100% of A+ tools have documented return types.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). The server clearly distinguishes READ_ONLY vs WRITE operations in metadata, but these hints are not exposed in the tool definitions. This prevents agents from inferring safe retry boundaries and state-modification risks.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Get a commit from a repository
Get details of a specific issue
Get details of a specific pull request
Get the diff of a specific pull request for analysis
Get a release by tag from a repository
Get a tag from a repository
Get GitHub Actions workflows from a repository
List all branches in a repository
List commits in a repository
Trigger a GitHub Actions workflow
Search for code across repositories
Search for issues across repositories
Search for pull requests across repositories
Search for repositories
Create a new Jira ticket
Get details of a specific Jira ticket by its ID or key
Search for Jira tickets using JQL (Jira Query Language)
Create a new Notion database
Create a new Notion page
Get a Notion database by its ID
Get a Notion page by its URL
Search for Notion pages by title
Update a Notion database
Update a Notion page
Search tools (github_search_*) lack pagination guidance. The server returns all results without pagination, limit, or offset parameters. Per pattern baseline, tools returning lists should accept limit and page/offset parameters and return total count.
No error recovery guidance. The server implements generic JSON-RPC error codes (-32600, -32601, -32602) with minimal context. Production baseline (pattern:recovery-guide): errors must tell the LLM what to do next. Example: 'User not found. Try search_users() with a partial name.'
No parameter constraints documented (no enums, ranges, formats, or patterns). Example: 'draft' boolean in github_create_pull_request lacks description; 'query' string in searches has no length/format guidance. Per pattern:constrained-input, free-form strings invite hallucinated values.
Tool 'github_assign_copilot' has ambiguous naming. 'Copilot' is GitHub's AI assistant, the tool actually assigns human users. Should be 'github_assign_users' or 'github_add_assignees' to match user intent ('Assign John to this issue').
No dependency hints or discovery guidance. Tools like 'github_create_pull_request' require head/base branch names, but the server doesn't document that users should call 'github_list_branches' first. Per pattern:tool-description, discovery tools should explain their role in multi-step workflows.