Loading ToolBench
Server provides a single tool (wolfram_alpha_query) with a clearly visible definition in src/wolfram_alpha/server.py. The tool has a name that starts with a verb, a comprehensive multi-section description, and a JSON Schema with type information. However, the schema lacks individual parameter descriptions (the 'input' parameter has no description field), the output schema is not documented, and error handling is present but generic. The extensive formatting rules embedded in the tool description are helpful but would be better served as parameter constraints and examples rather than prose. Tool name is clear and unambiguous. Definition is explicit and visible (not inferred).
Performs a query to Wolfram Alpha. Supports mathematical calculations, scientific questions, data analysis, and more. Formatting Rules: 1. Use natural language or simplified keywords: - Example: "France population" instead of "how many people live in France" - Example: "10 densest elemental metals" instead of "what are the 10 densest metals" 2. Mathematical Notation: - Use * for multiplication: 6*10^14 (NOT 6e14) - Use proper Markdown for formulas: - Standalone: $$\n[expression]\n$$ - Inline: \( expression \) - Use single-letter variables with optional integer subscripts: n, n1, n_1 - Use named physical constants: 'speed of light', 'gravitational constant' 3. Units and Constants: - Include space between compound units: "Ω m" (NOT "ohm*meter") - For equations with units: - Solve without units first - Exclude counting units (e.g., books) - Include genuine units (e.g., kg) 4. Handling Ambiguous Queries: - If a result is not relevant, check for multiple 'Assumptions' - If available, choose the most relevant assumption - Re-send the exact same query with the 'assumption' parameter - Only simplify or rephrase if no relevant assumptions are provided
Input parameter lacks description in schema. The 'input' parameter in inputSchema has no 'description' field, violating pattern:tool-description which requires every parameter to have a description explaining what it controls.
Output schema is not documented. The tool returns TextContent with unspecified structure. LLMs need to know what fields to expect in the response to plan downstream tool calls and extract relevant data (pattern:tool, pattern:response-shaper).
Formatting rules embedded in description as prose rather than constraints. The lengthy 'Formatting Rules' section (1-4) should be expressed as JSON Schema enums, patterns, and examples, not embedded prose that LLMs may not follow precisely.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Error handling lacks recovery guidance. While McpError exceptions are raised for HTTP 501, 400, 403, and network errors, error messages do not guide the LLM on next steps (e.g., 'The input could not be understood. Please rephrase your query.' lacks specific rephrasing advice). Pattern:recovery-guide recommends actionable recovery steps.
No parameter constraints for 'input' field. The input parameter accepts free-form strings with no min/max length, regex pattern, or validation hints. This invites hallucinated or malformed queries.