Loading ToolBench
Multi-server MCP chatbot that integrates math operations, web search, and weather services with a LangGraph-based agent
This MCP server provides 25 mathematical and utility tools with basic schema definitions and descriptions. However, there are significant quality gaps across naming conventions, parameter documentation, output schemas, and error handling that prevent this from being production-grade. The math tools (add, subtract, multiply, etc.) have minimal descriptions (10-40 chars) and lack output schema documentation. The naming is inconsistent: 'multiple' should be 'multiply', 'abs_val' should be 'absolute_value', 'nCr' and 'nPr' violate verb_noun convention. Web search and weather tools have better descriptions but still lack structured output schemas and pagination guidance. Error handling is present in some math tools (division by zero, domain checks) but missing from others. No tools declare their output structure, making it hard for LLMs to chain results.
Absolute value of x.
Add to numbers
Ceiling of x.
Cosine of x (radians).
Cosine of an angle in degrees.
Divide two numbers
e**x.
n! for non-negative integer n.
Inconsistent and non-standard tool naming. 'multiple' should be 'multiply' (verb_noun convention). 'abs_val' should be 'absolute_value'. 'nCr' and 'nPr' are acronyms, not action verbs, should be 'combination' and 'permutation'. Naming affects LLM tool selection and understanding.
Majority of math tool descriptions are under 20 characters (add, multiple, subtract, divide, power, exp, floor, ceil). Descriptions lack WHAT the tool does beyond the function name, WHEN to use it, or ANY guidance for LLM selection. Rubric requires descriptions to be 10-1024 chars with context for selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Floor of x.
Greatest common divisor.
Get current weather for a location using WeatherAPI.com.
Least common multiple.
Logarithm of x with the given base (x > 0, base > 0, base != 1).
Multiply two numbers
Combination: n choose r.
Permutation: n P r.
Raise a to the power of b
Round x to `ndigits` decimal places (default 0).
Sine of x (radians).
Sine of an angle in degrees.
Square root of x (x >= 0).
Subtract two numbers
Tangent of x (radians).
Tangent of an angle in degrees.
Minimal web search: - DDGS top results - MarkItDown -> Markdown - Strip links -> plain text - Return up to `max_results` blocks (default 1) `include_content`: - True -> include ~1200 chars per page - False/0 -> just the title (no page fetch) - int -> that many chars per page (cap ~4000)
No output schemas documented for any tool. LLMs cannot determine what fields to expect in responses, preventing proper downstream tool chaining and forcing unnecessary lookup calls. E.g., what does 'add' return? A number? An object with result and metadata?
Parameter descriptions are minimal or missing for simple types. E.g., 'a', 'b', 'x' parameters have descriptions like 'First number' but no guidance on valid ranges, constraints, or context. Rubric requires format, range, and allowed values directly in descriptions.
Error handling is inconsistent. Some math tools (divide, sqrt, log, factorial, nCr, nPr) validate input and raise ValueError with domain explanations. Others (add, sin, cos, tan, floor, ceil) do not validate at all. No tool returns error guidance telling the LLM what to do next or how to self-correct.
web_search tool description mentions 'MarkItDown -> Markdown' and internal processing details that are implementation-specific, not user-facing. Description should focus on what the tool does for the user, not how it does it.