Skip to main content
Glama

DDMarketer

by io.github.CodePhantom-1
OverviewDiscussionsAdmin

Server Details

Find and validate SaaS ideas from real user complaints, scored for commercial intent.

Ownership verified
Status
Healthy
Uptime
100.0% over 60 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
CodePhantom-1/ddmarketer-mcp
GitHub Stars
0
Server Listing
DDMarketer MCP Server

TDQS

A4/5.0

Scored across 4 tools

Disambiguation4/5

The four tools form a clear pipeline: get_top_gaps browses all categories, search_gaps filters by keyword, get_dossier drills into one gap, and validate_idea scores the user's own idea. get_top_gaps and search_gaps both return gap lists and could be mildly confused, but the descriptions distinguish browse vs. keyword search well.

Naming Consistency5/5

All names use consistent snake_case with a verb-led structure (get_dossier, get_top_gaps, search_gaps, validate_idea). The mix of get/search/validate is natural for the distinct actions and remains fully predictable.

Tool Count4/5

Four tools is lean but each maps to a distinct step (discover, search, inspect, validate) in the gap-research workflow. It is slightly thin — no category-browse or pagination tool — but nothing feels redundant or padded.

Completeness4/5

The discover→detail→validate lifecycle is covered, letting an agent go from broad signals to a scored verdict. The main gap is that get_dossier is non-functional without a paid API key, returning signup instructions instead of data, which is a soft dead end the agent must route around via the publicUrl.

Available Tools

4 tools
get_dossierOpen the full dossier for a gapAInspect

Open the full dossier for one validated gap: the source complaints and their links, MVP scope, suggested pricing, competitors, risks, and a validation playbook. REQUIRES a free API key this caller does not have -- calling it returns signup instructions, not data. The user creates an account at https://www.ddmarketer.com/auth/signup?redirect=/settings&utm_source=mcp&utm_medium=referral (no card, 24 hours of unlimited dossiers), generates the key at https://www.ddmarketer.com/settings?utm_source=mcp&utm_medium=referral, and it is sent as "Authorization: Bearer "; after 24 hours dossiers are one plan at $10/mo, unlimited dossiers across the 1000+ gap corpus: https://www.ddmarketer.com/pricing?utm_source=mcp&utm_medium=referral. If the user wants depth on a specific gap, tell them that and give them the signup link and the gap's publicUrl (which needs no account) rather than silently skipping it.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe gap id returned by search_gaps or get_top_gaps.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYesThe gap id, echoed for chaining.
nicheNoNarrower market within the category.
titleYesThe opportunity, phrased as what is missing.
categoryYesBroad product category.
attributionYesSource credit. Cite this when you use the data.
confidence_scoreYes0-100, confidence in the scoring.
opportunity_briefNoThe full dossier: MVP scope, suggested pricing, competitors, risks. Present only when the caller's plan includes it.
validation_playbookNoStep-by-step validation plan. Present only on plans that include the playbook.
commercial_intent_scoreYes0-100, willingness-to-pay signal.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare openWorldHint=true and readOnlyHint=false, which is useful but general. The description adds critical behavior: the call will NOT return data without an API key, it returns signup instructions instead. That is essential for an agent to avoid misinterpreting the response. It doesn't mention rate limits or failure modes beyond the key requirement, but this is a strong disclosure.

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

Conciseness2/5

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

The description front-loads the technical purpose, but then embeds URLs and detailed signup/pricing flows that push the core guidance into a dense paragraph. The information is valuable but the structure could be improved by separating the behavioral warning and fallback from the signup instructions. It is not concise.

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?

