icp-intelligence-mcp

ICP Gap Analysis

icp_gap_analysis

Read-only

Helps you decide whether you are selling to the customers you meant to. You give your current customer base, your ideal customer profile and, if you have them, current and target metrics. You get what the ideal profile has that the current base lacks, metric gaps from your own figures, causes to check and actions that fit your business model, with sector notes when your inputs name a supported sector.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "current_customers": "<current_customers>",
      "ideal_icp": "<ideal_icp>"
    },
    "name": "icp_gap_analysis"
  }
}

Input Schema

Name	Required	Description
`company`	No	Optional: your company or product name, so the answer can name it
`ideal_icp`	Yes	Description of your ideal customer profile
`business_model`	No	Optional: how you charge (software subscription, services, connectivity, per transaction, marketplace, hardware plus software, or investment management). Read from your other inputs when left out
`target_metrics`	No	Target performance metrics
`current_metrics`	No	Current performance metrics
`product_category`	No	Optional: what you sell, used for sector notes
`current_customers`	Yes	Description of your current customer base

Schema Changelog

Changes observed during successful MCP inspections.

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 cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower; the description still adds real value by describing the shape of the answer — profile gaps, metric gaps from your own figures, causes to check, and actions matched to the business model. It also discloses a conditional behavior, that sector notes appear only when inputs name a supported sector, though it never says which sectors are supported.

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?

Two sentences with the intent front-loaded and no filler; the second sentence is a compact input-to-output contract. It is slightly prose-heavy ('You give... You get...') but the parallel structure aids scanning rather than hurting it.

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 seven parameters, nested metric objects and no output schema, the description carries the return-value burden — and it does, enumerating the four output components plus the sector-note condition. The gaps (which sectors are supported, how large an input is expected) are minor for a read-only analytical tool whose schema is fully documented.

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 baseline is a 3. The description restates that current customers, ideal ICP and optional current/target metrics are the inputs, but it adds no meaning beyond the schema for company, product_category, or the metric sub-fields, and the business_model fallback behavior is already documented in the schema.

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 the analysis plainly: it compares a current customer base against an ideal ICP and returns the delta, metric gaps, causes and actions. The 'You give X, you get Y' framing makes the resource and the transformation clear. It does not, however, differentiate itself from close siblings like icp_deep_dive or icp_scoring_model, so an agent must infer which ICP tool to pick.

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?

The opening line implies the situation ('decide whether you are selling to the customers you meant to'), which is genuine usage context rather than pure restatement. But there is no explicit when-not guidance, no prerequisites, and no named alternative among the eight ICP-related siblings, so the agent is left to infer routing.

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.