icp-intelligence-mcp

ICP Scoring Model

icp_scoring_model

Read-only

Helps you decide which leads are worth a seller's time. You give the criteria that matter, how important each one is and, if you know it, what goes with success. You get a lead scoring template: example point weights set by importance level, example points for each value you list, a scorecard and tier bands to adjust, with sector notes when your inputs name a supported sector. Your success pattern is matched to your criteria; it does not set the weights. Ask for held-back test counts and the pre-agreed stop rule when a model has been tested.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "icp_scoring_model"
  }
}

Input Schema

Name	Required	Description
`company`	No	Optional: your company or product name, so the answer can name it
`held_back_test`	No	Optional results on deals held back before tuning. Ask for the counts and the stop rule set before the test. A missed rule holds the scoring model; do not tune on this set.
`product_category`	No	Optional: what you sell, as a product category, so the scoring notes use your sector
`scoring_criteria`	No	Criteria for scoring with importance levels
`success_correlation`	No	What correlates with success? (e.g., "deals with VP Sales champion close 2x faster")
`correlation_direction`	No	Optional confirmed direction of the success pattern. Ask the user whether the named values correlate with better or worse outcomes before filling this. Overrides word reading; unknown withholds a top-points recommendation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 1, 2026

addedInput schema / properties / correlation_direction

Added value: +{
+  "description": "Optional confirmed direction of the success pattern. Ask the user whether the named values correlate with better or worse outcomes before filling this. Overrides word reading; unknown withholds a top-points recommendation.",
+  "enum": [
+    "positive",
+    "negative",
+    "unknown"
+  ],
+  "type": "string"
+}

addedInput schema / properties / held_back_test

Added value: +{
+  "description": "Optional results on deals held back before tuning. Ask for the counts and the stop rule set before the test. A missed rule holds the scoring model; do not tune on this set.",
+  "properties": {
+    "maximum_non_win_pass_percent": {
+      "maximum": 100,
+      "minimum": 0,
+      "type": "number"
+    },
+    "minimum_win_pass_percent": {
+      "maximum": 100,
+      "minimum": 0,
+      "type": "number"
+    },
+    "non_wins_passing": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "non_wins_tested": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "wins_passing": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "wins_tested": {
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "wins_tested",
+    "wins_passing",
+    "non_wins_tested",
+    "non_wins_passing",
+    "minimum_win_pass_percent",
+    "maximum_non_win_pass_percent"
+  ],
+  "type": "object"
+}

First observedOct 17, 2026

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: sector notes appear only when inputs name a supported sector, the success pattern is matched to criteria but explicitly does not set the weights, and a missed stop rule on held-back data holds the model rather than permitting tuning.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The 'You give ... You get ...' framing front-loads inputs and outputs efficiently and every sentence maps to a real behavior. It is slightly prose-heavy and the closing sentence about held-back tests could be tightened, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With six parameters, a nested object and no output schema, the description compensates well by enumerating what the caller receives (weights, points, scorecard, tier bands, sector notes). The main residual gap is that the structure expected inside scoring_criteria values and criterion is left entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already carries the parameter documentation and baseline 3 applies. The description adds a little relational meaning (success_correlation is matched to scoring_criteria but does not drive weights), yet adds nothing about scoring_criteria structure, importance levels, or the held_back_test sub-fields beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb-and-output pair: given criteria, importance weights and an optional success pattern, it returns a lead scoring template with example point weights, points per value, a scorecard and tier bands. That is clearly distinct from sibling tools such as icp_gap_analysis or account_prioritization, though it never names a sibling to contrast against.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: you invoke it when you need a scoring model built from ICP criteria. Two useful in-flow instructions are given ('Ask for held-back test counts and the pre-agreed stop rule when a model has been tested' and 'Ask the user whether the named values correlate...'), but there is no explicit when-to-use versus the eight sibling ICP/prioritization tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All icp-intelligence-mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.