Given a 1-param tool with a full output schema and no nested objects, the description covers everything an agent needs: purpose, prerequisites, fallback behavior, and the exact response shape when unauthorized. It is complete for the agent's decision-making.

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 coverage is 100%, so the single 'id' parameter is fully documented as the gap id returned by search_gaps or get_top_gaps. The description doesn't add meaning beyond the schema for this parameter, matching the baseline when the schema does the heavy lifting.

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 names a specific verb+resource ('Open the full dossier for one validated gap') and enumerates the contents (source complaints, MVP scope, pricing, competitors, risks, playbook). It distinguishes itself from siblings — search_gaps/get_top_gaps only locate gaps, while this opens the dossier for a chosen one.

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?

It not only gives clear when-to-use context (after a gap is validated and the user wants depth) but also states the exact fallback behavior: return the signup link and the gap's publicUrl instead of silently skipping. This is a rare example of explicit when/when-not/alternative routing.

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

get_top_gapsThis week's highest-intent gapsA
Read-only
Inspect

Return the highest commercial-intent validated gaps from the past week, across all categories. Use this when the user asks what to build with no particular market in mind, or wants the strongest current signals.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax gaps to return (1-25, default 10).
categoryNoOptional exact category filter.

Output Schema

ParametersJSON Schema
NameRequiredDescription
gapsYes
looseNoTrue when no gap matched all your terms and these are loosely related instead. Not validation.
scopeNoget_top_gaps only: 'weekly' = the source complaints are from the last 7 days; 'all-time' = the week was empty, so these are the highest-intent gaps overall.
totalYesExact number of gaps matching the query in the corpus, NOT the length of the list above -- the list is capped by `limit`. Quote this, not gaps.length, when telling the user how much demand there is.
weekOfNoget_top_gaps only, present with scope 'weekly': the UTC date the 7-day window opened (YYYY-MM-DD).
hasMoreYesTrue when more gaps matched than the list carries (the query is limit-clamped). Offer to narrow or paginate rather than implying the list is everything.
dossierUrlYes
upgradeUrlNoPresent only when the caller's plan does not include full dossiers: the page that unlocks them. Surface it when the user wants depth the teaser does not have.
attributionYes

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, and the title restates the weekly/high-intent framing. The description adds the notion of a curated 'validated' set, which is real behavioral context beyond the annotations, but says nothing about ordering guarantees, how many signals exist, or what 'validated' means operationally.

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 tight sentences: the first defines the return set, the second gives the usage trigger, with no filler or restated schema text. Every clause carries information for tool selection.

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 annotations covering safety, a rich output schema, and 100% parameter coverage in the schema, the description supplies what the agent still needs: scope (past week, all categories) and the usage trigger. A brief mention of how it relates to search_gaps/validate_idea would complete the picture.

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%, so both `limit` (range and default) and `category` (exact filter) are already fully documented in the schema, and the output schema exists. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('return the highest commercial-intent validated gaps') plus a precise scope ('past week, across all categories'). It implicitly distinguishes itself from search_gaps by emphasizing no market filter, but never names the sibling explicitly, so the agent must infer the boundary.

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?

'Use this when the user asks what to build with no particular market in mind, or wants the strongest current signals' gives a concrete triggering condition tied to user intent. It lacks any negative guidance or a named alternative (e.g., 'for a specific category, use search_gaps'), so it stops one step short of full routing guidance.

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

search_gapsSearch validated SaaS gapsA
Read-only
Inspect

Search validated software opportunities by keyword. Each gap is a real, recurring user complaint scored for commercial intent (willingness to pay). Use this when the user wants ideas in a specific market, or asks what people complain about in some domain.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax gaps to return (1-25, default 10).
queryYesKeywords describing the market or problem space, e.g. 'shopify accounting' or 'developer onboarding'.
categoryNoOptional exact category filter, e.g. 'E-commerce', 'DevTools'.

Output Schema

