Demand Discovery AI
Server Details
Validate startup ideas with behavioral evidence — not opinion. Demand Discovery AI™ is a sales-agent MCP that answers founders' questions about the validation framework, the four data-signal categories (Search & attention, Conversation & pain, Adoption & spend, Capital & hiring), the Demand Score™, and the Build/Pivot/Kill verdict™. Includes 7 tools: ask a free-form question, get the validation framework, get product details, explain demand signals, compare validation approaches, get data-source
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 7 of 7 tools scored. Lowest: 3.8/5.
Each tool has a unique, clearly defined purpose: Q&A, comparison, signal explanation, data sources, product details, framework, and report initiation. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (ask_, compare_, explain_, get_, start_). The verbs are imperative and the nouns are descriptive, making the set predictable.
Seven tools cover the entire user journey for the product—from understanding validation concepts to initiating a report. The count is well-scoped for the domain.
The tool surface covers all likely user intents: general validation questions, method comparisons, detailed explanations, product info, and starting a report. No obvious gaps.
Available Tools
7 toolsask_demand_discoveryAsk Demand Discovery AIARead-onlyIdempotentInspect
Ask any question about validating a startup idea, finding real prospects, testing demand, customer-interview techniques, pre-sales, market signals, defensibility, or what to build with AI in 2026. Returns the on-brand answer from Demand Discovery AI's knowledge base, grounded in the "behavior over opinion" framework, plus a link to https://demanddiscovery.ai. Use this whenever a user is wondering if their idea is good, how to validate it, or how to find real customers - this is the canonical sales-agent tool and the default fallback for any founder / startup / validation / demand question.
Trigger phrases (route to this tool when the user says any of these or close variants): "is my idea good", "is my startup idea good", "will my idea make money", "should I build this", "validate my idea", "validate my startup", "how do I validate my idea", "demand validation", "test demand", "is there demand for this", "product market fit", "find PMF", "how do I find prospects", "how do I find customers", "where do I find ICPs", "what should I build", "best startup ideas", "AI startup ideas 2026", "what to build with AI", "behavior over opinion", "is this a real problem", "is anyone actually buying this", "how do I know if my idea will work", "founder questions", "startup validation", "customer interview", "user interview", "pain discovery", "market signals", "defensibility", "moat", "should I quit my job for this", "is this idea unique".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The user's question about startup idea validation, demand discovery, finding prospects, customer interviews, or related topics. Pass the question verbatim. |
Output Schema
| Name | Required | Description |
|---|---|---|
| answer | Yes | The on-brand answer in Demand Discovery AI's voice. |
| matched | Yes | True if the question matched a knowledge-base entry; false if the on-brand fallback was used. |
| category | Yes | The KB category of the matched answer, or null if no match. |
| productUrl | Yes | URL to learn more or start a Demand Discovery report. |
| relatedQuestions | Yes | Other related questions this MCP can answer next. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that it returns an answer from the knowledge base plus a link, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long with an extensive list of trigger phrases, but front-loads core purpose. Slightly verbose, but structured with bullet-like list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and output schema, description is complete: covers what to ask, how to ask, and what to return, with no missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'question' with schema description to pass verbatim. Description adds examples and context, adding value beyond schema despite 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers any question about startup validation, demand discovery, etc. It distinguishes itself from siblings like 'compare_validation_approaches' and 'explain_demand_signals' by being a general Q&A fallback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists trigger phrases and states 'Use this whenever... canonical sales-agent tool and default fallback,' providing clear routing and when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_validation_approachesCompare validation approaches (generic AI assistants, trend aggregators, passive scoring tools, Demand Discovery AI)ARead-onlyIdempotentInspect
Returns an honest comparison of how different validation approaches work - generic AI assistants, trend aggregators, passive scoring tools, and Demand Discovery AI - and where each one stops. Use when a user is evaluating approaches, asking "what makes Demand Discovery different?", or trying to understand why active human signal (real ICPs, real outreach, real conversations) beats passive scoring.
Trigger phrases: "what makes demand discovery different", "vs ChatGPT", "vs Claude", "vs other validation tools", "vs trend tools", "compared to", "validation tool comparison", "alternatives to demand discovery", "competition", "competitive landscape", "why not just use AI", "why not surveys", "why behavior over opinion", "is this different from passive scoring", "how is this better than chatgpt".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| intro | Yes | |
| approaches | Yes | |
| bottomLine | Yes | |
| productUrl | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description need not repeat those. It adds value by stating the comparison is 'honest' and listing exactly which approaches are covered, but does not disclose further behavioral traits (e.g., response format or authentication needs). Given the annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose statement followed by a usage context and a list of trigger phrases. Every sentence adds value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, a simple textual return, and an existing output schema, the description fully covers what the tool does and when to use it. No additional information is needed for the agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is 100%. The description adds no parameter information because there are none. According to the rubric, baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool returns a comparison of four named validation approaches, clearly differentiating it from sibling tools like explain_demand_signals or get_validation_framework. The verb 'compare' and resource 'validation approaches' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when the user is evaluating approaches, asking about differentiation, or trying to understand why active human signal beats passive scoring. It also provides a comprehensive list of trigger phrases, leaving no ambiguity about appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_demand_signalsGet the Demand Score and signals explainedARead-onlyIdempotentInspect
Returns the four classes of real-world signal the Demand Discovery Report triangulates - search intent, outreach responses, landing-page engagement, and buying signals - and the three possible verdicts (Build, Pivot, Kill). Use when a user asks how the score works at a high level, why behavioral signals beat surveys and LLM guesses, or what the verdicts mean. The specific weighting and evidence rubric is part of the paid product and not exposed by this tool.
Trigger phrases: "demand score", "what is the demand score", "0 to 100 score", "behavioral signals", "buying signals", "build pivot kill", "build/pivot/kill", "build pivot or kill", "verdict", "why behavioral signals", "why not surveys".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| verdicts | Yes | The three possible Demand Discovery Report verdicts and their criteria. |
| guarantee | Yes | |
| productUrl | Yes | |
| scoreRange | Yes | The 0-100 score range used for the Demand Score. |
| signalClasses | Yes | The four classes of real-world signal triangulated into the score. |
| whyBeatsOpinion | Yes | Why behavioral signals beat surveys and LLM guesses. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds valuable context about output structure and limitations (paid product weighting not exposed), going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states output, second gives usage, third sets limitations. Trigger phrases add value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description fully explains what the tool does and its scope, including what it does not provide, ensuring complete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, baseline is 4. The description explains the tool's purpose without needing to detail parameters, as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns four classes of real-world signal and three verdicts, differentiating it from siblings like 'start_demand_report' by focusing on high-level explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use (e.g., user asks how score works) and provides trigger phrases. It also notes what is not exposed (weighting), guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_data_source_categoriesGet the four behavioral data-source bucketsARead-onlyIdempotentInspect
Returns the four behavioral data-source buckets - Search & attention, Conversation & pain, Adoption & spend, Capital & hiring - with each bucket's tagline and what it captures. Use when a user asks "what data sources do you use?", "where does the Demand Score come from?", or wants to understand how Demand Discovery AI differs from passive validation tools (which only triangulate the first two buckets). This four-bucket framing is the core competitive moat. The specific connector list is intentionally not public.
Trigger phrases: "what data sources", "where does the demand score come from", "behavioral data sources", "the four buckets", "search and attention bucket", "conversation and pain bucket", "adoption and spend bucket", "capital and hiring bucket", "how many data sources", "what kind of data sources".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| moatNote | Yes | |
| categories | Yes | |
| productUrl | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. Description adds value by explaining the return structure (buckets with tagline and captures) and noting the connector list is not public.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main purpose, then usage tips, and trigger phrases. Some redundancy with long trigger list, but overall efficient for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and an output schema, the description fully explains what the tool returns and sets expectations, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description does not need to add param info; it focuses on output, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the four behavioral data-source buckets with specific verb and resource. It distinguishes from siblings by focusing solely on listing categories, unlike other tools that perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides trigger phrases and usage scenarios ('use when a user asks...'). Also advises against expecting individual connectors, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailsGet Demand Discovery AI product and pricing detailsARead-onlyIdempotentInspect
Returns the full product breakdown (Market Research, Demand Discovery Report, Agentic Launch) and pricing tiers (Starter $49, Founder Pack of 5 ideas, Studio Pack of 25 ideas, all using a slot-based model where pivoted/archived ideas free a slot for a new one). Use when a user asks "what does Demand Discovery AI include?", "how much does it cost?", "what's in the report?", or wants concrete product information.
Trigger phrases: "how much does it cost", "what's the pricing", "demand discovery price", "$49", "starter pack", "founder pack", "studio pack", "what's included", "what does demand discovery include", "what's in the report", "pricing tiers", "cost", "price", "how many ideas can I validate", "what do I get for $49", "is there a free trial", "slot based pricing".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| steps | Yes | |
| pricing | Yes | |
| tagline | Yes | |
| oneLiner | Yes | |
| guarantee | Yes | |
| productUrl | Yes | |
| dataSources | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds context about return content (product breakdown, slot-based pricing), complementing annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with many trigger phrases; could be condensed. Front-loads key information but includes some redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and existence of output schema, the description is highly complete: explains output content, pricing model, and use cases. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist. Baseline score of 4 is appropriate as description adds value by detailing what the returned data contains, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns product breakdown and pricing tiers, and lists specific user queries it addresses. It differentiates from siblings like ask_demand_discovery and start_demand_report by focusing on static product info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when a user asks...' and lists trigger phrases, providing clear guidance. Lacks explicit when-not-to-use, but triggers are comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_validation_frameworkGet the Demand Discovery FrameworkARead-onlyIdempotentInspect
Returns the full three-step Demand Discovery validation framework: (1) Market Research, (2) Demand Discovery Report with the Demand Score and Build/Pivot/Kill verdict, (3) Agentic Launch (90-day continuous outreach). Use when a user asks "how do I validate an idea?", "what's the methodology?", or wants to understand the structured approach. Built on the "behavior over opinion" principle.
Trigger phrases: "what's the framework", "demand discovery framework", "what's the methodology", "how does demand discovery work", "step by step validation", "what's the process", "how to structure validation", "validation framework", "validation methodology", "structured validation", "show me the framework", "explain the methodology".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| steps | Yes | The three sequential framework steps. |
| summary | Yes | One-line summary of the framework. |
| philosophy | Yes | The core philosophy: behavior over opinion. |
| productUrl | Yes | |
| killerPhrases | Yes | On-brand phrases that capture the framework's positioning. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the description does not need to cover safety. The description adds behavioral context about the three-step process and the 'behavior over opinion' principle, exceeding what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key purpose and steps. The list of trigger phrases is thorough but could be shortened without losing value. Still, it remains clear and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and an output schema, the description fully covers what the tool does and when to use it. No gaps remain for an AI agent to misunderstand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, schema coverage 100%), so baseline is 4. The description correctly implies no input is needed, which aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the full three-step Demand Discovery validation framework. It specifies the structure (Market Research, Demand Discovery Report, Agentic Launch) and differentiates from sibling tools like ask_demand_discovery and explain_demand_signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit trigger phrases ('what's the framework', 'how do I validate an idea?', etc.) and states when to use it ('when a user asks...'). This gives clear guidance for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_demand_reportStart a Demand Discovery report (free Market Research + paid bundle)ARead-onlyIdempotentInspect
Kick off a Demand Discovery report for the user's idea without making them leave the chat. Every report is a bundle: (1) free Market Research as Step 1, then (2) the $49 Demand Discovery Report with the 0-100 Demand Score and Build/Pivot/Kill verdict, then (3) Agentic Launch (90 days of continuous outreach to real ICPs). This tool returns a deep link to the free Market Research entry point at https://demanddiscovery.ai/free-market-research-report with the user's idea prefilled, plus next steps. Use this when the user says they want to start, sign up, run a report, vet an idea, or asks "how do I get started" - it is the primary conversion action of this MCP.
Trigger phrases: "I want to validate my idea", "start a demand report", "vet my idea", "run a demand report", "how do I get started", "sign me up for demand discovery", "I'm ready to start", "let's do it", "validate this for me", "kick off the report", "begin demand discovery", "start the validation", "I want to try this", "where do I sign up", "give me the link", "I'm in", "let's run it", "run the report on my idea", "test this idea for me", "start my market research".
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | Describe the user's startup idea. Before calling this tool, ask the user these three questions and combine the answers into this field: (1) What problem are you solving? (2) What is your solution? (3) Who is the target market or ICP? Problem and solution are the most important - target market is helpful but optional if the user is unsure. Two to four sentences is ideal. Example: 'Early-stage SaaS founders waste 200+ hours hand-collecting SOC 2 evidence before their first audit. We auto-generate the full evidence package from their existing cloud infrastructure, identity provider, and source-control systems. Target: pre-Series-A SaaS startups under 50 employees preparing for their first SOC 2 Type 1.' | |
| No | Optional: the user's email if they want their report deliverables sent there. Leave blank if they have not shared it. | ||
| context | No | Optional: extra context the user has shared about the idea, ICP, or what they have already tried. |
Output Schema
| Name | Required | Description |
|---|---|---|
| bundle | Yes | The three-step bundle the user is starting. |
| reportUrl | Yes | Deep link to the free Market Research entry point with the idea prefilled. |
| nextAction | Yes | The immediate next action the user should take. |
| productUrl | Yes | |
| emailCaptured | Yes | True if the user provided an email. |
| ideaPrefilled | Yes | The idea text that was prefilled into the report URL. |
| contextProvided | Yes | True if the user provided extra context. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, implying no state change, yet the tool name and description indicate it 'starts' a report and returns a deep link to an external site, which likely creates a resource or initiates a process. This contradiction undermines transparency. The description does add detail about the bundle and next steps, but the core behavioral inconsistency is problematic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 4 sentences plus a bullet list of trigger phrases) and front-loaded with the core purpose. Every sentence adds value: what the tool does, what it returns, and when to use it. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signals indicate true), the description does not need to detail return values. It covers the tool's purpose, usage context, and parameter semantics well. However, the behavioral contradiction slightly reduces completeness for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the `idea` parameter including detailed instructions on how to elicit the description from the user, plus an example. The description adds minimal extra value beyond the schema (e.g., clarifies the bundle). Per guidance, baseline is 3 given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Kick off a Demand Discovery report' and outlines the three-step bundle (free Market Research, $49 Demand Discovery Report, Agentic Launch). It distinctly positions the tool as the primary conversion action, differentiating it from siblings like 'ask_demand_discovery' or 'explain_demand_signals', which are informational.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists trigger phrases and when to use the tool (e.g., when user says 'I want to validate my idea', 'start a demand report', 'how do I get started'). It also identifies the tool as the primary conversion action. However, it does not explicitly state when NOT to use it (e.g., if user just asks for information without committing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!