Skip to main content
Glama
Sign In

revenue-enablement-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Deal Strategy Coach

deal_strategy_coach
Read-only

Helps you decide what to do next to move a deal. You give the deal name and stage, plus competitors, stakeholder positions and blockers. You get a deal health score, a strategy for the stage, next steps and risks to handle. Ask the user to confirm blocker status, economic buyer engagement, incumbent status and project status when those facts affect the score; typed facts take precedence over text.

Input Schema

NameRequiredDescriptionDefault
blockersNoKnown blockers or objections
deal_nameYesDeal/opportunity name
close_dateNoTarget close date
deal_stageYesCurrent deal stage
deal_valueNoDeal value in dollars
next_stepsNoCurrently planned next steps
competitorsNoCompetitors in the deal and their position
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.
days_in_stageNoDays the deal has been in current stage
your_solutionNoWhat you are selling
blocker_statusNoAsk whether any blocker is present. A confirmed typed fact overrides word reading.
economic_buyerNoEconomic buyer name and engagement level
project_statusNoAsk whether the project is still active. A cancelled project is held, without a close plan.
champion_statusNoChampion identification status
incumbent_statusNoAsk whether the buyer already uses a competing supplier. Overrides word reading.
economic_buyer_engagementNoAsk whether the budget holder actively participates in this decision. Overrides word reading.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / blocker_status
      Added value: +{
+  "description": "Ask whether any blocker is present. A confirmed typed fact overrides word reading.",
+  "enum": [
+    "none",
+    "present",
+    "unknown"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / economic_buyer_engagement
      Added value: +{
+  "description": "Ask whether the budget holder actively participates in this decision. Overrides word reading.",
+  "enum": [
+    "engaged",
+    "not_engaged",
+    "unknown"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / incumbent_status
      Added value: +{
+  "description": "Ask whether the buyer already uses a competing supplier. Overrides word reading.",
+  "enum": [
+    "present",
+    "none",
+    "unknown"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / project_status
      Added value: +{
+  "description": "Ask whether the project is still active. A cancelled project is held, without a close plan.",
+  "enum": [
+    "active",
+    "cancelled",
+    "unknown"
+  ],
+  "type": "string"
+}
  2. 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"
+}
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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 is covered. The description adds genuine value beyond that: it names the return contents (health score, strategy, next steps, risks) and the conflict-resolution rule that 'typed facts take precedence over text', which an agent needs to know before calling.

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?

Four tight sentences: purpose first, then inputs, then outputs, then interaction caveat. No filler, though the final sentence is dense and packs four distinct facts into one clause.

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?

With 16 parameters and no output schema, the description needs to carry the return-value burden, and it does by naming the four artifacts returned. The mutation/permission story is moot for a read-only tool, and only explicit sibling differentiation 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 coverage is 100%, so every parameter already carries its own description, including the enum-level notes that typed facts override word reading. The description adds only a light procedural layer by grouping the four facts worth confirming with the user, so the baseline 3 is appropriate.

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?

States a specific verb and resource ('decide what to do next to move a deal') and enumerates both the inputs (deal name, stage, competitors, stakeholders, blockers) and outputs (health score, stage strategy, next steps, risks). It does not explicitly distinguish itself from adjacent siblings like mutual_action_plan_generator or win_loss_analyzer, so an agent must infer the boundary.

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?

Guidance is about interaction protocol rather than tool selection: 'Ask the user to confirm blocker status, economic buyer engagement, incumbent status and project status when those facts affect the score.' That is useful in-conversation direction, but there is no statement of when this tool is the right choice versus the 11 sibling generators.

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