Skip to main content
Glama
Sign In

revenue-enablement-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Pricing Negotiation Guide

pricing_negotiation_guide
Read-only

Helps you decide how to answer a discount request without giving away margin. You give the negotiation scenario, plus deal value, the discount asked, each side's leverage and who approves. You get a leverage assessment, a value based negotiation strategy, answers to common pushback and a discount approval framework. Ask whether the user has authority to approve the proposed terms.

Input Schema

NameRequiredDescriptionDefault
scenarioYesNegotiation scenario
deal_valueNoCurrent deal value
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.
your_leverageNoYour leverage points (unique features, timeline, etc.)
your_solutionNoYour product/solution. Named in the guide and used, with your leverage, to read the sector and how you charge
business_modelNoOptional: how you charge (software subscription, services, connectivity, per transaction, marketplace, hardware plus software, or investment management). Read from your other inputs when left out
buyer_leverageNoBuyer leverage points (size, reference potential, etc.)
value_deliveredNoQuantified value your solution delivers. Used in the value reframe, word for word; the guide adds no value figure of its own
competitor_priceNoCompetitor pricing if known
decision_timelineNoWhen decision needs to be made
approval_authorityNoWho has final approval on pricing
discount_requestedNoDiscount percentage requested
pricing_authority_statusNoOptional confirmed fact. Ask whether the user can approve this price or discount. Free-text role titles do not establish authority; unconfirmed authority holds commitment to terms.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / pricing_authority_status
      Added value: +{
+  "description": "Optional confirmed fact. Ask whether the user can approve this price or discount. Free-text role titles do not establish authority; unconfirmed authority holds commitment to terms.",
+  "enum": [
+    "authorized",
+    "not_authorized",
+    "unknown"
+  ],
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / value_delivered / description
      Previous value: -"Quantified value your solution delivers. Shown in the output; the value example does not use it"New value: +"Quantified value your solution delivers. Used in the value reframe, word for word; the guide adds no value figure of its own"
    • 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"
+}
    • changedInput schema / properties / your_solution / description
      Previous value: -"Accepted but not used yet by this tool"New value: +"Your product/solution. Named in the guide and used, with your leverage, to read the sector and how you charge"
  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 and no destruction, so the bar is lower, yet the description still adds value by disclosing the output shape: leverage assessment, value-based strategy, pushback answers, and a discount approval framework. It does not discuss length, format, or any limits, which keeps it below a 5.

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 outcome and margin constraint are front-loaded, followed by inputs and outputs in a compact three-sentence flow. The trailing instruction about approval authority is somewhat disjointed from the descriptive framing but is short and actionable.

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 13-parameter advisory tool with no output schema, the description covers purpose, required inputs, and the returned artifacts well enough to call it correctly. The fallback and inference behaviors are carried by the schema rather than the description, which is acceptable but leaves the description near rather than fully complete.

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% and the schema descriptions are unusually rich, including inference behavior for your_sector, business_model, and pricing_authority_status. The description only restates a subset of the inputs, so it adds little semantic meaning 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 states a specific purpose with a clear outcome ("decide how to answer a discount request without giving away margin") and enumerates what the tool returns. It does not name any sibling such as deal_strategy_coach or competitive_trap_setter, so an agent must infer the boundary from the scenario enum rather than from the text.

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 tells the agent what to supply ("You give the negotiation scenario, plus deal value, the discount asked, each side's leverage and who approves"), which implies usage, and adds one procedural instruction about confirming approval authority. There is no explicit when-not-to-use guidance and no routing to the obviously overlapping siblings.

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