DDMarketer

Validate an idea against real demand

validate_idea

Score a specific product idea against the complaint corpus: how many real complaints match it, how commercial they are, how confident the scoring is, and a verdict. Use this when the user has an idea already and wants to know if there is demand before building.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`idea`	Yes	The idea in plain words, e.g. 'a tool to reconcile Shopify payouts with my accounting' (3-300 chars).

Output Schema

TableJSON Schema

Name	Required	Description
`idea`	Yes	The idea as submitted, echoed back so the caller can confirm what was scored.
`verdict`	Yes	The demand call, derived from how many complaints matched and whether they matched directly.
`matchCount`	Yes	How many complaints were scanned and aggregated into the stats below. When verdict.level is 'weak' because only loosely related complaints were found, this counts those loose matches, which do NOT validate the idea. Never report matchCount as direct evidence without checking verdict.level.
`upgradeUrl`	No	Present only when the caller's plan does not include full dossiers: the page that unlocks the matched complaints and their source links. Surface it when the user wants the underlying evidence.
`attribution`	Yes	Source credit. Cite this when you use the data.
`totalMatches`	Yes	Exact total complaints matching in the corpus, even when only the highest-intent ones were scanned (matchCount). Differs from matchCount when demand exceeds the scan window; quote THIS as the breadth of the signal.
`avgConfidence`	No	Mean confidence score (0-100) of the scoring across the matched complaints.
`topCategories`	No	Which product categories the matching complaints fall into, with a count each. Useful for telling the user where the demand actually sits.
`avgCommercialIntent`	No	Mean commercial-intent score (0-100, willingness to pay) across the matched complaints. Only meaningful when matchCount > 0.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 28, 2026

addedInput schema / properties / idea / maxLength
```
Added value: +300
```
addedInput schema / properties / idea / minLength
```
Added value: +3
```

changedOutput schema / properties / matchCount / description

Previous value: -"How many complaints matched. IMPORTANT: when verdict.level is 'weak' because only loosely related complaints were found, this counts those loose matches, which do NOT validate the idea. Never report matchCount as direct evidence without checking verdict.level."New value: +"How many complaints were scanned and aggregated into the stats below. When verdict.level is 'weak' because only loosely related complaints were found, this counts those loose matches, which do NOT validate the idea. Never report matchCount as direct evidence without checking verdict.level."

addedOutput schema / properties / totalMatches

Added value: +{
+  "description": "Exact total complaints matching in the corpus, even when only the highest-intent ones were scanned (matchCount). Differs from matchCount when demand exceeds the scan window; quote THIS as the breadth of the signal.",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "idea",
-  "verdict",
-  "matchCount",
-  "attribution"
-]New value: +[
+  "idea",
+  "verdict",
+  "matchCount",
+  "totalMatches",
+  "attribution"
+]

Changed1 schema field changedSep 5, 2026

addedOutput schema / properties / upgradeUrl

Added value: +{
+  "description": "Present only when the caller's plan does not include full dossiers: the page that unlocks the matched complaints and their source links. Surface it when the user wants the underlying evidence.",
+  "type": "string"
+}

Changed10 schema fields changedAug 29, 2026

addedOutput schema / properties / attribution / description

Added value: +"Source credit. Cite this when you use the data."

addedOutput schema / properties / avgCommercialIntent / description

Added value: +"Mean commercial-intent score (0-100, willingness to pay) across the matched complaints. Only meaningful when matchCount > 0."

addedOutput schema / properties / avgConfidence / description

Added value: +"Mean confidence score (0-100) of the scoring across the matched complaints."

addedOutput schema / properties / idea / description

Added value: +"The idea as submitted, echoed back so the caller can confirm what was scored."

addedOutput schema / properties / matchCount / description

Added value: +"How many complaints matched. IMPORTANT: when verdict.level is 'weak' because only loosely related complaints were found, this counts those loose matches, which do NOT validate the idea. Never report matchCount as direct evidence without checking verdict.level."

addedOutput schema / properties / topCategories / description

Added value: +"Which product categories the matching complaints fall into, with a count each. Useful for telling the user where the demand actually sits."

addedOutput schema / properties / verdict / description

Added value: +"The demand call, derived from how many complaints matched and whether they matched directly."

addedOutput schema / properties / verdict / properties / detail / description

Added value: +"The reasoning behind the level and the recommended next step. Surface this to the user rather than paraphrasing the level alone."

addedOutput schema / properties / verdict / properties / headline / description
```
Added value: +"One-line summary of the level."
```

addedOutput schema / properties / verdict / properties / level / description

Added value: +"strong = 5+ direct matches; moderate = 2-4 direct; weak = 1 direct match, OR only loosely related complaints were found; none = nothing matched. Only strong and moderate are evidence of demand."

Changed1 schema field changedAug 28, 2026
- removedOutput schema / properties / trendingShare
```
Removed value: -{
-  "type": "number"
-}
```
First observedAug 14, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is partly covered. The description explains what the scoring dimensions are but never discloses why this is not read-only (e.g., whether the idea or score is persisted) or what the open-world lookup entails, leaving a gap the annotations only imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences, no filler, and the scoring scope is front-loaded before the usage condition. Every clause earns its place and nothing is repeated from the schema.

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 one fully documented parameter and an output schema covering return values, the description only needed to convey purpose and usage, which it does. The remaining gap is the unexplained non-read-only behavior, which an agent would benefit from knowing.

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?

There is a single parameter with 100% schema description coverage, including an inline example and length constraints, so the schema carries the load. The description adds a time/context cue ('idea already') but no format guidance beyond the schema, matching the baseline for high-coverage schemas.

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 states a specific verb and resource: score a product idea against the complaint corpus. It also enumerates the four outputs (match count, commerciality, confidence, verdict), making it unmistakable against siblings get_dossier, get_top_gaps, and search_gaps.

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

Usage Guidelines4/5

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

It explicitly scopes usage to 'when the user has an idea already and wants to know if there is demand before building', which is a clear triggering condition. It does not name an alternative sibling or a when-not-to-use case, so it stops short of a 5.

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

All DDMarketer tools Inspect

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.