impact-mcp

IMPACT Full Audit

impact_full_audit

Read-only

Helps you decide whether your positioning is working and what to fix first. Use for a full positioning review or when someone asks help me explain why we are different. Ask what the product does, who it serves and the problem it solves before calling; never invent these or fill missing facts with placeholders such as Not supplied. Clarify what unlabelled numbers mean. For a request only to phrase a message, impact_craft_message also fits; use this tool for the full review. You get input completeness scores, supplied proof, a positioning draft and next actions. Scores measure how complete the inputs are, not how strong the positioning is. Never invent proof.

Input Schema

Name	Required	Description
`competitors`	No	Main competitors
`your_sector`	No	Your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.
`company_name`	No	Your company name
`business_model`	No	How you sell (saas, services, connectivity, transactions, marketplace, hardware_software or investment). Used in the plan; read from your inputs when not given. It does not change the score
`problem_solved`	Yes	The problem the user says they solve. Ask if missing; do not invent or use a placeholder.
`target_customer`	Yes	Who it serves, as supplied by the user. Ask if missing. Keep staff ranges as ranges and clarify unlabelled numbers.
`customer_feedback`	No	Customer feedback actually supplied by the user. Leave out if absent; never invent quotes or outcomes.
`current_positioning`	No	Your current positioning statement or tagline
`key_differentiation`	No	A difference the user can describe. Leave out if unknown; do not invent uniqueness or proof.
`product_description`	Yes	What the product or service does, in the user's words. Ask if missing; do not invent or use a placeholder.

Output Schema

Name	Required	Description	Default
`plainText`	Yes
`positioningAudit`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 1, 2026

changedInput schema / properties / customer_feedback / description

Previous value: -"What customers say about you"New value: +"Customer feedback actually supplied by the user. Leave out if absent; never invent quotes or outcomes."

changedInput schema / properties / key_differentiation / description

Previous value: -"What makes you unique"New value: +"A difference the user can describe. Leave out if unknown; do not invent uniqueness or proof."

changedInput schema / properties / problem_solved / description

Previous value: -"The problem you solve"New value: +"The problem the user says they solve. Ask if missing; do not invent or use a placeholder."

changedInput schema / properties / product_description / description

Previous value: -"What your product does"New value: +"What the product or service does, in the user's words. Ask if missing; do not invent or use a placeholder."

changedInput schema / properties / target_customer / description

Previous value: -"Who you serve"New value: +"Who it serves, as supplied by the user. Ask if missing. Keep staff ranges as ranges and clarify unlabelled numbers."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "plainText": {
+      "type": "string"
+    },
+    "positioningAudit": {
+      "oneOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "draft": {
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            },
+            "gaps": {
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            },
+            "kind": {
+              "const": "positioning-audit"
+            }
+          },
+          "required": [
+            "kind",
+            "draft",
+            "gaps"
+          ],
+          "type": "object"
+        },
+        {
+          "additionalProperties": false,
+          "properties": {
+            "kind": {
+              "const": "unavailable"
+            },
+            "reason": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "kind",
+            "reason"
+          ],
+          "type": "object"
+        }
+      ]
+    }
+  },
+  "required": [
+    "positioningAudit",
+    "plainText"
+  ],
+  "type": "object"
+}

First observedOct 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines5/5

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.

All impact-mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.