Skip to main content
Glama

Demand Discovery AI

by ai.demanddiscovery.mcp

Validate real demand - start the Demand Discovery Report

validate_real_demand
Idempotent

Check the account status for this idea's full Demand Discovery Report and return the user's next step. This call NEVER moves money and never transacts on the user's behalf - it only looks up whether the given email already has an account with available report slots or a report already running. It returns ONE of: the existing report path (alreadyRunning=true, chargeRequired=false, nothing new started), a no-charge slot path when the idea is already covered, or a secure hosted link the user may CHOOSE to open in their own browser to order the report (normally $49). Any purchase happens entirely on that hosted page and is initiated by the user - never by this tool. Once the order is confirmed, call get_demand_report_status with the returned orderId to stream the finished report into chat.

The Demand Discovery Report grades the idea on a 0-100 Demand Score™ with a Build / Pivot / Kill verdict™, grounded in real behavioral signals (search, conversation, adoption, capital). It normally follows a free Market Research report (start_demand_report). If that step returned a reportId, pass that EXACT id here - it ties the paid order to the existing record. If you do NOT have a reportId, OMIT it entirely; DD resolves the idea from name/problem/solution. NEVER invent, guess, or placeholder a reportId - a fabricated id is rejected.

Call this when the user wants the full/paid report, e.g. "run the $49 report", "yes, validate it for real", "I want the Demand Score", "run Demand Discovery on this", "do the deep report". Pass the SAME name/problem/solution used for the free report so the order ties back to it, the user's email, and the reportId from the free step if you have it.

If a paid report already exists for this idea (for example an existing pack slot was already used), this returns that report's status with alreadyRunning=true instead of starting a new order - in that case do NOT re-run the free step or surface a new payment link; poll get_demand_report_status (when pollWith is set) or open the returned link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesShort startup or product name - the SAME one used for the free Market Research report.
emailYesREQUIRED. The user's own email, provided by them in chat for report delivery - the order is tied to this email and Agentic Launch replies route here. This was captured at the free Market Research email gate.
problemYesOne sentence on the problem - the SAME wording used for the free report (ties the order back to it).
reportIdNoOptional but strongly preferred: the EXACT reportId returned by the free Market Research step (start_demand_report). It ties the paid order to that record. OMIT it if you don't have one - DD resolves the idea from name/problem/solution. NEVER invent, guess, or placeholder a reportId; a fabricated id is rejected.
solutionYesOne sentence on the solution - the SAME wording used for the free report.
target_marketNoOptional ICP phrase; refines what was captured on the free report if given.
current_workaroundNoOptional: how the audience copes today. Only pass if already known; never block on it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoPresent on the needs_upgrade path: 'no_credits' (current pack's reports are used) or 'slot_cap_reached' (every idea slot is occupied).
statusYes'pending_payment' on success; 'already_running'/'processing' if a paid report already exists for this idea; 'needs_upgrade' when the account's current pack has no report slots left (see upsellOptions); 'blocked'/'failed' if the reportId didn't resolve; 'unconfigured_fallback'/'error_fallback' when the inline path was unavailable.
orderIdYesThe order handle to poll with get_demand_report_status. Null if no order was created.
pollWithYesThe tool to call next to stream the report (get_demand_report_status) once paid. Null when not applicable.
expiresAtNoWhen the checkout session expires, if provided.
nextActionYesThe immediate next action the user/agent should take.
productUrlYes
checkoutUrlYesHosted page the user opens in a browser to pay. On fallback/misconfig this is a hosted deep link to continue on the site.
upsellOptionsNoWays the user can keep going when their current pack is used up (or alongside a checkout, as alternatives). Render EVERY option with its link printed verbatim and let the user choose — the user opens links in their own browser; nothing is ever purchased from chat.
alreadyRunningNoTrue if the paid report already exists (running or completed) for this idea - e.g. an existing pack slot was already used. Do NOT start a new checkout or re-run the free step; poll get_demand_report_status (if pollWith is set) or open checkoutUrl.
chargeRequiredNoFalse when no payment is due - the idea is already covered (a plan slot or a prior purchase), so do NOT open a checkout. Present on the alreadyRunning path.
checkoutCreatedYesTrue if a checkout session was created and a checkoutUrl is present.
needsFreeReportFirstYesTrue if the paid step was refused because no valid free Market Research report backs this idea - run start_demand_report first.

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond annotations by stating 'This call NEVER moves money and never transacts on the user's behalf' and explaining that any purchase happens on a hosted page initiated by the user. It also discloses the three possible return paths and warns against fabricating reportId, complementing the openWorld and idempotent hints 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and safety guarantee, but it is quite long and repeats the 'same name/problem/solution' instruction and the 'NEVER invent reportId' warning. The length is mostly justified by the nuanced paths and caveats, though trimming redundancy would improve it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides complete operational context: preconditions regarding the free report and reportId, return paths, follow-up actions (poll get_demand_report_status with orderId), and what to avoid. Given the tool's complexity and the presence of an output schema, nothing critical is missing for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds substantial semantics: name/problem/solution must match the free report, reportId must be the exact one from start_demand_report and never invented, and email is the user's own for delivery. These enrich the parameters far beyond their schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks account status for a Demand Discovery Report and returns the user's next step, using a specific verb and resource. It distinguishes itself from siblings like start_demand_report and get_demand_report_status by explaining its role as a lookup/next-step gate that never transacts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly says to call this when the user wants the full/paid report, with concrete example phrasings. It also provides when-not-to-call guidance: if a paid report already exists, do not re-run the free step or surface a new payment link, but instead poll get_demand_report_status.

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

All Demand Discovery AI toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Tools have mostly distinct purposes, but ask_demand_discovery is a catch-all that could overlap with explainer tools like explain_demand_signals or get_product_details. The detailed trigger phrases help route correctly, but some ambiguity remains.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (ask_, compare_, explain_, get_, start_, validate_) using snake_case throughout. No mixed conventions or inconsistent patterns.

Tool Count5/5

With 10 tools, the server is well-scoped for its purpose of startup idea validation. Each tool serves a clear role in the workflow, from free research to paid reports to outreach, without unnecessary bloat or missing essentials.

Completeness4/5

The tool set covers the full customer journey (free report, paid report, status polling, outreach launch) and provides educational tools for methodology. Minor gaps like report history or user management are absent but not critical for the primary function.

Resources