Skip to main content
Glama
Sign In

impact-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Anchor Market

impact_anchor_market
Read-only

Helps you decide which market segment to win first. You give what your product does and the segments you are weighing, plus optional customers, pain, deal size and company counts. You get a beachhead choice: your segments ranked from your own customers, pain and deal size when you give all three (the answer says which method it used), otherwise scored on keywords in their names; a TAM, SAM and SOM calculation from only the figures you give; a three year expansion path and an ICP hypothesis for the chosen segment. It never chooses a segment you did not name.

Input Schema

NameRequiredDescriptionDefault
sales_cycleNoTypical sales cycle length. Shown in the output; not used in the scoring
your_sectorNoYour 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.
customer_painNoThe problem your best customers describe, in their words. With current customers and average deal size it ranks the segments from your own inputs; without them the keyword presets are used
company_countsNoHow many companies you could sell to in each segment, one per line or separated by semicolons (for example "Mid-market fintech: 3,200; Enterprise banks: 600"). A single number is read as the count for the recommended segment. Needed for market sizing
average_deal_sizeNoYour annual contract value (ACV) as one amount (e.g., "$50,000", "$50K" or "$1.5M"); a range is refused
current_customersNoDescription of your current/best customers. With customer pain and average deal size it ranks the segments (the answer says which method it used); without them it is shown only and the keyword presets score the segments
potential_segmentsNoThe market segments you are weighing, in your own words (for example Mid-market fintech, Enterprise banks, Small retail chains). Needed for a recommendation: without segments no segment is chosen, and the answer explains how to find yours
product_descriptionYesWhat your product does
percent_matching_icpNoThe percent of those companies that match your ideal customer profile (for example 25). Needed for SAM
year_one_share_percentNoThe share of the matching companies you expect to win in year one, in percent (for example 1). Needed for SOM

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / current_customers / description
      Previous value: -"Description of your current/best customers. With customer_pain and average_deal_size it ranks the segments (the answer says which method it used); without them it is shown only and the keyword presets score the segments"New value: +"Description of your current/best customers. With customer pain and average deal size it ranks the segments (the answer says which method it used); without them it is shown only and the keyword presets score the segments"
    • changedInput schema / properties / customer_pain / description
      Previous value: -"The problem your best customers describe, in their words. With current_customers and average_deal_size it ranks the segments from your own inputs; without them the keyword presets are used"New value: +"The problem your best customers describe, in their words. With current customers and average deal size it ranks the segments from your own inputs; without them the keyword presets are used"
  2. Changed1 schema field changed
    • changedInput schema / properties / potential_segments / description
      Previous value: -"The market segments you are weighing (for example Mid-market fintech, Enterprise banks, Small retail chains)"New value: +"The market segments you are weighing, in your own words (for example Mid-market fintech, Enterprise banks, Small retail chains). Needed for a recommendation: without segments no segment is chosen, and the answer explains how to find yours"
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All impact-mcp toolsInspect
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.

Resources