Loading ToolBench
Evidence-first company discovery from the public web. Search the public web, crawl company sites, and return ranked leads with source evidence.
ICP Scout has well-structured tool definitions with complete JSON schemas and tool annotations. All 4 tools have descriptions and input schemas with proper types. However, parameter descriptions are sparse or missing entirely, most parameters lack explanatory text beyond their names. The discover_leads and scan_websites tools have complex, overlapping parameter sets that could benefit from clearer dependency documentation. Error handling guidance is absent from tool descriptions. Output schema is partially documented in code but not exposed in tool definitions.
Search the public web, crawl company sites, and return ranked leads with source evidence.
Read one locally saved ICP Scout run by id.
List locally saved ICP Scout runs.
Crawl supplied public websites and score each company against source-backed ICP criteria.
Parameter descriptions missing or minimal. Most parameters (provider, limit, min_score, include, must_have, exclude, locations, technologies, max_pages, verify_mx, allow_private) lack descriptions explaining their purpose, constraints, or expected format. LLMs cannot infer parameter semantics from names alone.
Output schema not documented in tool definitions. The toolRunResult() function shows the response structure (id, query, stats, leads array with company, domain, score, etc.), but this is not exposed in the tool's inputSchema or as a separate outputSchema field. LLMs cannot plan downstream operations without knowing what fields to expect.
No error recovery guidance in tool descriptions. Descriptions do not explain what errors might occur, how to interpret them, or what the LLM should do next (retry, ask user, try alternative tool). Error handling is critical for agent reliability.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
Parameter dependencies undocumented. discover_leads and scan_websites share many filtering parameters (include, must_have, exclude, locations, technologies) but the relationship between them and how they interact is not explained. LLMs may misuse them.
Enum constraints present but descriptions lack explanation. The 'provider' parameter has enum ['searxng', 'brave'] but no description explaining when to use each or what the default behavior is. Descriptions should guide LLM selection.