Loading ToolBench
MCP server integration for WhatsApp data access and messaging, integrated with the OWL multi-agent framework
The WhatsApp MCP server has only one tool (extract_document_content) with a basic description but critical gaps in schema completeness, parameter validation, and error guidance. The tool name is verb-based (positive), but the description is vague about capabilities and limitations, and the input schema lacks proper type declarations and constraint documentation. No evidence of output schema documentation, pagination support, or structured error handling. The codebase shows the tool is imported from an external CAMEL-AI toolkit rather than being explicitly defined with MCP-compliant registration, which caps confidence in the implementation.
Extract the content of a given document (or url) and return the processed text. It may filter out some information, resulting in inaccurate content.
Search the web using DuckDuckGo search engine
Input schema lacks property types. The 'document_path' parameter has no 'type' field in the JSON Schema, only a description string.
Output schema is not documented. The tool returns Tuple[bool, str] in source code (line: 'Returns: Tuple[bool, str]...'), but the MCP tool definition shows no output schema specification. LLMs cannot plan downstream calls without knowing the structure of returned data.
Description lacks clarity on when to use this tool vs alternatives, and does not guide error recovery. The description says 'It may filter out some information, resulting in inaccurate content', a warning that suggests the tool is unreliable but offers no guidance on what to do when content is missing or corrupted.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Parameter lacks format and constraint documentation. 'document_path' accepts 'local path or URL' with support for 'image, audio files, zip files and webpages, etc.', but no enums, regex patterns, or explicit file type list is provided. LLMs will guess at valid formats.
Error messages in source code (e.g., 'Document not found at path...', 'Error occurred while processing pdf...') are generic and do not guide the agent on recovery steps. Per pattern:recovery-guide, errors must tell the LLM what to do next.
Tool combines multiple concerns (image analysis, Excel extraction, ZIP extraction, webpage scraping, PDF parsing, DOCX conversion, JSON/XML parsing, Python code reading). Per pattern:tool, each tool should do exactly one thing, this violates composition principles and makes the tool hard to reason about.
External dependencies on CAMEL-AI toolkits and third-party libraries (Chunkr, docx2markdown, PyPDF2, etc.) are tightly coupled in the tool implementation. Failures in these dependencies (e.g., Chunkr API down, XML parse error) are not gracefully handled with fallbacks or clear error messages to the LLM.
No pagination or result limiting documented. If a document (e.g., large PDF or webpage) returns thousands of tokens, there is no limit stated in the tool definition, risking context window exhaustion.