Loading ToolBench
An MCP server that provides tools for RAG-based PDF querying, email sending, and basic arithmetic operations. Integrates with OpenAI and LangChain for intelligent document retrieval and answering.
This server has critical gaps in tool definitions across all four tools. While all tools have names and input schemas visible in the code, descriptions are present but lack specificity, and parameter descriptions are minimal or absent. The 'add' and 'get_current_temperature_by_city' tools are trivial demos with hardcoded responses that add no real value. The 'send_email' tool exposes a WRITE operation without any error handling, confirmation, or safety mechanisms. The 'ask_from_pdf' tool has a lengthy multi-line docstring that duplicates parameter documentation already in the schema, wasting tokens. None of the tools have documented output schemas. The server lacks error handling guidance, input validation advice, or recovery patterns. Overall, this reads as a proof-of-concept rather than a production-grade tool suite.
Add two numbers
Query and answer questions from a preloaded PDF document Default: The PDF file is already loaded and indexed — no need to upload anything. Parameters: question (str): The question asked by the user. Returns: str: The answer generated using retrieved context from the PDF.
Get current temperature of a city
Send an email to a given recipient with a subject and message
send_email tool lacks confirmation, dry-run, or any destructive operation safeguards. A WRITE operation with no recovery guidance or retry-classification guidance violates the confirmation-request pattern. Agents should never send emails without confirmation logic.
No documented output schemas for any tool. LLMs cannot infer what fields to expect in responses, breaking downstream tool composition and forcing agents to parse unstructured text or guess field names.
Parameter descriptions are minimal or absent. 'city_name' and 'question' have one-line descriptions; 'a' and 'b' in add() have no description beyond the type hint. LLMs rely on parameter descriptions to infer meaning and valid ranges.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Tool descriptions lack actionable context. 'Add two numbers' and 'Get current temperature of a city' do not explain WHEN to use the tool, WHAT it returns, or how it fits into larger agent workflows. Descriptions should be 50-200 chars and answer: what, when, why, what does it return?
ask_from_pdf has a verbose multi-line docstring that duplicates schema information (Parameters: question, Returns: str) already in the input schema. This wastes tokens and violates DRY principle. The description should be a single concise sentence, not a pseudo-function signature.
get_current_temperature_by_city returns a hardcoded string ('20 degrees celcius') with no error handling. What if the city is invalid? What if the weather service is down? No error-classification or recovery-guide pattern present.
ask_from_pdf tool depends on a preloaded PDF at a hardcoded path (/home/davidntd/...). This is not portable, not configurable, and the error case (PDF missing, corrupted, or empty) is not documented. Tool descriptions must document dependencies and prerequisites.
No input validation. The send_email tool accepts any string for 'receiver', 'subject', 'body' with no validation (email format, length limits, content sanitization). LLMs can pass invalid or malicious input without guidance on constraints.
Trivial demo tools (add, get_current_temperature_by_city) add no production value and clutter the tool list. If this is a development server, consider removing these before deployment. If they are intentional, document why in the server description.