revenue-enablement-mcp

Demo Script Builder

demo_script_builder

Read-only

Helps you decide what to show in a demo, and in what order. You give the demo type, the persona and the use case, plus the features you must show and the pains you name. You get a timed run from opening to close, with spoken lines and a step for each feature tied to the pains, then discussion, close and follow up lines and sector notes. The answer says where each step came from and what it did not get.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "demo_type": "<demo_type>",
      "your_solution": "<your_solution>"
    },
    "name": "demo_script_builder"
  }
}

Input Schema

Name	Required	Description
`attendees`	No	Other attendees and their roles
`demo_type`	Yes	Type of demo
`your_sector`	No	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.
`demo_duration`	No	Demo duration in minutes
`your_solution`	Yes	Your product/solution
`desired_outcome`	No	What you want to achieve from this demo
`key_pain_points`	No	Pain points to address in demo
`known_objections`	No	Known objections to address
`primary_audience`	No	Primary demo audience (role/persona)
`customer_industry`	No	Customer industry
`competitor_context`	No	Competitor being displaced or compared
`must_show_features`	No	Features that must be demonstrated

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

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"
+}

First observedOct 17, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already establish this is a non-destructive, read-only, closed-world tool, so the safety profile is covered. The description adds genuine value by describing the output shape — a timed run with spoken lines, pain-tied feature steps, discussion, close, follow-up, sector notes, and provenance about what it did not receive. With no output schema, that output detail is the description's main contribution, but it omits practical traits such as response length or how missing optional inputs 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 purpose and required inputs are front-loaded in the first two sentences, with output detail following. The prose is a bit meandering — phrasing like 'what it did not get' is awkward — but every sentence carries information rather than 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 a 12-parameter, no-output-schema generation tool, the definition covers the essential contract: what to supply and what comes back, including sector-note and provenance behavior. Only minor gaps remain, such as guidance on which of the nine optional parameters materially change the result.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description goes slightly beyond by explaining how inputs are used — pains drive feature steps, features are tied to pains, and demo type plus persona shape the run. It still does not clarify optional-versus-required behavior or the role of duration, attendees, objections, or competitor context.

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 opening sentence states a specific objective — deciding what to show in a demo and in what order — which effectively means producing a demo run-of-show. That distinguishes it from siblings like proposal_section_writer or discovery_question_bank, though it never names an alternative explicitly.

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?

The description tells the agent what inputs to supply (demo type, persona, use case, must-show features, pains), which implies the context in which the tool fits. But it gives no explicit when-to-use/when-not-to-use rule and no routing guidance against the eleven sibling builders.

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 tools Inspect

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.