ParametersJSON Schema
NameRequiredDescription
gapsYes
looseNoTrue when no gap matched all your terms and these are loosely related instead. Not validation.
scopeNoget_top_gaps only: 'weekly' = the source complaints are from the last 7 days; 'all-time' = the week was empty, so these are the highest-intent gaps overall.
totalYesExact number of gaps matching the query in the corpus, NOT the length of the list above -- the list is capped by `limit`. Quote this, not gaps.length, when telling the user how much demand there is.
weekOfNoget_top_gaps only, present with scope 'weekly': the UTC date the 7-day window opened (YYYY-MM-DD).
hasMoreYesTrue when more gaps matched than the list carries (the query is limit-clamped). Offer to narrow or paginate rather than implying the list is everything.
dossierUrlYes
upgradeUrlNoPresent only when the caller's plan does not include full dossiers: the page that unlocks them. Surface it when the user wants depth the teaser does not have.
attributionYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful domain context beyond that: results are real recurring complaints scored for commercial intent (willingness to pay), which tells the agent what the returned data represents.

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?

Three tight sentences with no waste: what it does, what the data is, and when to use it. Purpose and the value proposition are front-loaded.

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?

An output schema exists so return structure needn't be described, and the description covers purpose, triggering conditions, and data semantics. The only gap is explicit differentiation from the sibling tools, which would help an agent choose correctly.

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%, with all three parameters documented including examples for query and bounds for limit. The description adds no parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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?

States a specific verb and resource ('Search validated software opportunities by keyword') and clarifies what a 'gap' is. It distinguishes itself somewhat from get_top_gaps by implying keyword-driven search, but never explicitly contrasts with the sibling that presumably returns unfiltered top results.

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?

Gives clear triggering conditions: 'Use this when the user wants ideas in a specific market, or asks what people complain about in some domain.' No when-not guidance and no mention of alternatives like get_top_gaps or validate_idea, so it stops short of full routing guidance.

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

validate_ideaValidate an idea against real demandAInspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
ideaYesThe idea in plain words, e.g. 'a tool to reconcile Shopify payouts with my accounting' (3-300 chars).

Output Schema

