impact-mcp

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

Annotations only declare readOnly/openWorld=false, so the description carries the real burden and does well: it discloses the two scoring methods, that the answer self-reports which method was used, the fallback to keyword matching on segment names, and the hard guarantee that it never invents a segment. It stops short of describing the shape or length of the returned ranking and expansion path.

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 purpose, then inputs-to-outputs, then the one guarantee that matters most. Three sentences, heavy parentheticals but every clause (method disclosure, fallback, refusal to invent segments) carries information an agent needs.

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 10-parameter tool with no output schema, the description covers what happens on partial input, what gets computed from which inputs, and the safety boundary, which is the critical missing context. Some detail of the return payload (format of the ranking, units in the TAM/SAM/SOM output) is left implicit.

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 baseline is 3, but the description adds genuine cross-parameter meaning the schema states only piecemeal: that pain + customers + deal size must all be present for the customer-driven ranking, and that market sizing depends only on the figures supplied. This interaction logic helps an agent decide which optional params to bother filling.

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 and resource ('decide which market segment to win first', a 'beachhead choice') and enumerates the exact outputs: ranked segments, TAM/SAM/SOM, a three-year expansion path and an ICP hypothesis. That is far more specific than any of the sibling tools, none of which do market selection, so an agent can route here without ambiguity.

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 clear conditional guidance: segments are required for a recommendation, and customer/pain/deal-size inputs together unlock the customer-based ranking while any subset falls back to keyword scoring. It does not name alternative tools or state explicit when-not-to-use conditions, which keeps it short of a 5.

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 genuine behavioral context beyond that: the output is written 'from your own words, in whole sentences' and includes testable versions, which tells the agent this is a generative drafting tool rather than a lookup.

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 clause, followed by inputs and outputs in a logical order. The long enumeration of optional inputs and deliverables partially duplicates the schema, but every sentence still serves to set expectations about what the agent receives.

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 takes on the burden of describing returns, and it does so thoroughly: full and one-sentence positioning statements, a tagline-to-three-pillars hierarchy, audience variants, objection handling and testing approaches. Combined with annotations covering the read-only profile, an agent has enough to call this 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% with 9 well-documented parameters, including enum explanations for your_sector and business_model, so the schema carries the semantics. The description's input sentence mostly restates the schema's required/optional split and adds no new format or constraint detail, which lands at the baseline.

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+resource: it helps decide a core message and test it, and enumerates the concrete artifacts produced (positioning statement, message hierarchy, audience versions, objection handling). That is clearly distinct from siblings like impact_pinpoint_value or impact_anchor_market, though it never names them 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?

