Skip to main content
Glama
Sign In

revenue-enablement-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Win/Loss Analyzer

win_loss_analyzer
Read-only

Helps you decide why you won or lost and what to change. You give the details of one deal, a competitor pattern or a set of deals. You get a short write up that names the outcome, the stated reason in the buyer's words, what the reason points to and what the buyer weighed, then questions for the review call and sector notes. It adds no figure or reason you did not give, and says what a missing outcome or reason would add.

Input Schema

NameRequiredDescriptionDefault
deal_valueNoDeal value
loss_reasonNoStated loss reason (for lost deals)
your_sectorNoOptional: 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.
deal_detailsNoDeal details, can be rough notes, CRM export, or structured data
deal_outcomeNoDeal outcome for single deal analysis
analysis_typeYesType of analysis
your_solutionNoWhat you were selling
competitor_wonNoCompetitor who won (if applicable)
multiple_dealsNoFor portfolio analysis: summary of multiple deals
sales_cycle_daysNoLength of sales cycle
stakeholders_involvedNoKey stakeholders and their positions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / your_sector
      Added value: +{
+  "description": "Optional: 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.",
+  "enum": [
+    "logistics_tech",
+    "fintech",
+    "saas",
+    "vertical_saas",
+    "ai_native",
+    "ites",
+    "telecom",
+    "software",
+    "cybersecurity",
+    "other"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already mark this as a read-only, non-destructive, closed-world tool. Beyond that, the description adds meaningful behavioral context: it says the write-up will not invent figures or reasons, and it explains how missing outcomes or reasons are handled.

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?

The description is front-loaded with the purpose and then explains input and output expectations in a compact way. It is dense but avoids repetition and unnecessary filler.

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 an 11-parameter analytical tool with full schema coverage and annotations, the description is largely complete. It explains the output content in lieu of an output schema and clarifies non-fabrication behavior, though it could say more about when to use this tool versus its siblings.

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 the parameter definitions already carry most semantic weight. The description adds useful framing about the types of deal inputs and the output structure, but it does not add specific meaning to individual parameters beyond what the schema provides.

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 analytical purpose: explain why a deal was won or lost and what to change. It covers the scope of inputs (one deal, competitor pattern, or set of deals) and the kind of write-up produced, though it does not explicitly position itself against sibling tools such as deal_strategy_coach.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives implied usage contexts by naming single deals, competitor patterns, and deal sets, which map to the analysis_type enum. However, it does not state when to choose this tool over related siblings or provide exclusions for when it is inappropriate.

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

All revenue-enablement-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