Loading ToolBench
Multi-tool MCP server with expense tracking, GitHub integration, and AI client support. Includes FastMCP-based servers for expenses and GitHub operations.
This server exposes 8 tools across two unrelated domains (expense tracking and GitHub operations). While schemas are present and mostly complete, descriptions are inconsistent and often generic. Most tools lack guidance on when to call them vs. similar tools, and parameter descriptions are minimal. The 'say_hello' tool is a placeholder. Error handling is absent from all tool definitions. The server mixes concerns (expenses + GitHub) without clear composition boundaries. Output schemas are not documented. Most tools fall in the 40-55 range due to generic descriptions and incomplete parameter guidance.
Add a new expense entry to the database.
Create a new issue in a repository
Get details of a specific repository
List expense entries within an inclusive date range.
List open issues in a given repository
List public repositories for a given GitHub username
Returns a greeting message.
Descriptions are generic and lack actionable context. Most descriptions (e.g. 'List expense entries within an inclusive date range', 'Get details of a specific repository') state WHAT without explaining WHEN to use the tool, dependencies, or how it differs from related tools. LLMs need explicit selection guidance.
Parameter descriptions are minimal or absent. Many parameters lack descriptions explaining their format, constraints, or allowed values. E.g., 'date' parameter in add_expense has no guidance on format (ISO 8601? MM/DD/YYYY?). 'category' and 'subcategory' lack enum constraints or valid value guidance. LLMs must infer intent from name alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Summarize expenses by category within an inclusive date range.
No output schema documentation. Tool definitions show input schemas but never document what fields the caller should expect in responses. Without this, LLMs cannot plan multi-step chains (e.g., after list_repos returns, what fields are available for the next call?). This violates the response-shaper pattern.
No error handling or recovery guidance. Tool descriptions do not indicate what errors may occur, when to retry, or how to recover (e.g., 'If username not found, try search_users()'). Agents lack guidance on next steps when a call fails.
Unrelated tool domains mixed without clear boundaries. The server exposes both expense-tracking tools (add_expense, list_expenses, summarize) and GitHub tools (list_repos, get_repo_info, list_issues, create_issue) in one server. This violates composition principles, tools should group by responsibility. The say_hello tool is a placeholder.
No pagination or result limits documented. list_expenses and list_repos accept date/username filters but do not specify pagination (limit, offset, page_size) or maximum result counts. Large result sets could blow context windows. Per pattern:paginated-result, tools returning lists must support pagination.
'summarize' tool name is ambiguous. Does it summarize by category, by date, by amount? The description clarifies ('Summarize expenses by category') but the name alone is vague. Rename to 'summarize_expenses_by_category' for clarity.
Parameter 'note' in add_expense is optional but no guidance on typical use (internal memo? audit trail?). Similarly, 'body' in create_issue lacks examples of expected format (markdown? plain text? structured?).