icp-intelligence-mcp

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (per-account timing points and top-contributing factor), which matters since there is no output schema.

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 dense sentence with the scoring model front-loaded and the output detail trailing after the semicolon. Nothing is redundant, though the sentence is long enough that a reader must parse it carefully.

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 nested-object, zero-required-parameter tool with no output schema, the description covers what the tool produces and the factors that drive ranking, and the schema fully documents inputs. Only the routing context relative to sibling scoring tools is missing.

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%, including the timing point mapping and the 50-default for missing fit/relationship/intent values, so the schema does the heavy lifting. The description only restates that the score is weighted by those four factors and adds no syntax or format detail beyond the schema.

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?

States a specific verb pair (rank/prioritize) and resource (accounts) plus the scoring basis (weighted fit, intent, relationship, timing), which an agent can act on immediately. It does not, however, name or contrast itself with any sibling such as icp_scoring_model, which is the closest alternative.

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 when-to-use, when-not-to-use, or prerequisite guidance anywhere in the description. Given nine sibling tools in the ICP/account space, the absence of routing guidance leaves the agent to infer when this beats icp_scoring_model or lookalike_signal_generator.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuine behavioral context: the response includes role concerns, message prompts, an influence map and discovery questions, and sector-specific roles are appended when inputs name a supported sector. However it never says which sectors are supported, which is the key behavioral unknown an agent would need.

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?

Two sentences, front-loaded with the core action and then the output inventory. Dense but every clause maps to a real capability. The trailing sector clause is slightly vague rather than wasteful.

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 output schema, the description carries the return-value burden and does a fair job by listing the artifacts returned. The gap is the undefined "supported sectors" conditional, which leaves the agent unable to predict or trigger that behavior confidently.

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 every parameter including the enum and the business_model fallback rule is already documented in the schema. The description echoes the champion and stakeholder inputs without adding syntax, format, or format-example detail beyond it. Baseline 3 applies.

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?

States a specific verb ("Map") and resource ("the buyer group for a deal") and enumerates the artifacts produced: roles placed by title, each role's concern and message prompts, an influence map and discovery questions. It is clearly distinct from sibling ICP/account tools. It stops short of explicitly naming which sibling to use instead, so a 4 rather than a 5.

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?

Usage is only implied by the artifact list (mapping stakeholders for a deal). There is no explicit when-to-use, when-not-to-use, or routing to account_prioritization or icp_deep_dive. The sector sentence is a behavioral note about conditional output, not guidance on selection.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description layers on genuine output behavior: ties are reported as ties rather than resolved, budget is reported as a range derived from supplied ACVs, and sector notes are conditional on supported sector inputs. That is real disclosure about how results are produced, though return format/pagination remains unstated.

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?

Purpose is front-loaded in the first sentence, with a second sentence of caveats of genuine value. Slightly dense packing of three behaviors into one sentence, but no filler.

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 read-only analysis tool with no output schema and all-optional parameters, the description covers what the analysis returns (patterns per dimension, tie handling, ACV-range budget, sector notes) and notes that business_model can be inferred from other inputs. Good enough that an agent could call it correctly; only the output shape stays unspecified.

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 baseline is 3. The description adds interpretive meaning beyond the schema — that 'budget' means the ACV range observed in your customers, and sector notes appear only for inputs naming a supported sector — but it doesn't clarify most individual parameters.

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?

Specific verb (Analyze) plus resource (customer data) and an enumerated list of the ICP dimensions it detects (industry, size, deal size, sales cycle, tech stack, triggers, champion roles). That distinguishes it reasonably from siblings like icp_gap_analysis or icp_scoring_model, though it never names which sibling to prefer.

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?

Usage is only implied: you feed it customer data and it surfaces ICP patterns, with 'customer_descriptions' as an alternative input mode. There is no explicit when-to-use/when-not guidance and with eight ICP-related siblings, the agent gets no routing help.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds genuine context beyond them: output is a draft rather than a committed ICP, win rates are deliberately not computed, and CRM data must be supplied/pulled by the user rather than fetched. It stops short of describing output structure or limits.

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 action and its outputs are front-loaded in the first sentence, with the limitation second. It is dense but nearly every clause carries distinct information; the only cost is a long, comma-heavy sentence that could be split for scannability.

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 output schema, the description must carry the return-value burden, and it does so by enumerating the artifact types the agent will receive. Combined with the explicit non-goal (no win rates), an agent knows what to expect and what follow-up work remains, though the shape/format of the draft is unspecified.

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% for all 7 parameters, so the schema already documents each field. The description gestures at the same inputs (wins, losses, market changes, current ICP) without adding syntax, format, or precedence details, so the baseline 3 applies.

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 names a specific verb ('Review how your ICP should evolve') and enumerates concrete outputs: a candidate change per input, a draft updated ICP, unnamed roles, loss reasons to tag, and CRM pulls. That is far more specific than the sibling names alone, though it never explicitly distinguishes itself from icp_gap_analysis or icp_deep_dive.

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?

It implies the use case (reviewing recent wins/losses/market changes to evolve an ICP) and adds one boundary ('It does not compute win rates; check each candidate against your CRM'). However, no sibling alternative is named and no when-not condition is stated, so routing among the many icp_* siblings is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: business_model is inferred from other inputs when omitted, and sector notes are conditionally appended only when the inputs name a supported sector.

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?

One dense, front-loaded sentence that leads with the gap-analysis scope before listing outputs and the conditional sector-note behavior. No filler, though the trailing clause about sector notes slightly crowds the core statement.

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 output schema, the description carries the return-value burden and does so by naming the analysis components (ideal-vs-current deltas, metric gaps, causes, actions, sector notes). Combined with annotations covering the safety profile, an agent has enough to call it correctly, though required-input expectations are left to the schema.

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 baseline is 3, and the description genuinely adds semantics on top by disclosing fallback behavior (business_model 'read from your other inputs when left out') and the conditional sector-notes behavior tied to product_category/inputs.

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?