Usage is only implied through the give/get framing ('You give your target customer... You get a positioning statement'). There is no explicit statement of when to choose this over impact_pinpoint_value or impact_anchor_market, and no prerequisites or exclusions 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 this a safe read-only, closed-world operation, and the description adds genuinely non-obvious behavior: it returns completeness scores rather than quality judgments ('Scores measure how complete the inputs are, not how strong the positioning is'), and it forbids fabricating missing facts or proof. It does not discuss determinism, latency, or what happens if required product facts are genuinely unobtainable, which keeps it out of 5 territory.

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, followed by usage, prerequisites, the alternative, and output expectations in a logical order with no filler sentences. The final 'Never invent proof' partially repeats the earlier anti-invention instruction, a small redundancy.

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 ten parameters, two enums, three required fields, and an output schema, the description covers what an agent needs: required preconditions, the sibling alternative, a caveat on interpreting returned scores, and the no-fabrication constraint. Return-value detail is correctly left to the output schema. Nothing needed for correct invocation 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%, so all ten parameters are already documented, including 'leave out if absent' and 'clarify unlabelled numbers'. The description largely restates those same instructions (ask for product/customer/problem, don't use placeholders), adding only the concrete 'Not supplied' placeholder example. Marginal added meaning over 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?

The description states a specific outcome: a full positioning review that decides 'whether your positioning is working and what to fix first', and names the concrete deliverables (completeness scores, supplied proof, positioning draft, next actions). It also distinguishes itself from impact_craft_message. It falls short of 5 only because the opening 'Helps you decide whether...' frames the purpose indirectly rather than stating the operation outright.

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 explicit triggers ('a full positioning review', 'explain why we are different'), a stated prerequisite (gather what the product does, who it serves, the problem it solves before calling), and names the alternative sibling plus the condition that selects it ('for a request only to phrase a message, impact_craft_message also fits'). When-to-use, when-to-use-something-else, and preconditions are all present.

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 adds genuinely non-obvious behavior: focus_phase narrows output to a single step, sector selection injects sector-specific buyer roles, measures and proof points, and unclear input yields a neutral reading.

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 purpose is front-loaded in the first clause and the input/output contract follows in a logical order. The parenthetical enumeration of all six steps is long but earns its place by mapping to the focus_phase enum; the sentence run-on is the only cost.

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 correctly takes on the job of describing returns: step-by-step method, a template or checklist per step, and the sector overlay. The main gap is the unaddressed overlap with the per-phase sibling tools, which leaves an agent with a real selection ambiguity.

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 baseline is 3. The description goes slightly beyond the schema by spelling out what sector actually changes in the output (buyer roles, measures, proof points) and by framing focus_phase as a filter that returns just that step, information the enum alone does not convey.

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 role: deciding which positioning steps to run and in what order, then names the six steps returned. This distinguishes it from the single-phase siblings in spirit, but it never explicitly says when to use this orchestrator versus impact_anchor_market or impact_full_audit, which matters because focus_phase can return exactly what a sibling returns.

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 states the invocation patterns clearly ('you give nothing, or one IMPACT step to focus on and your sector'), which is better than nothing. However, there are no exclusions or rules for choosing between this tool and the seven sibling phase tools, so the agent must infer the boundary itself.

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 genuinely useful behavior beyond that: it enumerates what comes back (role hypotheses, anti-champion warning signs, a development path, and what to give the champion) and explicitly caveats "These are roles to test, not named people," which prevents misreading the output as real contacts. It does not discuss depth of analysis or determinism, keeping it below 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?

Three sentences, front-loaded with the purpose, then inputs, then outputs — a sensible order with no repetition of the title. Some phrasing is conversational ("who inside the buyer will push for you") but it carries meaning rather than 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?

There is no output schema, so the description must explain returns, and it does so thoroughly by listing the role types, anti-champion signals, and the champion development path. Combined with required inputs and the roles-not-people caveat, an agent has everything needed to call it 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 every parameter is already documented in the schema, including the enum for your_sector. The description only restates the parameter list (product, problem, company name, target company type, price point, sector) without adding syntax, formatting, or interaction guidance, so 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 opens with a concrete outcome — "Helps you decide who inside the buyer will push for you" — and then names the artifact produced (champion, economic buyer, technical influencer, reviewers, daily users, anti-champion warning signs). That is enough to distinguish it from siblings like impact_anchor_market or impact_craft_message without opening schemas. It stops short of explicitly naming a sibling it is not, so it lands at 4 rather than 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?

It describes the input situation ("You give what your product does and the problem it solves, plus optional company name, target company type, price point and sector"), which implies when the tool applies. However, there is no explicit when-not guidance and no routing to alternatives among the impact_* siblings, so the agent must infer positioning.

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 behavioral context: it uses only supplied input, it always includes the status quo and 'doing nothing' cards, and it closes with self-critique of what would sharpen the map. It does not specify length or format of the output beyond 'cards'.

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 organized as purpose, inputs, outputs — a sensible front-load. Some phrasing is loose ('Helps you decide what buyers compare you with'), but no sentence is filler and nothing important is buried.

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 it does enumerate what comes back (per-competitor cards, status quo, doing nothing, lead areas, discovery questions, sector questions and objections). What remains unclear is the shape and size of that output, which matters for a generative tool with six inputs.

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 six parameters, including the sector enum and the bracket-note convention for competitor names. The description only restates that competitors, weaknesses, and strengths are optional, adding little semantic 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?

The description states a concrete outcome: it maps what buyers compare your product with and where you can lead, and it enumerates the returned artifacts (one card per competitor, status quo, doing nothing, discovery questions). The verb+resource is clear enough to act on, though it never names or contrasts itself with the sibling impact_* framework 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?

Usage is implied by the input recipe (give your product, category, and optionally competitors/strengths/weaknesses), which signals the situation it fits. There is no explicit when-to-use versus when-not, and no routing to alternatives such as impact_anchor_market or impact_full_audit.

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 and scope are covered. The description adds useful behavior beyond that by enumerating exactly what is produced (three versions, matrix, ranked proof points, test questions), but it doesn't say how it behaves when customer_metrics is absent or whether it fabricates figures.

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?

Roughly seventy words for eight parameters, with the benefit statement front-loaded and inputs before outputs. The final sentence is a dense run-on list of deliverables, but no sentence is padding.

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 correctly carries the burden of describing returns in detail, and it does. The gaps are the unmentioned your_sector parameter and unspecified handling of missing optional data (e.g., no customer_metrics), which matter for an 8-parameter generative 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 the baseline is 3. The description recaps the three required inputs plus product name, category, customer results and business model, but conspicuously omits your_sector, whose enum and sector-notes effect are documented only 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?

"Helps you decide what you can claim that buyers will believe" is a vague opener, but the description then names concrete artifacts: value statements in three versions, a value matrix, ranked proof points, audience/channel variants, and test questions. An agent can tell this is a value-proposition/proof-point generator rather than a messaging drafter or market anchor tool, though it never names the sibling it is contrasted with.

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: it presumes you already have a target customer, a main outcome, and a differentiator. There is no explicit "use this when..." statement, no exclusions, and no pointer to impact_craft_message or impact_anchor_market for adjacent tasks, leaving the agent to infer routing from sibling names alone.

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 settled and the description adds no risk context. It does disclose the default behavior that all five channels are covered when none are specified, which is genuinely useful, but it says nothing about non-determinism, length, edit expectations, or why it is described as copy "to edit."

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: the first frames the job, the second lists inputs and outputs, with the purpose front-loaded. The output list is long but each item is a real deliverable, so it earns its space; only the trailing "and the order to work the channels in" clause feels appended rather than integrated.

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 returns, and it does so concretely by naming every deliverable and the calls to action. For a seven-parameter generative tool the remaining gap is small: output format and whether results are deterministic are unstated, and the sector parameter is unmentioned.

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 beyond field labels by explaining effects: business_model drives the calls to action and commercial terms, and channels determine which artifacts appear plus "the order to work the channels in." The only unexplained input is your_sector, which is left out of the description entirely.

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 concrete framing ("how your positioning should read in each channel") and enumerates the exact artifacts produced: website hero, LinkedIn tagline and post drafts, three-email cold sequence, sales deck outline, 15-minute demo script. That is far more specific than the title alone, though it never names or contrasts the sibling tools (craft_message, anchor_market) that likely precede it.

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 states the entry condition clearly: you must already have a positioning statement, target customer and key benefit, and the tool then translates them into per-channel copy. It also implies a downstream role in the funnel by consuming positioning rather than producing it. It stops short of explicit when-not guidance or naming an alternative tool for a different job.

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