Loading ToolBench
MCP server providing essential day-to-day tools for data analysts and researchers
This server has basic tool definitions with descriptions and some parameter documentation, but falls short of production quality in several critical areas. Tool naming is acceptable (verb-driven: execute_, list_, describe_, get_), but parameter schemas are incomplete, output schemas are undocumented, and error handling lacks recovery guidance. The descriptions are present but generic, averaging ~120 characters and lacking LLM-optimized clarity about WHEN to use each tool. Parameters lack constraints (enums, ranges, format specs), and several tools return raw API responses without shaping for agent readability. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The server implements 5 tools across two distinct domains (ClickHouse + GitHub), but composition guidance is absent, agents must infer the sequencing of e.g. list_databases() → describe_table() → execute_sql_query().
Get the schema of a specific table in the ClickHouse database. Args: table_name: Name of the table to describe Returns: Tab-separated text containing the table schema information
Execute a SQL query on the ClickHouse database. Args: query: SQL query string to execute against ClickHouse Returns: Query results as tab-separated text if successful, or error message if query fails
Get detailed information about a specific PR. Args: repo_url: GitHub repository URL or owner/repo format pr_identifier: Either PR number or PR URL Returns: JSON string containing detailed PR information, or error message
Get list of PRs from the last N days. Args: repo_url: GitHub repository URL or owner/repo format days: Number of days to look back (default: 7) Returns: JSON string containing list of PR information, or error message
List all databases in the ClickHouse server. Returns: Tab-separated text containing the list of databases
Output schemas completely undocumented across all tools. Descriptions mention 'tab-separated text' or 'JSON string' but do not specify field names, types, or structure. Agents cannot plan downstream operations or extract required data without guessing. This violates pattern:response-shaper and forces LLMs to parse unstructured text, wasting tokens and increasing hallucination risk.
Parameter constraints missing across all tools. Numeric parameters (days) lack min/max bounds. String parameters (repo_url, table_name, pr_identifier) lack format specs, regexes, or enum values. This invites LLMs to pass invalid values (e.g., days=-1, pr_identifier='foobar') and forces validation errors without self-correction guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Error handling provides no recovery guidance. All tool descriptions mention 'or error message if query fails' / 'or error message' without specifying what errors are possible, whether they are retryable, or what the LLM should do next. This violates pattern:recovery-guide and leaves agents stuck when failures occur.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are completely absent. All tools in this server are read-only, but this is not explicitly declared in the tool definition. Agents have no way to know which tools are safe to retry or which might have side effects.
No composition guidance. Descriptions do not explain tool sequencing (e.g., 'Call list_databases() before describe_table()' or 'Call get_github_prs() then get_github_pr_details() for full info'). This forces agents to discover workflow through trial and error, wasting tokens and context.
GitHub tools require GITHUB_TOKEN environment variable but this dependency is not surfaced in the tool description or parameter list. Agents have no way to know the token is required, and will fail with cryptic auth errors instead of a clear message like 'GitHub token not configured. Set GITHUB_TOKEN environment variable.'
Parameter descriptions lack format specs and examples. 'repo_url' accepts 'GitHub repository URL or owner/repo format' but no enum or regex pattern is provided. Agents must guess whether to pass 'https://github.com/user/repo', 'user/repo', or 'repo'. Same issue with 'pr_identifier' (number vs URL format ambiguous).