Loading ToolBench
Advanced AI deep research assistant using Mastra's workflows and agent capabilities. Creates an interactive, human-in-the-loop research system that allows users to explore topics, evaluate results, and generate comprehensive reports.
This server has significant gaps in schema clarity and parameter documentation. While most tools have descriptions, they are often generic and lack actionable detail for LLM use. Critical issue: 4 of 9 tools have incomplete or missing input parameter documentation. Tool names are generally clear (verb-noun pattern), but parameter schemas lack proper type definitions for complex nested objects. The server uses Mastra framework conventions but does not follow strict JSON Schema discipline. Several tools (copywriter-agent, editor-agent) have minimal input specs. Vector/search tools have overly complex parameters without clear constraints (e.g., semantic/vector/positionWeight in rerank, are these 0-1? percentages?). Error handling guidance is absent from all tool descriptions.
Advanced document chunking tool supporting multiple formats (text, HTML, Markdown, JSON, LaTeX, CSV, XML) with configurable strategies and runtime context integration. It integrates with LibSQL for vector storage.
Calls the copywriter agent to write blog post copy.
Calls the editor agent to edit blog post copy.
Evaluate if a search result is relevant to the research query
Extract key learnings and follow-up questions from a search result
Get current weather for a location
Search and rerank conversation messages using semantic similarity and configurable weights
Minimal input documentation for agent-proxy tools (copywriter-agent, editor-agent). Only a single string parameter with vague description; no guidance on expected input format, constraints, or output structure.
Numeric weight parameters (semanticWeight, vectorWeight, positionWeight in rerank) lack range constraints (0-1? 0-100?). LLMs will pass arbitrary values without bounds validation.
Complex nested object schemas (vectorOptions, extractParams in comprehensive_chunker, filter in vector_query) lack property-level type definitions. Properties are described as objects but field types are missing or 'object' (ambiguous).
No error handling guidance in any tool description. Tool descriptions do not explain failure modes, recovery steps, or what the LLM should do if a call fails.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Advanced vector search with hybrid filtering, metadata search, and agent memory integration
Scrape and process web content with comprehensive HTML sanitization, markdown conversion, and optional file persistence
Tool descriptions lack context on when to use one tool vs. a similar one. E.g., extract-learnings vs evaluate-result are both given a search result, descriptions don't clarify the difference or help LLM decide which to call.
web-scraper has a WRITE risk but no dry-run or confirmation capability. Destructive operations should support confirmation before execution.
vector_query 'filter' parameter accepts 'Pinecone-compatible MongoDB/Sift query syntax', no schema, no examples, no constraints. LLMs will guess the syntax and likely fail.