Skip to main content
Glama
Sign In

craft-content-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Testimonial Capture

testimonial_capture
Read-only

Helps you ask a happy customer for a testimonial, from the customer's name, company, success story and the type of testimonial you want. Optional role, relationship, intended use, incentive, your product and business model fit it to the customer. Returns a request email, interview questions for the customer's role and sector, quote drafts for the customer to edit and a sign off checklist. It uses your product name when you give it and says so when you do not. Ask whether written customer approval covers the exact material and intended use.

Input Schema

NameRequiredDescriptionDefault
use_caseNoWhere the testimonial will be used (the website or a sales deck, for example)
incentiveNoOptional: what you are offering in return
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_productNoOptional: your product or service name, used in the answer. Without it the answer says so and shows a placeholder.
customer_nameYesThe customer's name
customer_roleNoThe customer's job title
success_storyYesA short description of their success with your product
business_modelNoOptional: how you charge, so the advice fits it. If omitted, it is read from your text and the answer says how.
customer_statusNoAsk whether the customer is active or cancelled before a testimonial request. A confirmed typed fact takes precedence over cancellation wording.
customer_companyYesThe customer's company
testimonial_typeYesThe kind of testimonial you need
publication_approvalNoOptional confirmed written approval for this exact customer name, figures, quote and intended use. Ask before publication. A draft cannot grant customer permission.
relationship_contextNoHow long they have been a customer and the key interactions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / customer_status
      Added value: +{
+  "description": "Ask whether the customer is active or cancelled before a testimonial request. A confirmed typed fact takes precedence over cancellation wording.",
+  "enum": [
+    "active",
+    "cancelled",
+    "unknown"
+  ],
+  "type": "string"
+}
    • 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 / customer_company / description
      Previous value: -"Customer's company"New value: +"The customer's company"
    • changedInput schema / properties / customer_name / description
      Previous value: -"Customer name"New value: +"The customer's name"
    • changedInput schema / properties / customer_role / description
      Previous value: -"Customer's job title"New value: +"The customer's job title"
    • changedInput schema / properties / incentive / description
      Previous value: -"Optional: What you're offering in return"New value: +"Optional: what you are offering in return"
    • changedInput schema / properties / relationship_context / description
      Previous value: -"How long they've been a customer, key interactions"New value: +"How long they have been a customer and the key interactions"
    • changedInput schema / properties / success_story / description
      Previous value: -"Brief description of their success with your product"New value: +"A short description of their success with your product"
    • changedInput schema / properties / testimonial_type / description
      Previous value: -"Type of testimonial needed"New value: +"The kind of testimonial you need"
    • changedInput schema / properties / use_case / description
      Previous value: -"Where will this testimonial be used? (website, sales deck, etc.)"New value: +"Where the testimonial will be used (the website or a sales deck, for example)"
    • addedInput schema / properties / your_product
      Added value: +{
+  "description": "Optional: your product or service name, used in the answer. Without it the answer says so and shows a placeholder.",
+  "type": "string"
+}
    • 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

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, and the description does not contradict them. It adds real behavioral substance beyond that: it enumerates the four returned artifacts (request email, role/sector interview questions, editable quote drafts, sign-off checklist), states the fallback behavior when no product name is supplied, and flags the customer-approval prerequisite.

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 first sentence front-loads purpose and required inputs, followed by optional inputs, then outputs, then the approval caveat – a sensible order. A small amount of redundancy exists, notably the product-name sentence that restates the your_product schema description, but no sentence is 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?

With 13 parameters, 4 required, and no output schema, the description takes on the burden of explaining return values and does so explicitly with its four artifacts. It also covers the notable edge behavior (missing product name) and the approval/compliance requirement, which is the main risk surface for a testimonial workflow.

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%, so the schema already carries the parameter documentation and the baseline is 3. The description's summary ("optional role, relationship, intended use, incentive, your product and business model") groups optional inputs loosely and repeats the product-name behavior already written in the schema, adding little new semantics.

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?

"Helps you ask a happy customer for a testimonial" states a specific verb and resource, then names the exact inputs (name, company, success story, testimonial type) that drive it. It is clear what the tool produces, but it never contrasts itself with siblings like case_study_generator or sales_enablement_content, leaving an agent to infer the boundary.

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 context is implied by the opening clause and reinforced by the closing instruction to check that approval covers the exact material and intended use. However, there is no explicit when-to-use/when-not-to-use framing and no named alternative for adjacent needs such as full case studies, so the routing guidance stays implicit.

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