Skip to main content
Glama
Sign In

craft-content-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Case Study Generator

case_study_generator
Read-only

Helps you turn a customer result into a case study, built from the customer name, your product and the challenge, solution and results you give (mode full), or an interview kit to collect them (mode discovery). Optional customer industry, quote, interview notes and business model fit the wording to the customer. Returns a headline, the story with each result you list, a customer quote, social and email copy, and sector notes when the sector can be read from your text. A bracket marks anything you did not give. Ask whether written customer approval covers the exact material and intended use.

Input Schema

NameRequiredDescriptionDefault
modeNofull builds the case study and needs the challenge, solution and results; discovery returns interview questions for collecting them
resultsNoMeasurable outcomes, one per line or per semicolon (needed in full mode)
solutionNoHow your product solved it (needed in full mode)
challengeNoThe customer's challenge or problem (needed in full mode)
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_productYesYour product or service name
customer_nameYesCustomer or company name
business_modelNoOptional: how you charge, so the advice fits it. If omitted, it is read from your text and the answer says how.
customer_quoteNoOptional: a direct quote from the customer
interview_notesNoOptional: raw interview notes or a transcript. In full mode they fill a missing challenge, solution or results; the answer says they were not used when you gave all three
customer_industryNoThe customer's industry, used for context
publication_approvalNoOptional confirmed written approval for this exact customer name, figures, quote and intended use. Ask before publication. A draft cannot grant customer permission.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / publication_approval
      Added value: +{
+  "description": "Optional confirmed written approval for this exact customer name, figures, quote and intended use. Ask before publication. A draft cannot grant customer permission.",
+  "enum": [
+    "approved",
+    "not_approved",
+    "unknown"
+  ],
+  "type": "string"
+}
  2. Changed11 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 / challenge / description
      Previous value: -"The customer's challenge/problem (required for full mode)"New value: +"The customer's challenge or problem (needed in full mode)"
    • changedInput schema / properties / customer_industry / description
      Previous value: -"Customer's industry for context"New value: +"The customer's industry, used for context"
    • changedInput schema / properties / customer_name / description
      Previous value: -"Customer/company name"New value: +"Customer or company name"
    • changedInput schema / properties / customer_quote / description
      Previous value: -"Optional: Direct quote from customer"New value: +"Optional: a direct quote from the customer"
    • changedInput schema / properties / interview_notes / description
      Previous value: -"Optional: Raw interview notes or transcript. Parsed into a case study when mode is 'full'"New value: +"Optional: raw interview notes or a transcript. In full mode they fill a missing challenge, solution or results; the answer says they were not used when you gave all three"
    • changedInput schema / properties / mode / description
      Previous value: -"full = generate case study (requires challenge/solution/results), discovery = generate interview questions to gather story"New value: +"full builds the case study and needs the challenge, solution and results; discovery returns interview questions for collecting them"
    • changedInput schema / properties / results / description
      Previous value: -"Quantifiable outcomes (required for full mode)"New value: +"Measurable outcomes, one per line or per semicolon (needed in full mode)"
    • changedInput schema / properties / solution / description
      Previous value: -"How your product solved it (required for full mode)"New value: +"How your product solved it (needed in full mode)"
    • changedInput schema / properties / your_product / description
      Previous value: -"Your product/service name"New value: +"Your product or service name"
    • 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.1/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/destructive annotations, the description discloses the actual payload (headline, story with each result, quote, social and email copy, sector notes) and the placeholder convention that a bracket marks anything not supplied. It also flags a compliance obligation around customer approval and intended use, which annotations cannot express. This is genuinely additive behavioral context.

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 opening sentence front-loads purpose and the mode split, and the return-contents list is efficient. The paragraph is dense and packs several distinct ideas (inputs, outputs, brackets, approval) into few sentences, which is appropriate for a 12-parameter tool, though a minor structural break would improve scanability.

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?

With no output schema, the description carries the return-value burden and does so by enumerating output sections and the bracket placeholder rule. It also covers both modes and the approval prerequisite. It stops short of specifying output formatting or how sector notes are shaped, leaving a small residual gap.

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 per-parameter descriptions already explain mode gating, sector derivation with neutral fallback, and interview_notes backfilling, so the description largely restates structured data. It does add a compact summary of how industry, quote, notes and business model tune the wording, plus the bracket convention, but the marginal value is modest given the schema's detail.

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 verb and artifact: it turns a customer result into a case study, with two named modes (full builds the study, discovery produces an interview kit). It distinguishes the modes clearly enough that an agent can pick one, but it never names which sibling tool to prefer (e.g. testimonial_capture or sales_enablement_content) for adjacent needs.

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?

Usage conditions are stated: mode full requires challenge, solution and results, while discovery is the path when those are missing, and interview_notes backfill a gap in full mode. It also sets a precondition to confirm written customer approval for the exact material and use. What is absent is any exclusion versus neighboring content tools, so an agent gets context but no routing rules.

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