Loading ToolBench
An MCP server exposing WhatsApp messaging, web search, document reading, system stats, and folder organization tools with Gemini AI integration
The Narad WhatsApp Agent has 4 tools with basic schemas and descriptions, but significant quality gaps prevent production readiness. All tools have descriptions and input schemas present, but descriptions are minimal (10-60 chars), parameter documentation is sparse, output schemas are undocumented, and error handling lacks recovery guidance. The tools are functional but fall well short of production-grade patterns from the 54 Agentic Tool Patterns. No tool annotations (readOnlyHint/destructiveHint/idempotentHint) are declared. Per-tool analysis below.
Gets local system CPU and RAM usage stats.
Reads content from a PDF or DOCX file inside the data/ folder.
Performs a 100% free web search using DuckDuckGo.
Sends a WhatsApp message via Twilio.
Output schemas are completely undocumented across all 4 tools. LLMs cannot plan downstream operations or extract structured data from results.
Tool descriptions are extremely brief (10-60 chars), missing WHEN to use the tool and WHAT it returns. Baseline for production tools is 194 chars. Example: get_stats is only 'Gets local system CPU and RAM usage stats.', no guidance on when an LLM should call it vs alternatives.
Parameter descriptions are minimal or missing context. 'query' for search_web lacks format/length guidance. 'file_path' for read_doc does not specify 'must be inside data/ folder' or acceptable formats. 'message' for send_whatsapp has no length limits or formatting constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. send_whatsapp is destructive/non-idempotent but not annotated, agents cannot reason about retry safety or irreversible consequences.
Error handling is generic. Tools return free-text error messages ('Search Error: {e}', 'Doc Reader Error: {e}') without recovery guidance. Per pattern:recovery-guide, errors must tell LLM what to do next (retry, lookup, ask user, etc.).
send_whatsapp accepts a 'to_number' parameter but no validation or sanitization is documented. Phone numbers require formatting (country codes, '+' prefix). Undocumented format invites LLM hallucinations.
read_doc accepts file_path but no enumeration of allowed paths (e.g., only within data/ folder). Implementation restricts to data/ folder but this security boundary is not exposed in the schema or description. Agents could attempt to read arbitrary files.
search_web returns unstructured strings (e.g., '[1] Title: body (Link: url)\n\n[2]...'). Per pattern:response-shaper, tools should return typed objects with fields (title, body, link, index) so LLMs can reason about and extract results without text parsing.
read_doc hardcodes max 5 PDF pages extracted. This limit is not exposed in parameters or documented in the schema. LLMs cannot control extraction scope, and the truncation may silently lose critical document content.