Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ICP Intelligence MCP Define our ideal customer profile based on top 10 customers."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Deep ICP Analysis with Pattern Detection - 9 tools for ideal customer profiling, market sizing, buyer mapping, and account prioritization.
# Run directly with npx
npx -y @shashwatgtmalpha/icp-intelligence-mcpAdd to your claude_desktop_config.json:
{
"mcpServers": {
"icp-intelligence-mcp": {
"command": "npx",
"args": ["-y", "@shashwatgtmalpha/icp-intelligence-mcp"]
}
}
}Related MCP server: Andru Revenue Intelligence
Tool | Purpose | Primary Output |
| Pattern detection from customer data | ICP profile with attributes |
| Auto-weighted qualification scorecards | Lead/account scoring model |
| Current vs ideal customer comparison | Metric gaps & recommendations |
| Dynamic ICP monitoring | Win/loss pattern trends |
| Extract patterns from interviews | Voice of customer insights |
| Decision dynamics mapping | Buying committee profiles |
| Bottom-up market sizing | Market size with deal targets |
| Platform-specific targeting | Ad platform targeting criteria |
| Multi-dimensional ranking | Prioritized account tiers |
Role | Key Tools | Use Cases |
Founders/CEOs |
| Market sizing, customer definition |
CMOs/VPs Marketing |
| ICP health monitoring |
Product Marketing |
| Buying committee, VOC |
Demand Gen |
| Targeting, ABM |
Sales Ops/RevOps |
| Lead scoring, account tiering |
SDRs/BDRs |
| Account qualification |
Job To Be Done | Recommended Tool |
"I need to define our ideal customer profile" |
|
"I need to create a lead scoring model" |
|
"I need to compare our actual vs ideal customers" |
|
"I need to track how our ICP is changing" |
|
"I need to synthesize customer interview insights" |
|
"I need to map the buying committee" |
|
"I need to calculate our TAM/SAM/SOM" |
|
"I need targeting criteria for ad platforms" |
|
"I need to prioritize our target accounts" |
|
This MCP is included in these user-focused Agent bundles:
Agent Bundle | Tools Count | Best For |
🎯 Founder GTM Copilot | 10 tools | Founders, early-stage CEOs |
📞 SDR Toolkit | 8 tools | SDRs, BDRs |
🎯 Product Marketing Engine | 12 tools | PMMs |
📊 Demand Gen & Ops | 10 tools | Demand gen, marketing ops |
💼 Account Executive Deal Desk | 12 tools | AEs, account managers |
icp_deep_dive)Detect patterns from customer data to define ICP attributes.
Inputs:
Parameter | Required | Description |
| ✅ | Description of current customers |
| ❌ | Characteristics of top customers |
| ❌ | Industry context |
Output: ICP profile with firmographics, technographics, behavioral signals, and champion characteristics.
icp_scoring_model)Generate auto-weighted qualification scorecards.
Inputs:
Parameter | Required | Description |
| ✅ | Key ICP characteristics |
| ❌ | Win/loss data for weighting |
| ❌ | lead, account, opportunity |
Output: Weighted scorecard with tiers, thresholds, and implementation guidance.
icp_gap_analysis)Compare current customers to ideal profile.
Inputs:
Parameter | Required | Description |
| ✅ | Current customer characteristics |
| ✅ | Target ICP definition |
| ❌ | Metrics to compare (ACV, retention, etc.) |
Output: Gap matrix, metric comparison, recommendations for ICP refinement.
icp_evolution_tracker)Monitor ICP changes over time.
Inputs:
Parameter | Required | Description |
| ✅ | Past customer/deal data |
| ❌ | Analysis timeframe |
| ❌ | Recent win/loss trends |
Output: ICP drift analysis, emerging segments, recommended adjustments.
icp_interview_synthesizer)Extract patterns from customer interviews.
Inputs:
Parameter | Required | Description |
| ✅ | Interview transcripts or notes |
| ❌ | discovery, win, loss, churn |
| ❌ | Specific areas to analyze |
Output: Pattern themes, quotes, ICP refinement recommendations.
buyer_group_analyzer)Map buying committee decision dynamics.
Inputs:
Parameter | Required | Description |
| ✅ | Your product/service |
| ✅ | SMB, mid-market, enterprise |
| ❌ | simple, moderate, complex |
Output: Committee map (champion, economic, technical, user, blocker) with engagement strategies.
tam_sam_som_calculator)Bottom-up market sizing with deal targets.
Inputs:
Parameter | Required | Description |
| ✅ | Your product/service |
| ✅ | Market segments |
| ✅ | Price point or ACV |
| ❌ | Target geography |
| ❌ | Available market data |
Output: TAM/SAM/SOM with methodology, assumptions, and quarterly deal targets.
lookalike_signal_generator)Generate platform-specific targeting criteria.
Inputs:
Parameter | Required | Description |
| ✅ | ICP characteristics |
| ✅ | linkedin, google_ads, 6sense, zoominfo, etc. |
| ❌ | low, medium, high |
Output: Platform-specific targeting fields, audience sizes, recommended exclusions.
account_prioritization)Multi-dimensional account ranking.
Inputs:
Parameter | Required | Description |
| ✅ | List of accounts to prioritize |
| ✅ | Scoring criteria |
| ❌ | Available intent data |
| ❌ | Existing relationships |
Output: Tiered account list (Tier 1/2/3) with scoring rationale and engagement recommendations.
MCP | Focus | Tools | Link |
CRAFT GTM | GTM strategy | 8 | |
CRAFT Content | Content creation | 8 | |
IMPACT | B2B positioning | 8 | |
Revenue Enablement | Sales execution | 12 |
This MCP is built on the principle that ICP is dynamic, not static. The best B2B companies continuously refine their ICP based on:
Win/loss patterns
Customer success metrics
Market evolution
Product capabilities
Key Principles:
Data-driven: Ground ICP in actual customer data
Multi-dimensional: Beyond firmographics to behavior
Actionable: Translate ICP to targeting criteria
Iterative: Regular refinement cycles
Shashwat Ghosh - Founder, Helix GTM Consulting
MIT License - see LICENSE for details.
Part of the GTM Helix MCP Suite - AI-powered B2B go-to-market tools
Rank and prioritize accounts using multi-dimensional scoring
| Name | Required | Description | Default |
|---|---|---|---|
| accounts | No | List of accounts to prioritize | |
| prioritization_weights | No | Custom weights (must sum to 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure, but it only says 'rank and prioritize' with 'multi-dimensional scoring.' It does not explain how weights are applied, whether any data is persisted, what the output format is, or how missing values are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It earns its place, though it is brief enough that adding a bit more actionable context would not have made it bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nested input objects, no annotations, and no output schema, the description is incomplete. An agent is not told what the scoring returns, how to interpret the prioritized list, or how to handle unknown fields like an intent_signals value of 0.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all parameters with 100% coverage, including descriptions for account dimensions and the constraint that weights must sum to 100. The description adds little beyond the generic 'multi-dimensional scoring' label, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Rank and prioritize accounts') and the target resource ('accounts'), and it hints at the approach ('multi-dimensional scoring'). It is distinguishable at a high level from the sibling ICP-analysis tools, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of siblings like icp_scoring_model or icp_gap_analysis. There are no prerequisites, exclusions, or contextual triggers, leaving tool selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map buyer group dynamics, influence relationships, and decision-making process
| Name | Required | Description | Default |
|---|---|---|---|
| deal_size | No | ACV range (e.g., "$50K-100K") | |
| product_category | Yes | What you sell | |
| typical_champion | No | Your typical champion role | |
| known_stakeholders | No | Roles you know are involved | |
| target_company_size | No | Company size (e.g., "500-1000 employees") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. The tool likely generates a structured analysis or report, but the description does not state whether it is read-only (e.g., generates insights) or whether it stores or modifies data. It does not disclose what the output includes or any side effects. The description adds some behavioral context (it maps and analyzes), but it does not cover important aspects like output format or mutability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence that is efficient and front-loaded with the core purpose. It avoids unnecessary elaboration. However, it lacks the usage guidance that would make it more helpful, which slightly reduces the score from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description should explain what the tool returns or how the analysis is structured, but it does not. It also does not provide usage context to distinguish it from sibling tools like icp_deep_dive or icp_interview_synthesizer. This is a significant gap for a tool that likely generates complex buyer group insights.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all 5 parameters (product_category, deal_size, typical_champion, known_stakeholders, target_company_size) with clear descriptions. The description does not add significant meaning beyond what the schema provides, apart from implying these parameters are used to map buyer group dynamics. Given 100% schema coverage, the baseline is 3, and the description does not compensate with extra detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose clearly: 'Map buyer group dynamics, influence relationships, and decision-making process.' It identifies the resource (buyer group) and the actions (map dynamics, relationships, process). However, it does not differentiate from sibling tools like icp_deep_dive or icp_interview_synthesizer, which may overlap in function. Without a distinction, an agent could confuse this with related ICP tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention the context in which this tool is appropriate (e.g., for initial buyer group analysis) or when to prefer another tool (e.g., icp_interview_synthesizer for interview data). This lack of usage guidance leaves the agent to infer when it is applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze customer data to detect ICP patterns - firmographics, technographics, buying behavior
| Name | Required | Description | Default |
|---|---|---|---|
| customers | No | List of customer objects with available attributes | |
| product_category | No | What type of product you sell | |
| customer_descriptions | No | Alternative: Describe your best customers in text format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state any side effects (likely a read/analysis operation, but that is implied), does not mention whether it performs clustering, scoring, or just descriptive analysis, and does not indicate the output format (though no output schema exists). The description does not disclose what happens with missing or incomplete data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loads the primary purpose. It uses efficient phrasing to list the key dimensions. No extraneous information is included, though it could have used the space to clarify usage without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, and the siblings indicate a rich functional context (scoring, gap analysis, lookalike generation), the description is under-specified. An agent cannot determine what the output looks like, whether it clusters customers or scores them, or what to do with the results. The input schema is rich but the description does not explain how to leverage the attributes for analysis.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so each parameter has a description. However, the descriptions are minimal and do not explain the relationship between 'customers' and 'customer_descriptions' (e.g., whether they are mutually exclusive, which takes priority). The description of the tool itself lists attributes like 'firmographics', which partially appear in the schema (e.g., industry, size), but does not clarify the exact expected format of customer_descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (analyze) and resource (customer data) and lists specific attributes to detect ICP patterns (firmographics, technographics, buying behavior). However, it does not distinguish this tool from siblings like icp_gap_analysis or lookalike_signal_generator, which may also analyze customer data for ICP insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of the siblings. It mentions analyzing customer data to detect ICP patterns, but does not state exclusions (e.g., when not to use) or alternatives. The input schema offers alternative inputs (customer_descriptions) but the description does not clarify which input to choose based on data availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track how your ICP should evolve based on market changes and data
| Name | Required | Description | Default |
|---|---|---|---|
| current_icp | Yes | Your current ICP definition | |
| recent_wins | No | Description of recent successful customers | |
| time_period | No | Time period for analysis (e.g., "Q4 2024") | |
| recent_losses | No | Description of recent lost deals | |
| market_changes | No | Recent market or competitive changes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates the tool analyzes and tracks evolution, but doesn't disclose whether it generates a report, updates a stored ICP, or just returns analysis. It also doesn't mention any side effects or data requirements beyond the parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It's efficient, though it could add a bit more context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description is somewhat thin. It doesn't explain what the tool returns, how the inputs are weighted, or what 'track' means operationally. Given the sibling tools are similar in domain, more context would help an agent select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all 5 parameters. The description adds minimal meaning beyond the schema—it implies the parameters are inputs to an evolution analysis, but doesn't explain how they combine or what the output looks like. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Track') and resource ('how your ICP should evolve'), which distinguishes it from sibling tools like icp_deep_dive or icp_scoring_model. However, it doesn't explicitly name a sibling or contrast itself, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for market-driven ICP evolution, and the parameter names (recent_wins, recent_losses, market_changes) suggest when to use it. But there is no explicit guidance on when to use this tool versus icp_gap_analysis or icp_deep_dive, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze gaps between current customer base and ideal ICP
| Name | Required | Description | Default |
|---|---|---|---|
| ideal_icp | Yes | Description of your ideal customer profile | |
| target_metrics | No | Target performance metrics | |
| current_metrics | No | Current performance metrics | |
| current_customers | Yes | Description of your current customer base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Analyze gaps' implies a read-only comparison, but the description does not state what kind of output is produced, whether metrics are required, or how the analysis handles missing data. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the tool's primary action and subject, though it sacrifices some informative detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, nested objects, no output schema, and no annotations, so the description is the only source of usage context. It fails to explain what the analysis returns, how optional metrics factor in, or how this tool differs from several close siblings. The description is too thin to fully support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both required parameters and the optional metric objects. The description adds little beyond naming the comparison between current customers and ideal ICP, but the high schema coverage makes this acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyze') and names the resource ('gaps between current customer base and ideal ICP'), making the core purpose clear. It does not explicitly differentiate from siblings like icp_deep_dive or icp_scoring_model, but the gap-analysis framing is distinct enough to be recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus sibling tools, nor are any exclusions or prerequisites stated. The description only says what the tool does, leaving the agent to infer when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract ICP patterns from customer interview notes or transcripts
| Name | Required | Description | Default |
|---|---|---|---|
| analysis_focus | No | What to focus on: pain_points, buying_journey, value_props, all | |
| interview_notes | No | Structured interview notes | |
| raw_transcripts | No | Alternative: Paste raw interview transcripts or notes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'extract', which implies a read operation, but it doesn't disclose whether the tool is read-only, what the output format is, or any side effects. This is a significant gap for a synthesis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It communicates the core function and input type immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 should hint at what the tool returns (e.g., the nature of extracted patterns). It also doesn't mention any prerequisites or limitations. This leaves an agent unsure about the expected output and potential edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a small amount of value by clarifying that interview_notes and raw_transcripts are alternative input methods ('or'), but it doesn't elaborate on parameter semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (extract) on a specific resource (ICP patterns) from customer interview notes or transcripts. It's unambiguous and distinguishes this tool from scoring or deep-dive tools, though it doesn't name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have interview notes or transcripts, but it doesn't explicitly compare to siblings like icp_deep_dive or icp_scoring_model, nor does it state when not to use this tool. The context is clear but not prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create qualification scoring model with auto-weighted criteria based on your success patterns
| Name | Required | Description | Default |
|---|---|---|---|
| product_category | No | ||
| 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") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It does disclose a meaningful behavior—criteria are auto-weighted based on success_patterns—but it does not mention side effects, persistence, return values, or what happens with existing models. The core behavior is present, yet the full behavioral picture is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. The verb, resource, and primary behavior all appear immediately, making the description easy to scan and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and three parameters, the description is too thin. It gives no clue about the expected returned model, which parameters are necessary, or how this tool fits with the surrounding ICP analysis workflow. An agent could call it, but would have to make assumptions about product_category and the resulting output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, leaving product_category undocumented in both the schema and the description. The description reinforces success_correlation ('based on your success patterns') and implicitly references scoring_criteria via 'auto-weighted criteria,' but it adds no concrete semantic detail and does not compensate for the missing product_category guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), resource ('qualification scoring model'), and a distinguishing mechanism ('auto-weighted criteria based on your success patterns'). This clearly separates it from siblings like icp_deep_dive or account_prioritization, which focus on analysis rather than model creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The phrase 'based on your success patterns' hints at context but does not explain when icp_scoring_model is the right choice over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate platform-specific targeting criteria and search queries (generates criteria, not data)
| Name | Required | Description | Default |
|---|---|---|---|
| platforms | No | Platforms to generate criteria for (linkedin, google_ads, 6sense, zoominfo) | |
| buying_triggers | No | Events that trigger buying | |
| champion_titles | Yes | Job titles of your champions | |
| icp_firmographics | No | Firmographic criteria | |
| icp_technographics | No | Technologies your ICP typically uses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds a useful behavioral note: 'generates criteria, not data', which clarifies the output type. However, it does not disclose other behaviors such as output format, any side effects, or whether it makes external calls. This is a minimal but meaningful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action and scope. It is concise, with no wasted words, and directly communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a generation tool given the schema covers all inputs. However, without an output schema or more details on the structure of generated criteria, an agent may be uncertain about how to use the results. The note 'generates criteria, not data' partially addresses this, but more context on the output format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter descriptions, so the description does not need to add parameter details. It adds no extra semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Generate platform-specific targeting criteria and search queries' with an explicit resource. It also distinguishes itself by noting '(generates criteria, not data)', which separates it from data retrieval tools. Among siblings which are all analysis tools, this stands out as a generation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the sibling analysis tools is provided. There is no mention of prerequisites, context, or exclusions. The only hint is that it generates criteria, but no explicit statement of appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate TAM/SAM/SOM using bottom-up methodology from your data (calculation framework, not data source)
| Name | Required | Description | Default |
|---|---|---|---|
| data_sources | No | Where you got your numbers (for documentation) | |
| segment_name | No | Name of the market segment | |
| icp_percentage | No | Percentage that match your ICP (1-100) | |
| average_contract_value | Yes | Your average ACV in dollars | |
| total_potential_companies | Yes | Estimated total companies that could buy (from LinkedIn, industry reports) | |
| year1_market_share_target | No | Realistic Year 1 market share percentage (typically 1-5%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It mentions the calculation framework (bottom-up) but does not explain what happens to the input data (e.g., calculations performed, output format, whether it stores data), nor does it disclose any limitations or assumptions. This leaves the agent unaware of side effects or output expectations beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, a single sentence that front-loads the core purpose (calculate TAM/SAM/SOM) and adds the key qualifier (bottom-up methodology). It avoids redundancy and is directly to the point. The only slight waste is the parenthetical 'calculation framework, not data source', which is useful but could be integrated more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a calculation tool with 6 parameters and no output schema, the description is incomplete. It does not explain the calculation formula, expected output format, or key assumptions (e.g., how icp_percentage factors into SAM estimation). An agent would need to infer much of the operational logic, which is risky for a tool that produces critical market sizing numbers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, each with descriptions. The tool description adds that it uses a bottom-up methodology, which implies certain parameter relationships (e.g., icp_percentage, year1_market_share_target), but does not elaborate on how parameters interact or required units beyond what the schema already provides. The schema does the heavy lifting, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates TAM/SAM/SOM using a bottom-up methodology, specifying the resource (calculator) and action (calculate). It distinguishes itself from sibling tools by focusing on market sizing, though it does not explicitly name a sibling as an alternative. The clarity is sufficient for an agent to understand the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a user needs TAM/SAM/SOM estimation, but it does not provide explicit guidance on when to prefer this tool over siblings like icp_deep_dive or account_prioritization. It lacks a when-not-to-use clause. However, the purpose is clear enough that an agent could infer appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0account_prioritizationbuyer_group_analyzericp_deep_diveicp_evolution_trackericp_gap_analysisicp_interview_synthesizericp_scoring_modellookalike_signal_generatortam_sam_som_calculatorScored across 9 tools
Each tool targets a distinct ICP task—detection, scoring, buyer mapping, TAM/SAM/SOM, lookalike targeting, prioritization, gap analysis, evolution, and interview synthesis. The only mild ambiguity is between icp_deep_dive, icp_gap_analysis, and icp_interview_synthesizer, but their data sources and outputs are described differently enough.
All tool names are lowercase snake_case and mostly follow a descriptive 'domain_topic_action' noun-phrase convention. However, some names use the icp_ prefix while others lead with the object (buyer_group_analyzer, account_prioritization), and there is no consistent verb-object pattern.
Nine tools is an appropriate scope for an ICP intelligence server; each tool covers a meaningful step without redundancy. It sits comfortably in the well-scoped range.
The set covers the full ICP workflow: pattern discovery, scoring, buyer dynamics, market sizing, targeting, prioritization, gap analysis, evolution, and interview synthesis. No obvious dead ends or required missing operations are apparent for an analysis-focused ICP tool.
TAM mapping, company discovery, contact intelligence, and technographics across 65M+ B2B domains.
Sales intelligence for B2B SMEs — lead scoring, ICP fit, CRM enrichment & writeback.
AI sales — prospect discovery, ICP scoring, outreach generation.
Real-time B2B buying signals on your target accounts: funding, hiring, leadership, tech stack.
