Loading ToolBench
MCP server providing AI-powered question answering, mathematical calculations, password generation, and time utilities
This server has 6 tools with basic definitions but multiple critical gaps. All tools have descriptions (good foundation) and schemas are present, but descriptions are often too generic or lack important context about preconditions and error modes. The `calculate` tool uses dangerous `Function()` evaluation without proper sandboxing. `ask_ai` and `ask_claude` lack explicit error handling guidance for LLM failures. Parameter descriptions are minimal (10-50 chars each) and don't include constraints or examples of valid inputs. No pagination support for tools that might return large results. Tool names follow verb_noun convention (positive), but compositions like `ask_ai` and `ask_claude` are redundant, should be a single `query_ai` tool with a `provider` enum parameter. The `get_docs` tool schema is incomplete in the source (definition cut off), making it unscoreable beyond basic naming.
AI-powered question answering tool that calls OpenAI API
Anthropic Claude AI question answering tool
Mathematical expression calculator supporting basic arithmetic operations and functions
Generates a random password with configurable length and optional special characters
Search the latest docs for a given query and library. Supports langchain, openai, and llama-index.
Returns the current time in both locale string and ISO format
CRITICAL: `calculate` tool uses `Function()` to evaluate untrusted input. Even with regex sanitization, this is a code injection vulnerability. An attacker could craft payloads that bypass the character filter.
Redundant tools: `ask_ai` and `ask_claude` are near-identical. Should be merged into a single `query_ai` tool with a `provider` enum parameter (openai|anthropic|claude). This violates the composition pattern (one tool, one job) and wastes reasoning cycles.
`ask_ai` and `ask_claude` lack error recovery guidance. Descriptions say what they do, not how to recover from API failures (rate limits, quota exceeded, invalid API key). LLMs need explicit recovery hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Parameter descriptions are too terse (10-30 chars). E.g., 'Additional context for the question' lacks guidance on format, length, or when to use. Following the rubric baseline (72 chars avg), expand to 'Optional context or background info (e.g., domain, recent events). Omit if the question is self-contained.'
`get_time` tool has empty input schema and minimal description (50 chars, below 72-char baseline). Add: 'Returns the current date and time in both locale-specific and ISO 8601 formats. Use this when the user asks for the time or to timestamp operations.'
`get_docs` source code is truncated; schema and full description are not visible in the provided source. Tool registration cannot be verified. This tool scores 0 on schema and cannot exceed 40 overall (pattern: inferred tool cap).
No output schemas documented. Tools return `content: [{type: 'text', text: '...'}]` but LLMs are not told what structured fields to expect. E.g., `ask_ai` should document that it returns a single text field with the AI's response, suitable for display.
No pagination support. If `get_docs` returns many results, no limit or page parameter is visible. Tools should support `limit` (default 20, max 100) and `offset` or `cursor` to prevent context explosion.
API credentials (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `SERPER_API_KEY`) are read from environment variables, good. However, error messages sometimes return raw API errors which could leak service details. Scrub error messages to be user-safe.