Skip to main content
Glama
Sign In

craft-gtm-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Customer Interview Kit

customer_interview_kit
Read-only

Helps you decide what to ask customers to test your hunch: it takes the interview type, the product context and the person you are interviewing, and returns an interview guide that fits the interview type, the sector and the product complexity. Questions use the sector's own language (the sector is chosen, or read from your inputs), your hypotheses are kept whole, and synthesis templates are included.

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": {
      "interview_type": "<interview_type>",
      "product_context": "<product_context>",
      "target_persona": "<target_persona>"
    },
    "name": "customer_interview_kit"
  }
}

Input Schema

NameRequiredDescriptionDefault
industryNoIndustry affects terminology and context. Leave it out and the sector is read from your other inputs
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.
business_modelNoOptional: how you earn revenue, so the advice fits it (saas, services, connectivity, transactions, marketplace, hardware_software or investment). Leave it out and the tool reads it from your other inputs and says how it read it
interview_typeYesType of interview determines question focus
key_hypothesesNoOptional: Hypotheses to validate during interview, one per line or separated by semicolons
target_personaYesWho you're interviewing (role/title)
product_contextYesProduct/service being researched
product_complexityNoAffects technical depth of questions

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that: sector language is used in the questions, the sector can be auto-derived from inputs, hypotheses are 'kept whole' (not paraphrased away), and synthesis templates are bundled into the output. It does not state length or format of the guide, which keeps it from 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 purpose is front-loaded in the opening clause and the remaining clauses add substantive facts (sector language, hypothesis preservation, synthesis templates). It is a single dense run-on sentence, however, and the mid-sentence restatement of how sector is resolved is slightly redundant.

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 an 8-parameter, enum-heavy generator with no output schema, the description does what matters: it explains what comes back (an interview guide plus synthesis templates) and how optional inputs are inferred when omitted. Minor gaps remain around guide length and how product_complexity and business_model alter the output.

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 enum parameters already carry their own explanations, so the schema does most of the work. The description only echoes that the sector may be supplied or inferred and that hypotheses are preserved; it adds no format or precedence guidance beyond what the schema says.

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 action and artifact: it takes interview type, product context and persona and 'returns an interview guide'. The phrase 'decide what to ask customers to test your hunch' pins the resource (customer interview questions) clearly enough that an agent can distinguish it from siblings like pmf_scorecard or competitive_intel, though it never names those siblings 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?

Implicit usage context is present ('test your hunch'), which signals a pre-research/discovery moment, but there is no explicit when-to-use versus when-not, and no alternative tool is named. An agent must infer that this is for planning interviews rather than analyzing results.

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

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