Loading ToolBench
Natural-language people/company-leads search over the Pearch API
Single tool with minimal schema and description quality. The search_leads tool has a description (74 chars), which exceeds the 20-char floor but falls well below production baselines (194 chars avg). Input schema is present but extremely minimal, only a 'query' string parameter with a brief description. No output schema is documented anywhere in the source. No error handling guidance, no parameter constraints (e.g., query length limits), no indication of what the response structure looks like. The tool name 'search_leads' follows verb_noun convention (good), but the implementation lacks pagination, result limits, or guidance on large result sets. The server code shows authentication logic and caching, but none of these operational details are reflected in the tool definition itself. For an agent using this tool, there is almost no structured information to drive composition or error recovery.
Search for people and company leads using natural language
Output schema completely undocumented. The tool returns results from the Pearch API, but agents have no information about the structure of the response (e.g., fields returned, pagination, total count, nesting). Without this, agents cannot reliably extract data for downstream calls or format responses for users.
Tool description is only 74 characters, below the 194-char production baseline. It states what the tool does ('Search for people and company leads') but does not explain when to use it instead of alternatives, what prerequisites exist (e.g., valid API key), what output format to expect, or any constraints on the query parameter. Insufficient for agent selection and planning.
Input parameter 'query' lacks formal constraints. No enum, min/max length, regex pattern, or description of valid formats. A query could be a full name, company name, email, or a freeform search string, the description does not clarify which. LLMs will guess and send invalid queries.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 59 | - | v1 |
No pagination or result limit documented. If the API returns 1000 leads for 'sales manager', the tool will dump all of them into the context window, wasting tokens and degrading reasoning. Production tools document and enforce reasonable limits (20-50 items) and offer pagination parameters.
Error handling provides no guidance to agents. If authentication fails, the Pearch API returns an error, but there is no indication in the tool definition of what errors are possible, whether they are retryable, or what the agent should do next (e.g., check API key, wait and retry, or report to user).
No documentation of what fields are returned in the response or their types/formats. Agents need this to compose downstream calls. For example, if a lead's ID is returned as 'lead_id' vs 'id', agents must know to pass 'lead_id' to any follow-up tools that reference the lead.