icp-intelligence-mcp

Account Prioritization

account_prioritization

Read-only

Helps you decide which accounts to work first. You give your accounts with fit, intent and relationship scores from 0 to 100 and a timing, plus optional weights. You get a ranked list from a weighted score, with a tier for each account, the points its timing earned and the factor that added the most points.

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": "account_prioritization"
  }
}

Input Schema

Name	Required	Description
`company`	No	Optional: your company or product name, so the answer can name it
`accounts`	No	List of accounts to prioritize. Each account: name, fit score (0 to 100), intent signals (0 to 100), relationship (0 to 100), timing (now, soon, later or unknown)
`product_category`	No	Optional: what you sell (for example "spend management software"), used for sector notes. The arithmetic does not use it
`prioritization_weights`	No	Optional custom weights in percent for fit, intent, relationship and timing. A missing weight uses its default (40, 30, 15, 15); the tool does not check that the weights sum to 100

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 1, 2026

changedInput schema / properties / accounts / description

Previous value: -"List of accounts to prioritize. Each account: name, fit_score (0 to 100), intent_signals (0 to 100), relationship (0 to 100), timing (now, soon, later or unknown)"New value: +"List of accounts to prioritize. Each account: name, fit score (0 to 100), intent signals (0 to 100), relationship (0 to 100), timing (now, soon, later or unknown)"

changedInput schema / properties / accounts / items / properties / timing / description

Previous value: -"now, soon, later or unknown (now 100 points, soon 70, later 40; unknown, left out or any other word 50)"New value: +"Buying horizon: now, soon, later or unknown (100, 70, 40 and 50 points respectively). Equivalent phrases are read by clause; denied or conflicting horizons remain unknown. Confirm the horizon with the user."

First observedOct 17, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already establish this is a safe read-only, closed-world computation, so the lower burden applies. The description does add the output shape (weighted score, tier, timing points, top contributing factor), which is real value, but it omits what a tier actually is (thresholds) and never mentions that company/product_category only produce sector notes rather than affecting arithmetic.

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?

Three tight sentences that front-load the purpose, then input, then output. No filler, though the conversational second-person phrasing ("You give ... You get") could be marginally more compact.

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?

There is no output schema, so the description carries the return-value burden and does so adequately, naming the ranked list, tier, timing points and dominant factor. The main remaining gap is the undefined notion of "tier" and the unmentioned sector-note behavior of company/product_category, both minor against a fully documented input 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 documents the 0-100 ranges, defaults of 50, the timing-to-points mapping and the default weights. The description mostly restates these at a higher level ("scores from 0 to 100 ... plus optional weights") without adding syntax or edge-case guidance, so the baseline 3 applies.

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?

"Helps you decide which accounts to work first" names a specific decision and resource, and the second half names the concrete input (fit/intent/relationship scores plus timing and optional weights) and output (ranked list with tier). An agent can tell this is a ranking tool rather than a scoring-model or gap-analysis tool, though it never names the sibling it displaces.

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 only implied by "decide which accounts to work first" and the requirement to supply per-account scores. There is no statement of when to prefer this over icp_scoring_model or icp_gap_analysis, and no prerequisites such as needing inputs already scored.

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.