icp-intelligence-mcp

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint and non-destructive, so the safety profile is covered; the description adds genuine behavioral context beyond that — that titles yield hypotheses rather than confirmed authority, that sector-specific roles and questions appear only when inputs name a supported sector, that business_model is inferred from other inputs when omitted, and that confirmed_budget_owner overrides candidate ordering. It does not disclose limits of the sector library or what happens with an unsupported sector, which keeps it off a 5.

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?

Front-loaded with the decision it supports, then a compact input clause, then the output inventory — a sensible order with little waste. The middle sentence is long and carries several nested enumerations, which slightly hurts scannability but every clause conveys real information.

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, and the description compensates by describing the returned artifacts in prose (role placement, concerns, message prompts, influence map, discovery questions, sector augmentation). Combined with full schema coverage and read-only annotations, an agent has everything needed to invoke it correctly and interpret the result.

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 earns above that by clarifying the dependency logic between parameters (business_model read from other inputs, confirmed_budget_owner overriding candidate ordering) and by signaling that a 'supported sector' concept gates part of the output. Those are cross-parameter behaviors the per-property schema text cannot express.

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 opening sentence states a specific decision outcome: 'Helps you decide who else must agree before a deal can close.' It then enumerates exactly what the tool produces — a buying group map with roles placed by title, per-role concerns and message prompts, an influence map, and discovery questions — which is concrete enough that an agent can tell this apart from the ICP and TAM/SAM siblings in the same family.

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 gives clear activation context ('before a deal can close' with 'what you sell, the deal size, the company size, your champion and any stakeholders you know'), which is effectively an input checklist-plus-timing signal. It stops short of naming an alternative tool or stating when not to use it, so there is no explicit routing guidance against the sibling ICP tools.

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), and the description reinforces the closed-world trait in plain language: "works only from what you give and looks nothing up." It also discloses non-obvious output behavior — ties are reported as ties, budget is expressed as the observed ACV range, and sector notes appear only when a supported sector is named — which an agent could not infer from schema or annotations.

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 sentences, front-loaded with the payoff and then input, output, and the closed-world caveat. Every sentence carries information, with only mild density in the long output sentence listing ties, budget, recommendations, and sector notes.

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 and all five parameters optional, the description carries the burden of describing return values, and it does so without needing to restate field syntax. Minor gap: it does not state what happens if customers is empty or whether one input mode is preferred when both are supplied.

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 goes slightly beyond by enumerating the customer attributes in the order the schema defines them and by framing customers and customer_descriptions as alternative input modes rather than separate fields. It also signals that business_model can be inferred from other inputs, matching the schema note.

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 outcome ("decide which customers to go after next") and the mechanism (derive shared patterns from your best customers), plus what is returned: shared patterns, ties, budget range, recommendations, sector notes. It is clearly a pattern-extraction/ICP tool rather than a scoring or prioritization tool, though it never names the near-neighbor siblings like icp_scoring_model or lookalike_signal_generator to draw the boundary explicitly.

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 gives concrete input guidance — supply customers either as a structured list with the seven named attributes or "in your own words" — which is real usage steering. It does not say when to prefer this over icp_gap_analysis, icp_scoring_model, or account_prioritization, so tool selection among 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 cover the safety profile (readOnly, non-destructive, closed-world), so the description's job is to add context, and it does: it enumerates what comes back (a candidate change per input, a draft updated ICP, unnamed roles, loss reasons to tag, CRM pulls) and discloses the win-rate limitation. What it omits is any note on how candidates are derived or how much of the answer is generic versus input-driven.

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 sentences, front-loaded with the decision the tool supports, then inputs, then outputs, then the limitation. The middle output list is dense but each item is a distinct deliverable, so little padding is present.

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, and the description usefully compensates by enumerating the returned artifacts, which is the main completeness risk for this tool. With seven params all documented in the schema, the remaining gap is minor: no guidance on how detailed the input strings should be for good results.

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 restates the four core inputs (current ICP, recent wins, recent losses, market changes) but says nothing about the optional company, product_category, or time_period fields, so it adds no meaning 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?

The description opens with a specific verb and outcome: 'Helps you decide whether your ICP should change after recent wins and losses.' That distinguishes it from siblings like icp_scoring_model or tam_sam_som_calculator, though it never explicitly names an alternative such as icp_gap_analysis, so the differentiation is inferential rather than stated.

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 trigger context is clear ('after recent wins and losses'), and the closing line sets a boundary: 'It does not compute win rates; check each candidate against your CRM.' That tells the agent what this tool will not do, but it stops short of routing to a specific sibling for the quantitative side.

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), 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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by enumerating the return content (aggregated pain points, objections, buying triggers, value realized, champion roles, verbatim quotes, discovery questions, sector notes) and by stating an input limitation. It does not say whether results are deterministic or how quotes are deduplicated, which is minor for a read-only 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?

