Loading ToolBench
AI-powered sales intelligence system that researches target accounts and identifies sales opportunities by matching a seller's product catalog to customer needs. Multi-agent research workflow with real-time progress streaming, human-in-the-loop feedback, and LangGraph-based orchestration.
This server has 14 tools with mixed quality. Most tools have descriptions (good), but parameter schemas are incomplete or missing for many. Tool naming is generally clear (verb_noun pattern), but several tools lack proper input schema documentation. Error handling guidance is absent. Output schemas are not documented. The server mixes HTTP API endpoints with CLI commands, creating inconsistency. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Average tool score: 42/100.
Permanently stop and discard a research workflow. Unlike /stop which preserves state for resumption, this endpoint completely removes the research - it will NOT appear in Previous Sessions and cannot be resumed.
Get per-node execution traces for the observability panel. Returns timing (start_time, end_time, duration_ms) and a state summary for each agent node that has started or completed in this thread. Used by the frontend trace panel when a user clicks on an agent node.
Get the formatted research report. Returns the markdown report generated by the coordinator.
Get the current state of a research workflow. Returns all collected signals, opportunities, risks, and progress.
Health check endpoint. Returns the service status and version.
List all previous research runs. CLI command to show all research runs stored in checkpoint database.
Output schemas not documented. Tools like get_research_state, get_report, get_node_traces return data but LLMs cannot see what fields to expect. This forces LLMs to guess at response structure and breaks downstream tool chaining.
No tool annotations despite clear risk levels. discard_research is DESTRUCTIVE but lacks destructiveHint. stop_research is REVERSIBLE but lacks idempotentHint. get_* tools are READ_ONLY but lack readOnlyHint. LLMs cannot distinguish safe from dangerous operations.
Error handling guidance missing. No tool describes what errors can occur, how to recover, or what the LLM should do next. E.g., submit_feedback does not explain what happens if thread_id is invalid or feedback text is malformed.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
List all research threads. Returns summary information for all known research workflows.
Start new research on a company. CLI command to initiate a new research workflow for an enterprise account.
Resume interrupted research. CLI command to resume a paused research workflow by thread ID.
Index product catalog for a seller company. CLI command to index product catalog for semantic matching. This must be run ONCE before using the research command with a seller. Products can be loaded from built-in catalog, JSON file, web page URL, or text/Markdown document.
Start a new research workflow. This endpoint initiates a research workflow and returns immediately. The workflow runs in the background. Use the /stream endpoint to receive real-time updates, or poll /state for current status.
Stop a running research workflow. Stops the workflow gracefully, preserving any data collected so far.
Stream real-time workflow updates via Server-Sent Events (SSE). Connect to this endpoint to receive live updates as agents work: node_started, node_completed, state_update, waiting_human, complete.
Submit human feedback on research results. Feedback options: 'approved' or 'looks good' to complete the workflow, 'dig deeper on X' to re-run gatherer, 'find other products' to re-run identifier, 'confidence seems off' to re-run validator. The workflow will resume in the background.
Inconsistent tool interface. HTTP API tools (start_research, stream_research) and CLI tools (research, resume, list_runs, setup_catalog) are mixed in the same tool list. CLI tools lack proper MCP registration and cannot be called remotely. This violates single-responsibility and composability.
Parameter descriptions lack format/constraint details. E.g., research_depth enum is documented but no description explains what 'quick' vs 'standard' vs 'deep' means in terms of time or coverage. feedback parameter in submit_feedback lacks examples of valid feedback strings.