Skip to main content
Glama
Sign In

revenue-enablement-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

ROI Business Case Builder

roi_business_case_builder
Read-only

Helps you build an ROI case the buyer's finance team can check. You give your solution, its main value driver and the buyer's own figures: an annual value estimate, or current annual cost with the expected improvement percent. With them you get the ROI, payback, three year value and sensitivity. Without them it shows no ROI: it names the inputs to add and gives the structure of the case (the cost lines to price, your quoted results as reference points, the questions to ask). Ask finance for the cash-only annual benefit when an investment decision depends on cash.

Input Schema

NameRequiredDescriptionDefault
industryNoThe customer's industry, in any words. Used for wording and sector notes only: no industry figure is applied to the calculation. A return needs the buyer's own figures (annual value estimate, or current annual cost with expected improvement percent)
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.
company_sizeNoCompany size tier
customer_nameNoCustomer/prospect name
known_metricsNoMetrics the prospect shared, or results you can quote. Listed as reference points, never as the buyer's figures; to turn the buyer's figures into the value, give current annual cost and expected improvement percent, or annual value estimate
your_solutionYesYour product/solution
annual_revenueNoCustomer annual revenue. Shown as your input; it is not turned into a value
employee_countNoNumber of employees. Shown as your input; it is not turned into a value
solution_priceNoAnnual cost of your solution
current_processNoHow they do it today. Separate the ways of working with a semicolon: each becomes a cost line to price. Not used in the calculation
annual_cash_benefitNoOptional buyer-confirmed annual cash benefit in US dollars, excluding staff time without a cash release. Ask finance to separate cash from non-cash value. Compared with the annual solution price; a cash deficit holds the investment decision.
current_annual_costNoOptional: what the problem or the current process costs the buyer a year, in dollars (their figure)
primary_value_driverYesPrimary value category
annual_value_estimateNoOptional: the buyer's own estimate of the annual value in dollars; used as the value when given
implementation_timelineNoExpected implementation time. Shown in the output; not used in the calculation
expected_improvement_percentNoOptional: the share of that annual cost the buyer expects to save, in percent (their figure)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / annual_cash_benefit
      Added value: +{
+  "description": "Optional buyer-confirmed annual cash benefit in US dollars, excluding staff time without a cash release. Ask finance to separate cash from non-cash value. Compared with the annual solution price; a cash deficit holds the investment decision.",
+  "minimum": 0,
+  "type": "number"
+}
    • changedInput schema / properties / industry / description
      Previous value: -"The customer's industry, in any words. Used for wording and sector notes only: no industry figure is applied to the calculation. A return needs the buyer's own figures (annual_value_estimate, or current_annual_cost with expected_improvement_percent)"New value: +"The customer's industry, in any words. Used for wording and sector notes only: no industry figure is applied to the calculation. A return needs the buyer's own figures (annual value estimate, or current annual cost with expected improvement percent)"
    • changedInput schema / properties / known_metrics / description
      Previous value: -"Metrics the prospect shared, or results you can quote. Listed as reference points, never as the buyer's figures; to turn the buyer's figures into the value, give current_annual_cost and expected_improvement_percent, or annual_value_estimate"New value: +"Metrics the prospect shared, or results you can quote. Listed as reference points, never as the buyer's figures; to turn the buyer's figures into the value, give current annual cost and expected improvement percent, or annual value estimate"
  2. Changed6 schema fields changed
    • changedInput schema / properties / annual_revenue / description
      Previous value: -"Customer annual revenue"New value: +"Customer annual revenue. Shown as your input; it is not turned into a value"
    • changedInput schema / properties / current_process / description
      Previous value: -"How they do it today. Shown in the output; not used in the calculation"New value: +"How they do it today. Separate the ways of working with a semicolon: each becomes a cost line to price. Not used in the calculation"
    • changedInput schema / properties / employee_count / description
      Previous value: -"Number of employees"New value: +"Number of employees. Shown as your input; it is not turned into a value"
    • changedInput schema / properties / industry / description
      Previous value: -"Industry for the example benchmarks: Technology, Financial_Services, Healthcare, Manufacturing or Retail (exact spelling). Any other value uses Technology"New value: +"The customer's industry, in any words. Used for wording and sector notes only: no industry figure is applied to the calculation. A return needs the buyer's own figures (annual_value_estimate, or current_annual_cost with expected_improvement_percent)"
    • changedInput schema / properties / known_metrics / description
      Previous value: -"Metrics the prospect shared. Shown in the output; to turn them into the value, give current_annual_cost and expected_improvement_percent, or annual_value_estimate"New value: +"Metrics the prospect shared, or results you can quote. Listed as reference points, never as the buyer's figures; to turn the buyer's figures into the value, give current_annual_cost and expected_improvement_percent, or annual_value_estimate"
    • 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

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, non-destructive, closed-world behavior, so the description earns credit for disclosing the degraded path: with no buyer figures it returns no ROI, instead naming the missing inputs and laying out the case structure. It also enumerates the computed outputs (ROI, payback, three-year value, sensitivity), which is real behavioral context the annotations cannot convey.

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 paragraph is front-loaded with the purpose and the two operating modes, then closes with a conditional data-gathering tip. Sentences are dense but each carries information; the finance/cash sentence is the only one that reads slightly tangential and could be folded into the figures sentence.

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 16-parameter tool with only 2 required fields and no output schema, the description covers what is needed: required inputs, the fallback when figures are absent, and the shape of the returned analysis. It stops short of stating units or formatting expectations for the computed outputs, but nothing essential to invoking it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline would be 3, but the description adds a cross-parameter rule the schema only states piecemeal: value comes either from an annual value estimate or from current annual cost combined with expected improvement percent. It also reinforces the buyer-figure vs. reference-point distinction that governs several optional fields, which is the key semantic trap in this 16-parameter schema.

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 names a specific verb and artifact ('build an ROI case') and states the two required ingredients (solution, primary value driver) plus the buyer figures needed to produce numbers. It is clearly distinguishable from the sibling builders, which cover plans, demos, and proposals rather than financial justification, though it never explicitly contrasts itself with them.

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 a clear when-to-use condition by splitting the two modes: with buyer figures you get computed ROI, without them you get an input checklist and case structure. It adds a situational instruction ('Ask finance for the cash-only annual benefit when an investment decision depends on cash'), but does not name any alternative tool or state when a different builder is the better choice.

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