Skip to main content
Glama
Sign In

craft-content-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Sales Enablement Content

sales_enablement_content
Read-only

Helps you decide what sellers should say at each stage of a deal, from your product, the persona you sell to and your proof points. Optional objections, value propositions, competitor objections, price context, sales stage and business model shape it. Returns a pitch order, an answer to each objection with the proof point that fits it, competitor responses, discovery questions and follow up templates. Without objections it suggests the ones your sector raises.

Input Schema

NameRequiredDescriptionDefault
productYesThe product name and what it does
sales_stageNoThe stage of the sales funnel
value_propsNoOptional: key value propositions, one per line, per semicolon or comma-separated. Taken from the proof points if not provided
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.
proof_pointsYesEvidence for your claims: case studies, metrics and quotes, one per line, per semicolon or comma-separated
price_contextNoOptional: your pricing against the market (for example 'Premium, above market', 'Budget option' or 'Mid-market')
business_modelNoOptional: how you charge, so the advice fits it. If omitted, it is read from your text and the answer says how.
target_personaYesWho sales is pitching to (role and company type)
common_objectionsNoOptional: sales objections you hear, one per line, per semicolon or comma-separated. If not provided, likely objections for your sector are suggested
competitor_objectionsNoOptional: 'why not [competitor]' objections

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedInput schema / properties / business_model
      Added value: +{
+  "description": "Optional: how you charge, so the advice fits it. If omitted, it is read from your text and the answer says how.",
+  "enum": [
+    "saas",
+    "services",
+    "connectivity",
+    "transactions",
+    "marketplace",
+    "hardware_software",
+    "investment"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / common_objections / description
      Previous value: -"OPTIONAL: Sales objections you hear (comma-separated). If not provided, we'll suggest likely objections for your product type"New value: +"Optional: sales objections you hear, one per line, per semicolon or comma-separated. If not provided, likely objections for your sector are suggested"
    • changedInput schema / properties / competitor_objections / description
      Previous value: -"Optional: 'Why not [competitor]' objections"New value: +"Optional: 'why not [competitor]' objections"
    • changedInput schema / properties / price_context / description
      Previous value: -"Optional: Your pricing vs market (e.g., 'Premium, 20% above market', 'Budget option', 'Mid-market')"New value: +"Optional: your pricing against the market (for example 'Premium, above market', 'Budget option' or 'Mid-market')"
    • changedInput schema / properties / product / description
      Previous value: -"Product name and what it does"New value: +"The product name and what it does"
    • changedInput schema / properties / proof_points / description
      Previous value: -"Evidence for claims: case studies, metrics, quotes (comma-separated)"New value: +"Evidence for your claims: case studies, metrics and quotes, one per line, per semicolon or comma-separated"
    • changedInput schema / properties / sales_stage / description
      Previous value: -"What stage of sales funnel"New value: +"The stage of the sales funnel"
    • changedInput schema / properties / target_persona / description
      Previous value: -"Who sales is pitching to (role, company type)"New value: +"Who sales is pitching to (role and company type)"
    • changedInput schema / properties / value_props / description
      Previous value: -"OPTIONAL: Key value propositions (comma-separated). Will be DERIVED from proof points if not provided"New value: +"Optional: key value propositions, one per line, per semicolon or comma-separated. Taken from the proof points if not provided"
    • 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"
+}
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnly=true, destructive=false and closed-world, so the safety profile is covered. The description goes beyond that by disclosing inference and fallback behavior: value props are derived from proof points when omitted, sector is inferred and stays neutral when unclear, and objections are suggested from the sector when not supplied. It also summarizes the returned sections, which matters because there is no output schema.

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?

It is front-loaded with the purpose, then inputs, then returns, then the no-objections fallback, and every sentence carries information. The input enumeration sentence is the one mildly redundant part given the 100%-documented schema.

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 10-parameter tool with no output schema, the description covers purpose, key inputs, conditional inference and the shape of the output, which is what an agent needs to call it correctly. The main residual gap is that it never positions the tool against its many content siblings.

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% and the schema already spells out optionality, enums and inference for your_sector and business_model. The description's enumeration of shaping inputs ('Optional objections, value propositions, competitor objections, price context, sales stage and business model') largely restates the schema rather than adding format or precedence detail, so the 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 concrete outcome: deciding what sellers should say at each deal stage, driven by product, persona and proof points, and it names the artifacts produced (pitch order, objection answers, competitor responses, discovery questions, follow-up templates). That is specific enough to distinguish it from content-generation siblings like webinar_script or case_study_generator, but 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the phrasing 'at each stage of a deal' and by the sales_stage enum, and there is useful conditional guidance ('Without objections it suggests the ones your sector raises'). However, there is no explicit when-to-use/when-not guidance and no routing to or away from the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All craft-content-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