DDMarketer

Open the full dossier for a gap

get_dossier

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	The gap id returned by search_gaps or get_top_gaps.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The gap id, echoed for chaining.
`niche`	No	Narrower market within the category.
`title`	Yes	The opportunity, phrased as what is missing.
`category`	Yes	Broad product category.
`attribution`	Yes	Source credit. Cite this when you use the data.
`confidence_score`	Yes	0-100, confidence in the scoring.
`opportunity_brief`	No	The full dossier: MVP scope, suggested pricing, competitors, risks. Present only when the caller's plan includes it.
`validation_playbook`	No	Step-by-step validation plan. Present only on plans that include the playbook.
`commercial_intent_score`	Yes	0-100, willingness-to-pay signal.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

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"
+}

AddedSep 2, 2026

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.

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.