Demand Discovery AI

Start the 90-day Agentic Launch (prepares outreach - never auto-sends)

start_agentic_launch

Idempotent

Kick off Day 1 of the 90-day Agentic Launch for a completed Demand Discovery Report. Demand Discovery surfaces named prospects matching the idea's ICP and DRAFTS the first outreach batch. It sends NOTHING automatically - the user reviews and sends from their hosted manage page. Outreach is drafted to come from Amy @ Demand Discovery, with replies routed to the user's own email.

Call this after a paid report is "ready" and the user wants to act on it (e.g. "generate prospects", "start agentic launch", "find me people to talk to", "yes, do the outreach"). Pass the reportId, the user's email, and the alTriggerToken from the ready report if you have it. The email MUST be the address the user themselves provided earlier in this conversation (their report-delivery email) - if you don't have it in context, ask the user first; NEVER invent one or use a placeholder like user@example.com (placeholders are rejected and the launch will not start). The response returns a manageUrl where the user reviews/sends the drafted outreach (and can switch the sender to their own Gmail).

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	REQUIRED. The user's own email, provided by them in chat - replies to the drafted outreach route here. Reuse the EXACT address the user gave earlier in this conversation for report delivery; if you don't have it, ask the user. NEVER invent one or substitute a placeholder (e.g. user@example.com) - placeholders are rejected.
`reportId`	Yes	REQUIRED. The reportId of the completed (ready) Demand Discovery Report.
`alTriggerToken`	No	Optional pass-through token from the ready report payload (report.alTriggerToken), if available.

Output Schema

TableJSON Schema

Name	Required	Description
`alId`	No	The Agentic Launch handle, if started.
`sender`	Yes	Always 'amy' for inline triggers.
`status`	Yes	started \| queued \| error \| unconfigured_fallback \| error_fallback \| needs_real_email \| email_not_owner.
`started`	Yes	True if Agentic Launch was started (prospects generated + outreach drafted, awaiting the user's review-and-send).
`manageUrl`	Yes	Where the user reviews and SENDS the drafted outreach, and manages the 90-day launch. Nothing goes out until they do.
`nextAction`	Yes	What the user should do next.
`productUrl`	Yes
`replyToEmail`	Yes	Where Amy forwards replies.

TDQS

A4.8/5.0

Behavior5/5

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

Discloses critical behavior beyond annotations: 'It sends NOTHING automatically - the user reviews and sends from their hosted manage page', plus the sender identity ('Amy @ Demand Discovery') and reply routing. This adds meaningful context that annotations (readOnlyHint=false, destructiveHint=false) do not cover.

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 somewhat lengthy but front-loaded with the purpose and key caveat. Each sentence adds value: the first introduces the action and safety, the second explains the behavior, the third gives call conditions and parameters. No fluff, though it is denser than the average tool description.

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?

The description covers prerequisites (ready report), usage triggers, parameter requirements, and the return value (manageUrl). With an output schema present and detailed annotations, this description provides a complete picture for an agent to select and invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds important semantics for the email parameter: it MUST be the user's own email from earlier in the conversation, and placeholders are rejected. This goes beyond the schema's basic format requirement, justifying a 4.

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's specific action: 'Kick off Day 1 of the 90-day Agentic Launch' for a completed Demand Discovery Report. It distinguishes from siblings by emphasizing it 'DRAFTS the first outreach batch' and 'sends NOTHING automatically', which sets it apart from tools like start_demand_report.

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?

Provides explicit when-to-use guidance: 'Call this after a paid report is "ready" and the user wants to act on it' with example user intents. It also explains the prerequisites (completed report, user's email, optional token), and clearly differentiates from the alternative of starting a new report.

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 tools Inspect

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

Need Help?