States a specific verb and resource: 'Analyze gaps between your current customer base and your ideal ICP', and enumerates what the analysis covers (profile deltas, metric gaps, causes, actions). It is clear, though it does not explicitly distinguish itself from near-neighbors such as icp_deep_dive or icp_scoring_model.

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 statement of when to use this tool versus the eight sibling ICP tools, and no prerequisites or exclusions. Usage is only inferable from the phrase 'gaps between your current customer base and your ideal ICP', which is descriptive rather than directive.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: pasted notes are shown back 'shortened' with a structuring template, meaning raw input is never analyzed, and quotes are kept verbatim. That is real operational context an agent needs to set user expectations.

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?

Two sentences with the extraction outputs front-loaded and the important raw_transcripts caveat second, so an agent reads the primary behavior first. The output enumeration is dense but each item is a distinct deliverable; the only mild bloat is the parenthetical aside about shortening.

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 output schema, the description carries the burden of describing results, and it does so by listing the extracted categories plus discovery questions and sector notes. It also disambiguates the two input paths (interview_notes vs raw_transcripts). The omission of any note about analysis_focus being inert is left to the schema, which covers it, so the definition is largely complete for a zero-required-param tool.

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 every parameter (including company, analysis_focus, product_category, and the nested interview_notes fields) is already documented in the schema itself. The description reinforces that analysis consumes structured interview_notes and that product_category drives sector notes, but adds little syntax or semantics beyond what the schema provides. Baseline 3 applies.

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?

States a specific verb ('Extract') and a specific resource ('ICP patterns from customer interview notes'), then enumerates the exact artifacts produced (pain points, objections, buying triggers, value realized, champion roles, quotes, discovery questions, sector notes). The interview-notes resource is inherently distinct from siblings like icp_scoring_model or tam_sam_som_calculator, but no sibling is named, so it falls short of a 5.

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 by clarifying that 'only structured notes are analyzed' and that pasted transcripts are echoed back rather than processed, which is useful selection context. However, it never states when to reach for this tool versus the eight ICP siblings (deep dive, gap analysis, evolution tracker), leaving routing to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: success patterns are matched to supplied criteria rather than setting weights, and sector notes are conditionally added based on the named sector. It doesn't state what the template returns or whether weights are editable.

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?

Two tight sentences with no filler; the creation scope is front-loaded. The second sentence is somewhat dense and the list-like output enumeration reads awkwardly, but nothing is wasted.

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 read-only, zero-mandatory-parameter generation tool with all four params documented and no output schema, the description covers what gets produced and how inputs are consumed. Missing only explicit guidance on how the output differs from the sibling icp_* tools.

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, but the description adds real meaning: importance level drives example point weights, points are generated per listed value, and success_correlation informs criteria rather than weights. This clarifies intended use of two parameters beyond their schema text.

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?

States a specific verb+resource: 'Create a lead qualification scoring template' and enumerates its output parts (criteria, weights, points, scorecard, tier bands). It does not name any sibling tool, so an agent can't tell from this alone when to pick it over icp_deep_dive or icp_gap_analysis.

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?

Usage is implied by the creation framing rather than stated: nothing says when to use this versus the other icp_* siblings, and no prerequisites are given. The only conditional-narrowing sentence ('Sector notes are added when your inputs name one of the supported sectors') describes behavior, not when to select the tool.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds genuine behavioral context beyond that: it clarifies the tool produces criteria rather than fetched data, and that each buying trigger yields its own discrete signal — output-shape information the annotations do not carry.

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?

Three dense sentences with no filler, and the core purpose plus the 'criteria, not data' caveat are front-loaded. The trailing clause about platforms is slightly awkwardly appended but still earns its place.

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 output schema, the description carries the return-value burden and does so partially ('each trigger gets its own signal', 'generates criteria, not data'). It tells the agent enough to call the tool confidently, though the exact output sections are only loosely sketched.

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, but the description goes further by explaining interaction semantics: 'platforms limits the sections' (and all sections appear when omitted), and product_category drives search keywords and sector notes. That adds meaning beyond the field 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?

States a specific verb+resource: generating targeting criteria and search queries from four named input types. The parenthetical '(generates criteria, not data)' sharpens scope well. It does not explicitly distinguish itself from the icp_* siblings, which is the only gap.

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 never says when to choose this over icp_deep_dive, icp_scoring_model, or the other eight siblings. Usage is only inferable from the input list. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnly/non-destructive/closed-world, so the safety bar is low. The description adds real behavior beyond that: it discloses that ICP match rate and Year 1 share have example defaults applied when omitted, and that sector notes are conditionally appended based on inputs. It does not explain the response format, but no output schema exists to lean on.

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?

Two sentences, front-loaded with the core action and method, followed by the one behavioral caveat that matters (sector notes). No padding or repetition of fields.

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 stateless calculation tool with full schema coverage and no output schema, the description covers what it computes, what it is not, and the two conditional behaviors. Only the shape of the returned result is left unspecified, which is a minor gap.

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 eight parameters including the 30% and 3% defaults. The description restates the four driving inputs but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb (calculate) and resource (TAM/SAM/SOM) with the method (bottom-up) and names the exact inputs used in the arithmetic. The parenthetical 'calculation framework, not a data source' cleanly distinguishes it from data-oriented siblings like lookalike_signal_generator and icp_deep_dive.

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 ('calculation framework, not a data source' and the sector-notes condition) but never states when to reach for this versus sibling ICP tools such as icp_scoring_model or account_prioritization. Guidance is inferable but not explicit.

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