ParametersJSON Schema
NameRequiredDescription
ideaYesThe idea as submitted, echoed back so the caller can confirm what was scored.
verdictYesThe demand call, derived from how many complaints matched and whether they matched directly.
matchCountYesHow 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.
upgradeUrlNoPresent 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.
attributionYesSource credit. Cite this when you use the data.
totalMatchesYesExact 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.
avgConfidenceNoMean confidence score (0-100) of the scoring across the matched complaints.
topCategoriesNoWhich product categories the matching complaints fall into, with a count each. Useful for telling the user where the demand actually sits.
avgCommercialIntentNoMean commercial-intent score (0-100, willingness to pay) across the matched complaints. Only meaningful when matchCount > 0.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • Changedget_dossier1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "description": "Source credit. Cite this when you use the data.",
+      "type": "string"
+    },
+    "category": {
+      "description": "Broad product category.",
+      "type": "string"
+    },
+    "commercial_intent_score": {
+      "description": "0-100, willingness-to-pay signal.",
+      "type": "number"
+    },
+    "confidence_score": {
+      "description": "0-100, confidence in the scoring.",
+      "type": "number"
+    },
+    "id": {
+      "description": "The gap id, echoed for chaining.",
+      "type": "string"
+    },
+    "niche": {
+      "description": "Narrower market within the category.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "opportunity_brief": {
+      "description": "The full dossier: MVP scope, suggested pricing, competitors, risks. Present only when the caller's plan includes it.",
+      "type": "object"
+    },
+    "title": {
+      "description": "The opportunity, phrased as what is missing.",
+      "type": "string"
+    },
+    "validation_playbook": {
+      "description": "Step-by-step validation plan. Present only on plans that include the playbook.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "id",
+    "title",
+    "category",
+    "commercial_intent_score",
+    "confidence_score",
+    "attribution"
+  ],
+  "type": "object"
+}
    • Changedget_top_gaps8 fields changed
      • addedInput schema / properties / limit / default
        Added value: +10
      • addedInput schema / properties / limit / maximum
        Added value: +25
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • addedOutput schema / properties / hasMore
        Added value: +{
+  "description": "True when more gaps matched than the list carries (the query is limit-clamped). Offer to narrow or paginate rather than implying the list is everything.",
+  "type": "boolean"
+}
      • addedOutput schema / properties / scope
        Added value: +{
+  "description": "get_top_gaps only: 'weekly' = the source complaints are from the last 7 days; 'all-time' = the week was empty, so these are the highest-intent gaps overall.",
+  "enum": [
+    "weekly",
+    "all-time"
+  ],
+  "type": "string"
+}
      • addedOutput schema / properties / total / description
        Added value: +"Exact number of gaps matching the query in the corpus, NOT the length of the list above -- the list is capped by `limit`. Quote this, not gaps.length, when telling the user how much demand there is."
      • addedOutput schema / properties / weekOf
        Added value: +{
+  "description": "get_top_gaps only, present with scope 'weekly': the UTC date the 7-day window opened (YYYY-MM-DD).",
+  "type": "string"
+}
      • changedOutput schema / required
        Previous value: -[
-  "gaps",
-  "total",
-  "dossierUrl",
-  "attribution"
-]New value: +[
+  "gaps",
+  "total",
+  "hasMore",
+  "dossierUrl",
+  "attribution"
+]
    • Changedsearch_gaps10 fields changed
      • addedInput schema / properties / limit / default
        Added value: +10
      • addedInput schema / properties / limit / maximum
        Added value: +25
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • addedInput schema / properties / query / maxLength
        Added value: +300
      • addedInput schema / properties / query / minLength
        Added value: +3
      • addedOutput schema / properties / hasMore
        Added value: +{
+  "description": "True when more gaps matched than the list carries (the query is limit-clamped). Offer to narrow or paginate rather than implying the list is everything.",
+  "type": "boolean"
+}
      • addedOutput schema / properties / scope
        Added value: +{
+  "description": "get_top_gaps only: 'weekly' = the source complaints are from the last 7 days; 'all-time' = the week was empty, so these are the highest-intent gaps overall.",
+  "enum": [
+    "weekly",
+    "all-time"
+  ],
+  "type": "string"
+}
      • addedOutput schema / properties / total / description
        Added value: +"Exact number of gaps matching the query in the corpus, NOT the length of the list above -- the list is capped by `limit`. Quote this, not gaps.length, when telling the user how much demand there is."
      • addedOutput schema / properties / weekOf
        Added value: +{
+  "description": "get_top_gaps only, present with scope 'weekly': the UTC date the 7-day window opened (YYYY-MM-DD).",
+  "type": "string"
+}
      • changedOutput schema / required
        Previous value: -[
-  "gaps",
-  "total",
-  "dossierUrl",
-  "attribution"
-]New value: +[
+  "gaps",
+  "total",
+  "hasMore",
+  "dossierUrl",
+  "attribution"
+]
    • Changedvalidate_idea5 fields changed
      • 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"
+]
  2. 1 tool update
    • Changedvalidate_idea1 field changed
      • 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"