Four short sentences in a clear order: purpose, input shape, output shape, input exclusion. Nothing is redundant, and the transcript warning is placed at the end where it functions as a guardrail rather than preamble.

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 telling the agent what comes back, and it does so thoroughly. Input constraints and the read-only nature are covered. Slight gaps remain around volume expectations (how many interviews are useful) and output format, which an agent might want before committing to a call.

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 all three parameters are already documented, and the nested note fields are self-describing by name. The description mirrors the schema's field list (customer, role, pain points, buying triggers, value realized, key quotes) rather than adding syntax or format guidance. Baseline 3 applies since the schema does the heavy lifting.

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 resource and goal precisely: it turns per-interview structured notes into ICP-relevant synthesis (pain points, objections, buying triggers, champion roles). It implicitly distinguishes itself from siblings like icp_deep_dive or account_prioritization by centering on customer interviews, though it never names an alternative. The understated verb ('Helps you decide what...') is the only thing keeping this from 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 context is implied well — you supply one structured note object per interview — and one explicit exclusion is given ('It does not take full transcripts; give only the points and quotes you want analyzed'), which is genuinely useful. However, there is no guidance on when to prefer this over sibling tools such as icp_gap_analysis or icp_deep_dive, and no prerequisites or minimum interview count are stated.

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 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.

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.

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.

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.

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.

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.

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

With readOnlyHint, destructiveHint=false and openWorldHint=false already supplied, the annotations cover the safety profile. The description earns credit for the explicit negative capability ('finds no companies or contacts') and for enumerating the shape of the output, plus the default that omitting platforms includes every section. It does not mention permissions, limits, or how the upstream account data is sourced, so it lands at a solid rather than rich level.

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 sentences, front-loaded with the purpose and ending on the most important constraint (no data returned). Almost every clause carries information, though the opening 'Helps you decide how to find' is slightly softer than a direct verb such as 'generates'.

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 seven-parameter tool with a nested object and no output schema, the description compensates well by describing the return values in prose (per-platform criteria and queries, per-trigger signals, keywords). Required versus optional input handling is covered, and the no-data caveat prevents the most likely misuse.

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% and every parameter, including the nested firmographics object, is documented in the schema itself. The description restates those inputs at a high level and adds a light output mapping (one signal per trigger, queries per platform), but introduces no syntax, format, or validation detail beyond the schema — so the baseline of 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 states a concrete purpose: turn ICP inputs (firmographics, technographics, champion titles, triggers) into targeting criteria and per-platform search queries. The closing line 'It writes criteria, not data: it finds no companies or contacts' sharply delimits the output. It never names any of the sibling ICP tools, so an agent gets no explicit differentiation from icp_deep_dive or icp_scoring_model beyond the 'lookalike' framing.

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 conveyed through an input/output contract ('You give ... You get ...'), which implies when the tool fits, and 'optionally' flags which inputs can be omitted. There is no explicit when-not-to-use guidance and no named alternative when the agent wants an ICP audit or scoring versus lookalike signal generation.

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?

Beyond the readOnly/openWorld/non-destructive annotations, it discloses that output is arithmetic on supplied figures rather than market research, that display is USD-only with no invented conversions, that rates are 0-100 percentage points with explicit fraction ambiguity handling, and that omitted rates fall back to labelled example defaults. These are exactly the behavioral traits an agent could otherwise get wrong.

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 and trigger phrases are front-loaded, then sourcing rules, then unit conventions, in a logical order with no filler sentences. Some content (never estimate, USD only, fraction clarification) is repeated from the schema descriptions, which is mildly redundant but reinforces safety-critical rules.

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 calculator with an output schema already defining return values, the description covers the remaining risks: input sourcing, currency constraint, percentage-point convention, and default labelling. Nothing an agent needs in order to invoke or interpret this tool correctly appears to be 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%, so the schema already documents every parameter, including the 0.2-means-0.2% rule and the 30%/3% example defaults. The description largely restates those rules and adds only a general instruction to clarify unlabelled numbers, so it clears the baseline but adds limited meaning 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 and resource ('decide how big your market is, counted bottom up') and names the outputs TAM, SAM, SOM, which separates it from the ICP-centric siblings. It does not explicitly contrast itself with tools like icp_scoring_model or account_prioritization, so the differentiation is implied rather than stated.

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?

Gives explicit trigger phrases ('size my market', 'market sizing', 'how big is my market') and a pre-call checklist: ask what they sell, how many companies could buy, and the annual contract value, and never estimate these. It stops short of naming alternatives or when-not-to-use conditions, so the routing guidance is clear but not exhaustive.

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