Loading ToolBench
MCP server for ICP Fit Scorer. Scores a company against your ideal customer profile with weighted signals via Apify. Returns a 0 to 100 score, a tier, and a per-signal breakdown. Clay-ready output.
Single tool 'score_icp_fit' with comprehensive schema and strong descriptions. Tool name is verb-noun (score_icp_fit) which is clear. Description is well-written (240+ chars) explaining WHAT (scores against ICP), WHEN (define ICP with template/config/description), and prerequisites (APIFY_TOKEN, credits). Extensive input schema with 40+ parameters, nearly all described. Annotations present (readOnlyHint, idempotentHint, openWorldHint). Schema uses Zod with proper type definitions. However, some parameters accept string representations of booleans ('true'/'false') and numbers (numeric strings) that are coerced at runtime, this is intentional for Clay compatibility but adds cognitive load. Output schema is NOT explicitly documented in the source (tool description mentions return fields but no formal output schema definition visible). Error handling guidance is minimal, tool relies on Apify actor's error responses. No explicit recovery patterns or actionable error messages documented.
Score a company against your ideal customer profile (ICP) using weighted signals. Returns a 0 to 100 icp_score, an A to D icp_tier, and a per-signal breakdown as a flat, Clay-ready JSON row. Define your ICP with a prebuilt template, a JSON scoring_config, or a plain-English icp_description (which requires llm_api_key). Read-only; requires an APIFY_TOKEN and consumes Apify credits per call.
Output schema not explicitly documented. Tool description mentions return fields (icp_score, icp_tier, per-signal breakdown) but no formal JSON Schema or TypeScript interface for the response is visible in source code. LLMs cannot plan downstream transformations or validate response structure.
String-coerced parameters reduce clarity. Parameters like gtm_hiring_signal, gtm_role_count, uses_hubspot, uses_salesforce, uses_clay, seq_tool_detected, crm_detected, headcount, revenue_estimate, latest_funding_amount accept string values that are coerced to boolean/integer at runtime. While documented as intentional for Clay compatibility, this violates type safety and forces LLMs to reason about coercion. Better pattern: accept native types in MCP, perform coercion in the adapter layer.
Error handling lacks recovery guidance. No documented error responses or recovery patterns. If Apify token is invalid, if company domain is malformed, if API call times out, the tool does not specify what error the LLM will see or how to recover. Agents need actionable error messages.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Mutually exclusive parameters not clearly documented. Parameters template, scoring_config, and icp_description are mutually exclusive alternatives, but the descriptions only hint at this ('Alternative to X or Y'). Clearer docs needed: 'Exactly one of template, scoring_config, or icp_description must be provided.'