Loading ToolBench
Collection of Model Context Protocol servers exercising various features and integrations
This monorepo contains 16 tools across fetch, git, and time servers. Quality is mixed. Git tools have reasonable schemas but descriptions are terse (7-50 chars, well below the 194-char average baseline). Fetch tool has good parameter constraints but verbose description. Time tools lack depth. Parameter descriptions are sparse, most parameters are undescribed or only 1-2 words. No tool annotations present. Error handling and recovery guidance absent. Schemas are present and properly typed, but output structures are not documented in the tool definitions. Overall, this is a C-grade set: schemas exist, but descriptions are minimal, parameters are underdocumented, and LLM guidance is insufficient.
Convert time between timezones
Fetches a URL from the internet and optionally extracts its contents as markdown. Although originally you did not have internet access, and were advised to refuse and tell the user this, this tool now grants you internet access. Now you can fetch the most up-to-date information and let the user know that.
Get current time in a specific timezones
Adds file contents to the staging area
List Git branches
Switches branches
Records changes to the repository
Critical: Git tool descriptions are 7 - 50 characters, far below the 194-char baseline. Examples: 'Shows the working tree status' (29 chars), 'Shows changes in the working directory that are not yet staged' (62 chars), 'Records changes to the repository' (32 chars). LLMs cannot determine when to select these tools or distinguish between them without fuller context. The descriptions do not answer: What does this tool do? When should I use it instead of a similar tool?
Critical: Most parameters across git tools lack descriptions. Examples: git_diff has 'target' param with no description (what is a valid target? branch name? commit hash? tag?), git_commit 'message' has no description, git_add 'files' has no description (should it be an array of paths? glob patterns?). Parameters named 'repo_path' appear in 14 tools but have no description explaining the expected format or whether it must be absolute or relative.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Creates a new branch from an optional base branch
Shows differences between branches or commits
Shows changes that are staged for commit
Shows changes in the working directory that are not yet staged
Initialize a new Git repository
Shows the commit logs
Unstages all staged changes
Shows the contents of a commit
Shows the working tree status
High: No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in any tool definition. This is a current-spec capability (2026-07-28) that helps LLMs reason about safety, retry semantics, and side effects. git_commit, git_add, git_checkout, git_create_branch, git_reset, git_init are all mutating operations and should be explicitly marked destructiveHint=true or idempotentHint=true for clarity.
High: No error handling or recovery guidance in any tool. Tools do not document what happens on failure or what the LLM should do next. Examples: git_checkout on a non-existent branch, git_commit with an empty message, fetch with an invalid URL, git_diff with a non-existent revision, all fail silently in the definitions provided. Per the rubric, error responses must tell the LLM what to do next with concrete suggestions.
High: Output schemas are not documented in any tool definition. LLMs need to know what fields to expect from each tool so they can plan downstream tool calls and extract the right data. Examples: What does git_status return? (list of files? dict with staged/unstaged sections?) What does git_log return? (array of commits? commit objects with which fields?) What does fetch return? (markdown string? structured object with title, body, metadata?) Without documented output schemas, LLMs cannot reliably chain tools.
Medium: fetch tool has a verbose, redundant description. It contains meta-commentary ('Although originally you did not have internet access, and were advised to refuse and tell the user this, this tool now grants you internet access.') that adds no operational value to the LLM and should be removed. The core information (what the tool does, when to use it) is buried. Keep descriptions focused on function, not history or apologies.
Medium: Time tools (get_current_time, convert_time) have parameter descriptions that are generic and miss key constraints. 'timezone' is described as 'IANA timezone name (e.g., America/New_York, Europe/London). Use local timezone as default if no timezone provided by the user.', but the schema shows timezone is required, not optional with a default. This contradiction will confuse LLMs. Also, no guidance on what happens if an invalid timezone is passed.
Medium: git_branch tool has a 'contains' and 'not_contains' parameter with type ['string', 'null'] but the description says 'Do not pass anything to this param if no commit sha is specified', this is vague guidance. Should state explicitly: 'Optional. If provided, filter branches to those containing this commit SHA. Pass null or omit to list all branches.' The current phrasing is unclear to both humans and LLMs.
Medium: fetch tool accepts 'max_length' with exclusiveMinimum 0 and exclusiveMaximum 1000000, but no description explains the unit (characters, bytes?) or what happens if content is longer than max_length (is it truncated? summarized?). start_index is documented as 'useful if a previous fetch was truncated' but fetch does not return a 'truncated' flag or 'next_offset', the LLM has no way to know if it should call fetch again.
Low: git_create_branch parameter 'base_branch' is typed as ['string', 'null'] with no description. Should clarify: 'Optional. Branch name to create from. Defaults to current branch if omitted.' Without this, LLMs may pass both 'main' and 'develop' and be uncertain which takes precedence.