Scores arrive as columns rather than prose, which is what makes them sortable, thresholdable and comparable across a list. The ways of defining the profile are not equivalent in what they cost you: a template or a scoring_config runs on the Apify token alone, while an icp_description in plain English routes through a model and needs an llm_api_key of your own. Worth knowing before it is wired into a loop: this is read-only and consumes Apify credits on every call, so the cost scales with the list rather than with the profile.
A single-tool scorer that takes a company, applies weighted ICP signals to it, and 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.
- The profile stated whichever way suits: a prebuilt template, an explicit JSON scoring_config with your own weights, or a plain-English icp_description.
- Output shaped for a spreadsheet rather than a paragraph: score_icp_fit returns a flat JSON row, so the score, the tier and each signal land as columns.
- The reasoning available on request: include_explanation adds why the score came out where it did, and fetch_signals controls whether signals are gathered for the company at call time.
- A read-only call: score_icp_fit reads about the company and scores it, and writes nothing anywhere.
An Apify token, supplied as APIFY_TOKEN — each call spends Apify credits. Scoring from a plain-English icp_description additionally needs an llm_api_key for the chosen llm_provider; a template or a JSON scoring_config does not.
One command plus a key — npx -y @mambalabsdev/mcp-icp-fit-scorer, then supply credentials