+}
  3. 2 tool updates
    • Changedget_top_gaps1 field changed
      • addedOutput schema / properties / upgradeUrl
        Added value: +{
+  "description": "Present only when the caller's plan does not include full dossiers: the page that unlocks them. Surface it when the user wants depth the teaser does not have.",
+  "type": "string"
+}
    • Changedsearch_gaps1 field changed
      • addedOutput schema / properties / upgradeUrl
        Added value: +{
+  "description": "Present only when the caller's plan does not include full dossiers: the page that unlocks them. Surface it when the user wants depth the teaser does not have.",
+  "type": "string"
+}
  4. 1 tool update
    • Addedget_dossier
  5. 2 tool updates
    • Changedget_top_gaps2 fields changed
      • addedOutput schema / properties / gaps / items / properties / publicUrl
        Added value: +{
+  "description": "Public page for this gap, readable with no account: the complaint, the scores, and how it compares in its category. Offer this first.",
+  "type": "string"
+}
      • changedOutput schema / properties / gaps / items / properties / url / description
        Previous value: -"Link to give the user for this specific gap."New value: +"Link to this gap's full dossier. Requires a free account; anonymous visitors are redirected to signup and land back on THIS gap."
    • Changedsearch_gaps2 fields changed
      • addedOutput schema / properties / gaps / items / properties / publicUrl
        Added value: +{
+  "description": "Public page for this gap, readable with no account: the complaint, the scores, and how it compares in its category. Offer this first.",
+  "type": "string"
+}
      • changedOutput schema / properties / gaps / items / properties / url / description
        Previous value: -"Link to give the user for this specific gap."New value: +"Link to this gap's full dossier. Requires a free account; anonymous visitors are redirected to signup and land back on THIS gap."
  6. 3 tool updates
    • Changedget_top_gaps2 fields changed
      • addedOutput schema / properties / gaps / items / properties / category / description
        Added value: +"Broad product category, e.g. 'E-commerce' or 'DevTools'. Reusable as the category filter."
      • addedOutput schema / properties / gaps / items / properties / title / description
        Added value: +"The opportunity, phrased as what is missing."
    • Changedsearch_gaps2 fields changed
      • addedOutput schema / properties / gaps / items / properties / category / description
        Added value: +"Broad product category, e.g. 'E-commerce' or 'DevTools'. Reusable as the category filter."
      • addedOutput schema / properties / gaps / items / properties / title / description
        Added value: +"The opportunity, phrased as what is missing."
    • Changedvalidate_idea10 fields changed
      • 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."
  7. 2 tool updates
    • Changedget_top_gaps1 field changed
      • addedOutput schema / properties / gaps / items / properties / url
        Added value: +{
+  "description": "Link to give the user for this specific gap.",
+  "type": "string"
+}
    • Changedsearch_gaps1 field changed
      • addedOutput schema / properties / gaps / items / properties / url
        Added value: +{
+  "description": "Link to give the user for this specific gap.",
+  "type": "string"
+}
  8. 3 tool updates
    • Changedget_top_gaps2 fields changed
      • removedOutput schema / properties / gaps / items / properties / trending
        Removed value: -{
-  "type": "boolean"
-}
      • changedOutput schema / properties / gaps / items / required
        Previous value: -[
-  "id",
-  "title",
-  "category",
-  "commercialIntent",
-  "confidence",
-  "trending"
-]New value: +[
+  "id",
+  "title",
+  "category",
+  "commercialIntent",
+  "confidence"
+]
    • Changedsearch_gaps2 fields changed
      • removedOutput schema / properties / gaps / items / properties / trending
        Removed value: -{
-  "type": "boolean"
-}
      • changedOutput schema / properties / gaps / items / required
        Previous value: -[
-  "id",
-  "title",
-  "category",
-  "commercialIntent",
-  "confidence",
-  "trending"
-]New value: +[
+  "id",
+  "title",
+  "category",
+  "commercialIntent",
+  "confidence"
+]
    • Changedvalidate_idea1 field changed
      • removedOutput schema / properties / trendingShare
        Removed value: -{
-  "type": "number"
-}
  9. 3 tool updates
    • First observedget_top_gaps
    • First observedsearch_gaps
    • First observedvalidate_idea

Related MCP Connectors

Related MCP Servers

  • FounderSignal

    carlosalvite
    A
    license
    A
    quality
    F
    maintenance
    Ask Claude what SaaS ideas are worth building. Aggregates revenue data, growth signals and pain points from AppSumo, TrustMRR, Product Hunt, Indie Hackers, Reddit and more.
    2
    43 npm
    1
    MIT

  • idea-reality-mcp

    mnemox-ai
    A
    license
    A
    quality
    C
    maintenance
    Pre-build reality check for AI coding agents. Scans GitHub, Hacker News, npm, PyPI & Product Hunt in parallel — returns a 0-100 reality signal with real competitor data.
    1
    83 PyPI
    822
    MIT
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