Loading ToolBench
Local MCP server with calculator and file operation tools
This server has 18 tools with complete input schemas and descriptions for all tools. Naming follows a consistent verb_noun pattern (calculator_*, file_*) which is strong. Descriptions are present and range from 43-119 characters, meeting the 10-1024 character baseline. However, several categories of tools lack the sophistication expected of production systems: (1) Calculator tools are trivial mathematical operations without stated error bounds, precision expectations, or examples of when to use them; (2) File operations lack per-operation error recovery guidance and confirmation patterns for destructive operations; (3) Parameters generally have descriptions but many lack examples of valid inputs or constraints beyond basic type info; (4) Output schemas are inferred from implementation but not explicitly documented in the tool definitions themselves. The server demonstrates competent basic patterns but falls short of the nuance required for A-grade tools, descriptions are functional but not LLM-optimized for decision-making.
Add two numbers together and return the result
Calculate cosine of an angle
Divide first number by second number and return the result
Calculate logarithm of x with specified base (default: natural log)
Multiply two numbers together and return the result
Calculate base raised to the power of exponent (base^exponent)
Calculate sine of an angle
Destructive operations (file_delete, file_write, file_append) lack confirmation or dry-run patterns. No mention of pre-flight validation or recovery guidance. An agent could destructively overwrite or delete critical files without any safeguard.
Error handling in call_tool() catches generic exceptions (ValueError, FileNotFoundError, FileExistsError) but does not provide recovery guidance to the LLM. For example, FileNotFoundError just logs 'File not found', it should suggest alternative paths or list available files. This violates the recovery-guide pattern.
Calculator tools lack precision/tolerance statements and error bounds. Division by zero is not mentioned; sqrt and log constraints (non-negative input for sqrt, positive for log) are mentioned in parameter descriptions but not in tool descriptions. An LLM does not know whether 1/0 will fail gracefully or crash.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Calculate the square root of a number
Subtract second number from first number and return the result
Calculate tangent of an angle
Append content to the end of an existing file. Creates the file if it doesn't exist.
Create a new file with given content. Fails if the file already exists.
Delete a file. Fails if the file doesn't exist or is a directory.
Check if a file exists at the given path
List files in a directory with optional glob pattern matching
Read the complete contents of a file. File path must be relative to workspace root.
Read specific lines from a file. Useful for large files or when you only need part of the file.
Write content to a file, creating it if it doesn't exist or overwriting if it does. Creates parent directories as needed.
Tool descriptions for calculator operations do not state when an LLM should use them vs. doing the calculation inline. A capable LLM might reason that simple arithmetic is faster and cheaper to do in-prompt than to call a tool. Descriptions should hint at use cases (e.g., 'Use this for precise scientific calculations requiring high floating-point accuracy beyond LLM reasoning').
Output schemas are not documented in tool definitions. The call_tool handler returns JSON serialized results, but the tool definitions do not declare what fields or structure to expect. LLMs cannot predict the shape of results without seeing schema documentation in the tool registration.
file_list does not paginate or limit results. If a directory contains thousands of files, the tool will return all of them, potentially exhausting the context window. The description should state a result limit and explain how to iterate through large directories.
Parameters accept string encodings (e.g., utf-8, latin-1) without validation or constraint. An LLM could pass 'invalid-encoding' and cause the tool to fail. Encoding should be an enum or validated with clear error messaging.