Loading ToolBench
MCP server that exposes the Apollo.io API functionalities as tools
The server provides 5 tools with reasonable descriptions and schemas, but has significant gaps in parameter documentation, output schema completeness, and error handling guidance. All tools are read-only and well-scoped, but descriptions could be more LLM-optimized and parameter constraints are often missing. Naming conventions are acceptable but some tools have generic patterns (e.g., 'organization_enrichment' could be 'enrich_organization'). Schemas are present for most tools but lack explicit output documentation and validation constraints.
Use the Organization Enrichment endpoint to enrich data for 1 company. https://docs.apollo.io/reference/organization-enrichment
Use the Organization Job Postings endpoint to find job postings for a specific organization. https://docs.apollo.io/reference/organization-jobs-postings
Use the Organization Search endpoint to find organizations. https://docs.apollo.io/reference/organization-search
Use the People Enrichment endpoint to enrich data for 1 person. https://docs.apollo.io/reference/people-enrichment
Use the People Search endpoint to find people. https://docs.apollo.io/reference/people-search
Output schemas not documented. Tools return `Optional[dict]` with no specification of what fields agents should expect. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
Parameter descriptions lack constraint specifications. For example, 'page' and 'per_page' have no min/max values, 'organization_num_employees_ranges' provides format guidance but no validation rules, and enum parameters (e.g., 'person_seniorities') have long descriptions but no explicit enum constraint in schema.
No error handling guidance. Tools provide no documentation about failure modes (API rate limits, invalid IDs, missing data) or recovery steps. LLMs cannot determine whether to retry, fallback, or inform the user.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
organization_enrichment has minimal parameter set (only 'domain' required). No schema shows that this tool returns organization data, and descriptions do not indicate what enrichment entails (company metadata? funding? headcount?). Generic input.
organization_job_postings has a bare string parameter 'organization_id' with no wrapper schema. Input is not wrapped in a query object like other tools, breaking consistency and making it harder for LLMs to reason about parameter structure.
No pagination limit enforcement documented. people_search and organization_search accept 'per_page' but lack guidance on maximum result size, default behavior, or how to handle large datasets. Risk of context window exhaustion.
Naming pattern inconsistency. Tools use noun_verb order (e.g., 'people_enrichment', 'organization_search') rather than verb_noun (e.g., 'enrich_people', 'search_organizations'). Production baseline shows 90% of A+ tools use verb_noun, improving LLM disambiguation.