Skip to main content
Glama
Sign In

revenue-enablement-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Mutual Action Plan Generator

mutual_action_plan_generator
Read-only

Helps you decide what has to happen, by whom and when, for a deal to sign on time. You give the deal name and the target close date, plus the current stage, the buyer's champion, economic buyer and evaluators, known requirements and process steps if you have them. You get a close plan both sides can work from, with milestones, owners and dates.

Input Schema

NameRequiredDescriptionDefault
blockersNoKnown blockers or concerns
deal_nameYesDeal/opportunity name
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.
current_stageNoCurrent deal stage
your_solutionNoWhat you are selling
buyer_championNoChampion name and title
economic_buyerNoEconomic buyer name and title
target_close_dateYesTarget close date (YYYY-MM-DD). A Saturday or Sunday date moves to the Friday before, and the plan says so
known_requirementsNoKnown requirements or evaluation criteria
known_process_stepsNoKnown steps in their buying process, separated by semicolons or new lines (for example: Pilot; security review; procurement). Each step becomes its own milestone
procurement_contactNoProcurement contact if known
technical_evaluatorsNoTechnical evaluators involved

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / known_process_steps / description
      Previous value: -"Known steps in their buying process"New value: +"Known steps in their buying process, separated by semicolons or new lines (for example: Pilot; security review; procurement). Each step becomes its own milestone"
    • changedInput schema / properties / target_close_date / description
      Previous value: -"Target close date (YYYY-MM-DD)"New value: +"Target close date (YYYY-MM-DD). A Saturday or Sunday date moves to the Friday before, and the plan says so"
  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, non-destructive and closed-world, so safety is covered. The description adds real context on top: what the output artifact is ('a close plan both sides can work from, with milestones, owners and dates') and that weekend close dates roll back to the preceding Friday with the change flagged.

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?

Front-loaded with the purpose, followed by inputs and then the returned artifact, in three clean sentences. The middle sentence is a laundry list that largely duplicates the schema, but the overall length is proportionate to a 12-parameter tool.

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 12-parameter generator with no output schema and read-only annotations, the description covers purpose, minimum required inputs, optional enrichment and the shape of the result. It stops short of explaining what happens with sparse input or how milestones are prioritized, but nothing essential to calling it 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 every one of the 12 parameters is already documented in structured form, including the sector inference fallback and the semicolon/newline format for process steps. The description only restates which inputs are needed versus optional, adding little beyond the schema; 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 gives a concrete verb-and-artifact: it produces a close plan with milestones, owners and dates for a deal to sign on time. That is distinguishable from siblings like account_plan_builder or deal_strategy_coach, though the description never names an alternative to sharpen 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?

Usage is implied rather than stated: you invoke it when you need a mutual close plan and have at least a deal name and target close date. It notes that stage, buyer roles and process steps are optional ('if you have them'), but there is no explicit when-not guidance or comparison to the other planning tools.

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