@clien-ai/mcp

What changed

Changed between 4 September 2026 and 5 October 2026 (first seen 2026-10-05 14:34 UTC)

7 descriptions rewritten, 3 schema or annotation changes with the description left byte-identical, 5 tools added.

+ tool added: add_project_text

+ tool added: cancel_research

--- pinned/clien_research
+++ observed/clien_research
  {
-   "description": "Run a full product-research pass on an idea — the recommended default for validating a new idea end to end. Returns a markdown report, FOLLOWED IN THE SAME TEXT by a machine-checked TRUST DIGEST — read the digest rather than trusting the prose. It states every claim's GROUNDED / SPECULATION / NO_RECEIPT state with its receipt id, the separate market/competitor spine, which personas are ⚠️ QA-FLAGGED, and the anti-sycophancy readout. The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. When a section is missing the digest says so — absent is not clean. The digest also states the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. The full structured report_data (framing, methodology, safe interview highlights, hypotheses, competitors[], key findings) is mirrored to host-side `_meta.report_data` for programmatic use by your MCP client; everything YOU need to reason is already in the result text above it. Raw typed `report_data` states, source ids, and attestation markers are stored audit data, not citation eligibility. Only the machine-checked TRUST DIGEST's rendered state and receipt arrow authorize Cited: the digest must resolve a canonical, spine-owned pointer to a safe reachable HTTP(S) destination. Dangling, malformed, cross-persona, unsafe, credentialed, or incomplete pointers degrade without an arrow and MUST NOT be cited. report_data carries this same typed TRUST layer: (1) `claims[]` — each has a stored GROUNDED / SPECULATION / NO_RECEIPT state and may carry a `sourceId` of the form \"RCP-p{i}-s{j}\" into `personas[i].sources[j]`; use the digest, not this raw pointer, to decide whether the claim earned Cited. One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. NO_RECEIPT can mean a bad claim OR merely sparse evidence — cross-check `personas[].insufficientEvidence` / `sourcesFound` before discounting it. (2) `hypothesisResults[].final` — the versioned effective verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. Prefer this block over the raw top-level `status`/numeric `confidence`; the digest validates its version and refuses any attempted verdict upgrade. The sibling `robustness` block supplies the inspectable `survived`/`total` working. (3) `personas[]` — besides `sources[]` receipts, check `qaFlagged` (persona failed a quality check) before relying on its claims. Two DIFFERENT grounding models ride here: forum `sources[]` are receipt-eligible clickable posts, whereas `identityProvenance` (when present) is a PII-free aggregate calibration line (\"calibrated against N real ICP profiles\") — NEVER a receipt, so do not treat it as a source URL; `identityPriors` (seniority + career path) is typed enrichment, not a receipt either. (4) `sycophancySignals` — broken-persona flags (`lowDiscrimination`), disagreement splits, and explicit `totalRejections`. (5) `reportClaims[]` — the SEPARATE market/competitor spine (never crosses the persona one): each stored GROUNDED / SPECULATION / NO_RECEIPT, and may carry a `sourceId` of the form \"RRCP-s{n}\" into `reportEvidence[n]` (its own pool). On THIS spine a NO_RECEIPT claim has one of two provenance readings: only when its complete `attestation` marker ({sourceId, quote}) resolves in the digest to a safe receipt with an arrow is it \"Cited\" — Claude read a supporting page and an independent check vouched it supports the figure, though no exact quote could be pinned (stronger than recall, but NOT a verified receipt; its `attestation.sourceId` indexes `reportEvidence[n]` the same way, but a marker's presence NEVER implies grounding — key on the digest's rendered state and arrow, not raw state/sourceId); otherwise it is \"unsourced\": an evidence-shaped figure Claude wrote from its own training knowledge that could not be verified against a source — often directionally right (a recalled analyst estimate), but treat it as unconfirmed, NOT as a checked fact. Neither reading is ever counted as grounded. (6) The typed `openQuestions[]` field is mirrored for your MCP client at host-side `_meta.report_data.openQuestions`; because host `_meta` is not reliably model-visible, YOU should use the model-visible result text's `## Open Questions` section. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the model-visible result text under \"## Verdict rationale\" — READ IT THERE. The typed field is mirrored for your MCP client at host-side `_meta.report_data.verdictSummary`, which is not reliably model-visible: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. Typical wall time 15-25 minutes; progress is streamed via notifications/progress. This hero tool runs the whole curated pipeline in one call. PREFER it over hand-assembling a full validation from the granular primitives (create_persona + interview_persona + get_report) — those are for targeted, cheaper spot-checks, not a complete report; sequencing them yourself gives lower-quality coverage. See docs/recipes/ for the supported compositions (competitor spot-check, pivot viability, new-market persona validation). ALWAYS attach the run to a project so the report is visible in the Clien.ai web app: pass `project_name` to create a new project (derive a short 2-4 word name from the idea), or `project_id` to reuse an existing one — a run with neither is refused. First call opens a browser for one-time OAuth login; subsequent calls reuse the stored refresh token. IMPORTANT: if this call fails mid-flight with \"MCP error -32000: Connection closed\", do NOT call clien_research again — that spawns a new run and debits credits again for the same idea. Instead call `clien_research_status` with NO arguments — it finds your recent run(s) and lists them so you can pick the one you were researching. The dropped call's error text usually carries the job_id too, and you can pass it directly if you have it. (The id is also in the `[clien-mcp] research started job_id=…` stderr line and in host-side `_meta.job_id`, but both reach the operator's MCP client rather than you.)",
+   "description": "Run a full product-research pass on an idea — the recommended default for validating a new idea end to end. Returns a markdown report, FOLLOWED IN THE SAME TEXT by a machine-checked TRUST DIGEST — read the digest rather than trusting the prose. It states every claim's GROUNDED / SPECULATION / NO_RECEIPT state with its receipt id, the separate market/competitor spine, which personas are ⚠️ QA-FLAGGED, and the anti-sycophancy readout. The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. When a section is missing the digest says so — absent is not clean. The digest also states the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness and is EXCLUDED from automatic community synthesis. It is also excluded from grounding except that a producer-resolved hypothesis receipt may support only a capability about that same named vendor; never cite it as user evidence or independent market evidence. `unclassified` is EXCLUDED from both grounding and automatic community synthesis, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, `quotesByHypothesis`, and content-addressed `evidenceReference` quote ids — internal `researchTaskId` is excluded. Typed `marketOverview` and `communityOverview` carry generated prose plus exact `claimSpans`; only the code-derived overview trust rows below the separator authorize Cited, and dangling or private references degrade to Unsourced. Fresh reports also carry `crossCuttingFindings[]`; their evidence is resolved inline and legacy Insights are suppressed. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. The full structured report_data (framing, methodology, safe interview highlights, hypotheses, competitors[], key findings) is mirrored to host-side `_meta.report_data` for programmatic use by your MCP client; everything YOU need to reason is already in the result text above it. Raw typed `report_data` states, source ids, and attestation markers are stored audit data, not citation eligibility. Only the machine-checked TRUST DIGEST's rendered state and receipt arrow authorize Cited: the digest must resolve a canonical, spine-owned pointer. Report and persona receipts require a safe reachable HTTP(S) destination; an overview forum receipt may instead expose its exact bounded cached excerpt when the destination is withheld. Outside that cached-excerpt exception, dangling, malformed, cross-persona, unsafe, credentialed, or incomplete pointers degrade without an arrow and MUST NOT be cited. report_data carries this same typed TRUST layer: (1) `claims[]` — each has a stored GROUNDED / SPECULATION / NO_RECEIPT state and may carry a `sourceId` of the form \"RCP-p{i}-s{j}\" into `personas[i].sources[j]`; use the digest, not this raw pointer, to decide whether the claim earned Cited. One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. NO_RECEIPT can mean a bad claim OR merely sparse evidence — cross-check `personas[].insufficientEvidence` / `sourcesFound` before discounting it. (2) `hypothesisResults[].final` — the versioned effective verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. Prefer this block over the raw top-level `status`/numeric `confidence`; the digest validates its version and refuses any attempted verdict upgrade. The sibling `robustness` block supplies the inspectable `survived`/`total` working. (3) `personas[]` — besides `sources[]` receipts, check `qaFlagged` (persona failed a quality check) before relying on its claims. Two DIFFERENT grounding models ride here: forum `sources[]` are receipt-eligible clickable posts, whereas `identityProvenance` (when present) is a PII-free aggregate calibration line (\"calibrated against N real ICP profiles\") — NEVER a receipt, so do not treat it as a source URL; `identityPriors` (seniority + career path) is typed enrichment, not a receipt either. (4) `sycophancySignals` — broken-persona flags (`lowDiscrimination`), disagreement splits, and explicit `totalRejections`. (5) `reportClaims[]` — the SEPARATE market/competitor spine (never crosses the persona one): each stored GROUNDED / SPECULATION / NO_RECEIPT, and may carry a `sourceId` of the form \"RRCP-s{n}\" into `reportEvidence[n]` (its own pool). On THIS spine a NO_RECEIPT claim has one of two provenance readings: only when its complete `attestation` marker ({sourceId, quote}) resolves in the digest to a safe receipt with an arrow is it \"Cited\" — Claude read a supporting page and an independent check vouched it supports the figure, though no exact quote could be pinned (stronger than recall, but NOT a verified receipt; its `attestation.sourceId` indexes `reportEvidence[n]` the same way, but a marker's presence NEVER implies grounding — key on the digest's rendered state and arrow, not raw state/sourceId); otherwise it is \"unsourced\": an evidence-shaped figure Claude wrote from its own training knowledge that could not be verified against a source — often directionally right (a recalled analyst estimate), but treat it as unconfirmed, NOT as a checked fact. Neither reading is ever counted as grounded. (6) The typed `openQuestions[]` field is mirrored for your MCP client at host-side `_meta.report_data.openQuestions`; because host `_meta` is not reliably model-visible, YOU should use the model-visible result text's `## Open Questions` section. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the model-visible result text under \"## Verdict rationale\" — READ IT THERE. The typed field is mirrored for your MCP client at host-side `_meta.report_data.verdictSummary`, which is not reliably model-visible: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. Typical wall time 15-25 minutes; progress is streamed via notifications/progress. This hero tool runs the whole curated pipeline in one call. PREFER it over hand-assembling a full validation from the granular primitives (create_persona + interview_persona + get_report) — those are for targeted, cheaper spot-checks, not a complete report; sequencing them yourself gives lower-quality coverage. See docs/recipes/ for the supported compositions (competitor spot-check, pivot viability, new-market persona validation). ALWAYS attach the run to a project so the report is visible in the Clien.ai web app: pass `project_name` to create a new project (derive a short 2-4 word name from the idea), or `project_id` to reuse an existing one — a run with neither is refused. First call opens a browser for one-time OAuth login; subsequent calls reuse the stored refresh token. IMPORTANT: if this call fails mid-flight with \"MCP error -32000: Connection closed\", do NOT call clien_research again — that spawns a new run and debits credits again for the same idea. Instead call `clien_research_status` with NO arguments — it finds your recent run(s) and lists them so you can pick the one you were researching. The dropped call's error text usually carries the job_id too, and you can pass it directly if you have it. (The id is also in the `[clien-mcp] research started job_id=…` stderr line and in host-side `_meta.job_id`, but both reach the operator's MCP client rather than you.)",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {
+       "operation_id": {
+         "description": "Recommended: a UUID you generate for this one paid start and keep. If the call is cut off (a timeout, a dropped connection) call again with the SAME operation_id and the SAME other inputs: if the first attempt did start, you get that run back and are not charged again. If you leave it unset, the tool picks one and reports it only when a failure is worth retrying — which a connection that dies before the tool returns can never do. Never reuse an operation_id for a different request — that is refused.",
+         "format": "uuid",
+         "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+         "type": "string"
+       },
        "project_id": {
          "description": "Clien.ai project UUID to attach this run to. Omit it to create a brand-new project instead — but then you MUST pass `project_name`. Reuse an existing project_id only for follow-up research the user explicitly asks to add to a prior run on the same idea.",
          "format": "uuid",

--- pinned/clien_research_status
+++ observed/clien_research_status
  {
-   "description": "Fetch the current state of an existing `clien_research` job. Use this to recover a run that disconnected with -32000 mid-flight (the job keeps running on the backend; this tool re-attaches a read view) and to poll for completion. If the job is complete, returns the full markdown report — followed in the same text by the same machine-checked TRUST DIGEST `clien_research` renders (claim states + receipt ids, QA-flagged personas, and the anti-sycophancy readout). One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. The digest also states the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. The structured report_data behind that digest is mirrored to host-side `_meta`, the same shape `clien_research` would have returned, but it is the result text you read. A recovered run therefore loses none of the trust signal a completed run would have shown. The typed `openQuestions[]` field is mirrored for your MCP client at host-side `_meta.report_data.openQuestions`; because host `_meta` is not reliably model-visible, YOU should use the model-visible result text's `## Open Questions` section. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the model-visible result text under \"## Verdict rationale\" — READ IT THERE. The typed field is mirrored for your MCP client at host-side `_meta.report_data.verdictSummary`, which is not reliably model-visible: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. If the job is still running, returns a brief status summary. If the job failed or was cancelled, returns the failure reason. RECOVERY WITHOUT A JOB_ID: if the -32000 drop left you with no job_id, call this tool with NO arguments — it discovers your recent run(s). If exactly one is in flight it resumes it automatically; if several come back, it returns a list of runs each with a job_id and an idea snippet — re-call with the job_id whose idea matches the run you were executing (never guess, so run A never receives run B's report). Read-only: no credit cost, no side effects.",
+   "description": "Fetch the current state of an existing `clien_research` job. Use this to recover a run that disconnected with -32000 mid-flight (the job keeps running on the backend; this tool re-attaches a read view) and to poll for completion. If the job is complete, returns the full markdown report — followed in the same text by the same machine-checked TRUST DIGEST `clien_research` renders (claim states + receipt ids, QA-flagged personas, and the anti-sycophancy readout). One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. The digest also states the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness and is EXCLUDED from automatic community synthesis. It is also excluded from grounding except that a producer-resolved hypothesis receipt may support only a capability about that same named vendor; never cite it as user evidence or independent market evidence. `unclassified` is EXCLUDED from both grounding and automatic community synthesis, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, `quotesByHypothesis`, and content-addressed `evidenceReference` quote ids — internal `researchTaskId` is excluded. Typed `marketOverview` and `communityOverview` carry generated prose plus exact `claimSpans`; only the code-derived overview trust rows below the separator authorize Cited, and dangling or private references degrade to Unsourced. Fresh reports also carry `crossCuttingFindings[]`; their evidence is resolved inline and legacy Insights are suppressed. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. The structured report_data behind that digest is mirrored to host-side `_meta`, the same shape `clien_research` would have returned, but it is the result text you read. A recovered run therefore loses none of the trust signal a completed run would have shown. The typed `openQuestions[]` field is mirrored for your MCP client at host-side `_meta.report_data.openQuestions`; because host `_meta` is not reliably model-visible, YOU should use the model-visible result text's `## Open Questions` section. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the model-visible result text under \"## Verdict rationale\" — READ IT THERE. The typed field is mirrored for your MCP client at host-side `_meta.report_data.verdictSummary`, which is not reliably model-visible: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. If the job is still running, returns a brief status summary. If the job failed or was cancelled, returns the failure reason. RECOVERY WITHOUT A JOB_ID: if the -32000 drop left you with no job_id, call this tool with NO arguments — it discovers your recent run(s). If exactly one is in flight it resumes it automatically; if several come back, it returns a list of runs each with a job_id and an idea snippet — re-call with the job_id whose idea matches the run you were executing (never guess, so run A never receives run B's report). Read-only: no credit cost, no side effects.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {

--- pinned/get_market
+++ observed/get_market
  {
-   "description": "Read a Clien.ai project's MARKET SNAPSHOT — the third cross-run research dossier, alongside `list_competitors` and `list_community_signals`. Returns market size, growth trend, key trends and positioning gaps as readable text, plus the id of the run that produced them and when it was last updated; the full record is also returned as `structuredContent.market` (mirrored in `_meta`). Requires a `project_id` — call `list_projects` to find one. ONE RUN, ONE SNAPSHOT: unlike the two collections, market is a SINGLETON — one row per project, replaced whole. Every field returned was written together by the single research run named in `sourceRunId`, never assembled from several runs, so a figure you quote can always be attributed to a specific run. Pass that id to `get_report` for the run behind the numbers. NO SNAPSHOT IS NOT AN EMPTY MARKET: a project can legitimately have none, because a completed run that did no web research writes nothing here. The tool says so explicitly and you must not convert it into a claim — \"no market data on record\" is the only statement it supports, never \"the market is small\", \"unmeasured\" or zero. A run that DID research the web and recorded nothing is reported as its own, differently-worded case. TRUST: the figures here carry NO trust state. A market figure's grounding lives in its source run's claim spine, not on the snapshot, so treat everything returned as recorded rather than verified — cite it only after reading the source run with `get_report`, whose market claims carry GROUNDED / SPECULATION / NO_RECEIPT states and their receipts. This is a free read of persisted state — it never researches anything. Read-only: no credit cost, no side effects.",
+   "description": "Read a Clien.ai project's MARKET SNAPSHOT — the third cross-run research dossier, alongside `list_competitors` and `list_community_signals`. Returns strict cited `marketSignals` as readable result text and `structuredContent.marketSignals`, alongside the raw legacy snapshot in `structuredContent.market`; both are mirrored in host-side `_meta`. Requires a `project_id` — call `list_projects` to find one. ONE ROW, VERIFIED ATTRIBUTION: unlike the two collections, market is a SINGLETON — one row per project, replaced whole. Attribute current fields to `sourceRunId` only when `sourceBindingState` is `bound` or `bound_empty`; otherwise every field is unattributable recorded context. When bound, the current fields were never assembled from several runs. Legacy market-size context is always exempt from run attribution and strict sizing. Pass a verified id to `get_report`. NO SNAPSHOT IS NOT AN EMPTY MARKET: a project can legitimately have none, because a completed run that did no web research writes nothing here. The tool says so explicitly and you must not convert it into a claim — \"no market data on record\" is the only statement it supports, never \"the market is small\", \"unmeasured\" or zero. A run that DID research the web and recorded nothing is reported as its own, differently-worded case. TRUST: strict market signals survived exact claim/receipt or derivation checks and include the source URL(s) required when citing them. Raw snapshot fields remain neutral recorded context; inspect the source run with `get_report` and its claim spine before citing raw figures. \"No cited market signals were established\" means no candidate survived strict proof, not that the market or the raw snapshot is empty, small, or zero. This is a free read of persisted state — it never researches anything. Read-only: no credit cost, no side effects.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {
-         "description": "UUID of the project whose market snapshot to read. Get it from `list_projects` (or `create_project`). Rejected with a 404 if you do not own the project. Returns the project's single stored market snapshot — market size, growth trend, key trends and positioning gaps — which is ONE COHERENT RUN'S OUTPUT: every field was written together by the research run named in the `sourceRunId` provenance field, never assembled from several runs. Pass that id to `get_report` to see the run behind the figures. A project can legitimately have NO snapshot; that is reported as \"no run has produced market data\", never as a zero or an empty market.",
+         "description": "UUID of the project whose market snapshot to read. Get it from `list_projects` (or `create_project`). Rejected with a 404 if you do not own the project. Returns the project's single stored market snapshot. Its versioned signals, sizing candidates, growth trend, key trends and positioning gaps may be attributed to `sourceRunId` only when `sourceBindingState` is `bound` or `bound_empty`. When bound they are ONE COHERENT RUN'S OUTPUT. The separately labelled legacy market-size context may predate that run and is never strict TAM, SAM, or SOM evidence. The tool also returns zero-to-three strict cited `marketSignals` in result text and `structuredContent.marketSignals`; cite those only with their rendered source URL(s). Raw snapshot fields are neutral recorded context; legacy context is neutral too. Check a bound source run with `get_report` before citation. No strict signals means no candidate survived proof, not that the raw snapshot or market is empty. A project can legitimately have NO snapshot; that is reported as \"no run has produced market data\", never as a zero or an empty market.",
          "format": "uuid",
          "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
          "type": "string"
-       "market": {}
+       "market": {},
+       "marketSignals": {
+         "items": {
+           "additionalProperties": true,
+           "type": "object"
+         },
+         "type": "array"
+       },
+       "marketSizing": {
+         "items": {
+           "additionalProperties": true,
+           "type": "object"
+         },
+         "type": "array"
+       }
      },
      "required": [
-       "market"
+       "market",
+       "marketSizing",
+       "marketSignals"
      ],
      "type": "object"
    }

--- pinned/get_project
+++ observed/get_project
  {
    "description": "Orient on a Clien.ai project in ONE call: the project's metadata plus the counts, ids, and one-line summaries of everything in it — personas, interviews, competitors, community signals, and research reports. START HERE when you pick up an existing project and need to know what it already holds; it replaces the five separate `list_*` calls that answer the same question. Reading it BEFORE `clien_research`, `scan_competitors`, or `search_forums` is the cheapest way to avoid paying to rediscover work the project already has. Pass `include` (any of \"personas\", \"interviews\", \"competitors\", \"community\", \"reports\") to inline those collections' full records instead of summaries, and `limit` to cap how many records per collection come back. Inlined interviews carry `messageCount` but NOT transcripts — use `get_interview` for one. DEGRADED RESULTS ARE NORMAL AND MUST BE READ CAREFULLY: each collection is fetched independently, so one failing read does not lose the others — a failed one is named as unavailable in the result text (and carried as `{ error: \"unavailable\", detail }` under its key in host-side `_meta.collections`). The project metadata degrades the SAME way and is flagged in the text with its own warning line — so the project name can be the one part that failed while every collection loaded. An `unavailable` entry is NOT an empty one: never conclude a project has no competitors (and never start a paid scan) on the strength of a collection that failed to load. A collection also comes back `unavailable` when the server answers without a usable count, precisely so a broken response can never read as \"this project has none\". Re-read just that collection with its `list_*` tool. COUNTS: `count` is the project-wide total and `countExact` is true for personas, interviews, competitors, and community signals. For REPORTS the endpoint returns no total, so a full page yields `countExact: false` and `count` is a LOWER BOUND — there may be more. ORDERING differs per collection and is not interchangeable: personas by newest created, interviews by newest started, reports by newest created, competitors by most recently SEEN (a competitor re-sighted by a later run moves back to the top), and community signals by newest DISCOVERED (stable — a thread seen again does not move). Read-only: no credit cost, no side effects.",
    "inputSchema": {
-   "name": "get_project"
+   "name": "get_project",
+   "outputSchema": {
+     "additionalProperties": true,
+     "properties": {
+       "collections": {
+         "additionalProperties": true,
+         "type": "object"
+       },
+       "included": {
+         "items": {
+           "additionalProperties": true,
+           "type": "object"
+         },
+         "type": "array"
+       },
+       "limit": {},
+       "project": {}
+     },
+     "required": [
+       "project",
+       "collections",
+       "limit",
+       "included"
+     ],
+     "type": "object"
+   }
  }

+ tool added: get_project_file_text

--- pinned/get_report
+++ observed/get_report
  {
-   "description": "Retrieve the full report for a past `clien_research` job by its `job_id` (from a `list_reports` entry, which prints every run's id, or from the error text of a run that dropped mid-flight). Returns the markdown report as text, FOLLOWED BY A MACHINE-CHECKED TRUST DIGEST rendered into that same text — read the digest rather than trusting the prose. The digest carries: Raw typed `report_data` states, source ids, and attestation markers are stored audit data, not citation eligibility. Only the machine-checked TRUST DIGEST's rendered state and receipt arrow authorize Cited: the digest must resolve a canonical, spine-owned pointer to a safe reachable HTTP(S) destination. Dangling, malformed, cross-persona, unsafe, credentialed, or incomplete pointers degrade without an arrow and MUST NOT be cited. (1) the persona claim spine — every claim's rendered GROUNDED / SPECULATION / NO_RECEIPT state; only an eligible Cited row has a \"RCP-p{i}-s{j}\" receipt arrow into the pool below it. One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. NO_RECEIPT can mean a bad claim OR merely sparse evidence, so check that persona's `insufficientEvidence` / `sourcesFound` line before discounting it. (2) the SEPARATE market/competitor spine — same three rendered states; eligible Cited rows carry \"RRCP-s{n}\" receipt arrows into their own evidence pool; a NO_RECEIPT claim marked \"Cited\" means a supporting page was read and independently vouched but no exact span pinned (NOT a receipt), and an unmarked NO_RECEIPT is recalled model knowledge, unverified. Neither counts as grounded — key on the digest's rendered state and arrow, never raw state or whether a source id is present. (3) the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. (4) per-persona QA — a ⚠️ QA-FLAGGED persona failed a quality check (or could not be checked at all); do not rely on its claims. Its `identityPriors` (seniority rung, career path) are typed enrichment and `identityProvenance` is a PII-free aggregate calibration line — NEVER a receipt, do not cite it as a source. (5) the anti-sycophancy readout — explicit rejection count, `lowDiscrimination` broken-persona flags, and per-hypothesis disagreement splits. (6) The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. The typed `openQuestions[]` field is returned at `structuredContent.report_data.openQuestions`, where it lists what the run did not settle. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the result text under \"## Verdict rationale\", and typed at `structuredContent.report_data.verdictSummary`: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. When a section is missing the digest SAYS SO (\"NOT PRESENT on this run\") — absent is not clean, so treat the corresponding prose as unverified. The full structured `report_data` (hypotheses, competitors[], key findings, and every field summarised above) is also returned as `structuredContent.report_data`, mirrored in `_meta.report_data`. Use this to RETRIEVE past research instead of re-running `clien_research`, which would debit credits again for the same idea. Backs the competitor spot-check (read `report_data.competitors[]`) and pivot-viability (compare a pivot's report against the original) recipes in docs/recipes/. If the job is still running or you are unsure of its state, use `clien_research_status`. Read-only: no credit cost, no side effects.",
+   "description": "Retrieve the full report for a past `clien_research` job by its `job_id` (from a `list_reports` entry, which prints every run's id, or from the error text of a run that dropped mid-flight). Returns the markdown report as text, FOLLOWED BY A MACHINE-CHECKED TRUST DIGEST rendered into that same text — read the digest rather than trusting the prose. The digest carries: Raw typed `report_data` states, source ids, and attestation markers are stored audit data, not citation eligibility. Only the machine-checked TRUST DIGEST's rendered state and receipt arrow authorize Cited: the digest must resolve a canonical, spine-owned pointer. Report and persona receipts require a safe reachable HTTP(S) destination; an overview forum receipt may instead expose its exact bounded cached excerpt when the destination is withheld. Outside that cached-excerpt exception, dangling, malformed, cross-persona, unsafe, credentialed, or incomplete pointers degrade without an arrow and MUST NOT be cited. (1) the persona claim spine — every claim's rendered GROUNDED / SPECULATION / NO_RECEIPT state; only an eligible Cited row has a \"RCP-p{i}-s{j}\" receipt arrow into the pool below it. One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. NO_RECEIPT can mean a bad claim OR merely sparse evidence, so check that persona's `insufficientEvidence` / `sourcesFound` line before discounting it. (2) the SEPARATE market/competitor spine — same three rendered states; eligible Cited rows carry \"RRCP-s{n}\" receipt arrows into their own evidence pool; a NO_RECEIPT claim marked \"Cited\" means a supporting page was read and independently vouched but no exact span pinned (NOT a receipt), and an unmarked NO_RECEIPT is recalled model knowledge, unverified. Neither counts as grounded — key on the digest's rendered state and arrow, never raw state or whether a source id is present. (3) the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness and is EXCLUDED from automatic community synthesis. It is also excluded from grounding except that a producer-resolved hypothesis receipt may support only a capability about that same named vendor; never cite it as user evidence or independent market evidence. `unclassified` is EXCLUDED from both grounding and automatic community synthesis, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, `quotesByHypothesis`, and content-addressed `evidenceReference` quote ids — internal `researchTaskId` is excluded. Typed `marketOverview` and `communityOverview` carry generated prose plus exact `claimSpans`; only the code-derived overview trust rows below the separator authorize Cited, and dangling or private references degrade to Unsourced. Fresh reports also carry `crossCuttingFindings[]`; their evidence is resolved inline and legacy Insights are suppressed. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. (4) per-persona QA — a ⚠️ QA-FLAGGED persona failed a quality check (or could not be checked at all); do not rely on its claims. Its `identityPriors` (seniority rung, career path) are typed enrichment and `identityProvenance` is a PII-free aggregate calibration line — NEVER a receipt, do not cite it as a source. (5) the anti-sycophancy readout — explicit rejection count, `lowDiscrimination` broken-persona flags, and per-hypothesis disagreement splits. (6) The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. The typed `openQuestions[]` field is returned at `structuredContent.report_data.openQuestions`, where it lists what the run did not settle. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the result text under \"## Verdict rationale\", and typed at `structuredContent.report_data.verdictSummary`: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. When a section is missing the digest SAYS SO (\"NOT PRESENT on this run\") — absent is not clean, so treat the corresponding prose as unverified. The full structured `report_data` (hypotheses, competitors[], key findings, and every field summarised above) is also returned as `structuredContent.report_data`, mirrored in `_meta.report_data`. Use this to RETRIEVE past research instead of re-running `clien_research`, which would debit credits again for the same idea. Backs the competitor spot-check (read `report_data.competitors[]`) and pivot-viability (compare a pivot's report against the original) recipes in docs/recipes/. If the job is still running or you are unsure of its state, use `clien_research_status`. Read-only: no credit cost, no side effects.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {

--- pinned/interview_persona
+++ observed/interview_persona
  {
    "description": "Run a real, stateful multi-turn interview with a persona and get its full replies. IMPORTANT — these personas are SYNTHETIC: AI-generated composites, not real people. Their replies are simulated research signal, never testimony from a human, and the persona will stay in character if you ask whether it is an AI (it will answer plainly if you press). Say so whenever you relay these answers to a person. Drive it as a loop: `action:start` once (with project_id + persona_id) opens the interview and seeds the persona's greeting, printing the interview id in its result text. Then `action:turn` (interview_id + content) repeatedly — each call posts one question and returns THAT persona's full reply as the result text; read it, then ask the next question. `action:transcript` (interview_id) re-reads the whole conversation. `action:complete` closes the interview when you've learned enough (5-12 turns is typical); `action:reopen` resumes a completed one. Interviews and their auto-summary/message-count behave exactly like the web app. Set `ephemeral:true` on `start` for a scratch interview excluded from the project's aggregate insights. ANCHOR IT: when the questions come from `list_interview_scripts`, pass that script's `hypothesisId` as `hypothesis_id` and the call's `sourceRun.id` as `hypothesis_run_id` on `start` (both or neither). The interview stores which hypothesis it tested and returns it on `get_interview` / `list_interviews`, so the answers can be tied back without you carrying the id through the conversation; `start` tells you if the server did not record it. Compose with `create_persona` to validate a new market or pressure-test a pivot (see docs/recipes/); for a FULL validation report, prefer `clien_research` over stitching interviews together yourself. Each `turn` generates a real AI reply. Billing is a FLAT 3-credit charge for the WHOLE interview, however many turns it runs: the first charging turn debits it, and every later turn — or a retry of the same one — replays that charge to a no-op, so it is free. Credits are the ONLY meter: there is no separate token allowance, so a turn never fails for usage reasons while you hold credits.",
    "inputSchema": {
-         "pattern": "^[^\\s\\p{Cc}\\p{Cf}\\p{Zl}\\p{Zp}]+$",
+         "pattern": "^[^\\s\\u0000-\\u001F\\u007F-\\u009F\\u00AD\\u0600-\\u0605\\u061C\\u06DD\\u070F\\u0890-\\u0891\\u08E2\\u180E\\u200B-\\u200F\\u2028-\\u202E\\u2060-\\u2064\\u2066-\\u206F\\uFEFF\\uFFF9-\\uFFFB]+$",
          "type": "string"
        },
        "hypothesis_run_id": {

--- pinned/list_community_signals
+++ observed/list_community_signals
  {
-   "description": "List the community signals (forum / Hacker News / Stack Exchange threads) recorded for a Clien.ai project (newest-discovered first, paginated). Returns each thread's title, platform, sentiment summary, url, one representative quote (with `(+N more cached)` when the thread has others, so one quote is not mistaken for all there was), and engagement as readable text (shown only when a real, non-zero count was measured — an absent engagement line means either UNMEASURED or genuinely zero on both sides, which the render cannot distinguish); the full signal array and pagination are also returned as `structuredContent.communitySignals` / `.pagination` (mirrored in `_meta`). Requires a `project_id` — call `list_projects` to find one. This reads the project's DEDUPED, ACCUMULATED thread set — merged across every research run and the web app — so unlike `get_report` (one run's view) or `search_forums` (a fresh, credit-debiting scan), it answers \"what user voice has this project already collected?\" for free. Check here BEFORE running `search_forums` to avoid paying to rediscover threads you already have. Each signal's `relevantQuotes[]` are the user-voice excerpts cached at collection — the same field `search_forums` returns — so they stay readable even if the thread later disappears. ORDERING differs from `list_competitors` on purpose: this feed is ordered by when the project FIRST saw a thread and that order is STABLE — a thread a later run sees again does not move back to page one. So page one is the newest DISCOVERIES, not the newest activity; do not read a thread's position as a recency signal. SOURCE TYPE: every returned community row carries a `source type:` line — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Read-only: no credit cost, no side effects.",
+   "description": "List the community signals (forum / Hacker News / Stack Exchange threads) recorded for a Clien.ai project (newest-discovered first, paginated). Returns each thread's title, platform, sentiment summary, url, one representative quote (with `(+N more cached)` when the thread has others, so one quote is not mistaken for all there was), and engagement as readable text (shown only when a real, non-zero count was measured — an absent engagement line means either UNMEASURED or genuinely zero on both sides, which the render cannot distinguish); the full signal array and pagination are also returned as `structuredContent.communitySignals` / `.pagination` (mirrored in `_meta`). Requires a `project_id` — call `list_projects` to find one. This reads the project's DEDUPED, ACCUMULATED thread set — merged across every research run and the web app — so unlike `get_report` (one run's view) or `search_forums` (a fresh, credit-debiting scan), it answers \"what user voice has this project already collected?\" for free. Check here BEFORE running `search_forums` to avoid paying to rediscover threads you already have. Each signal's `relevantQuotes[]` are the user-voice excerpts cached at collection — the same field `search_forums` returns — so they stay readable even if the thread later disappears. ORDERING differs from `list_competitors` on purpose: this feed is ordered by when the project FIRST saw a thread and that order is STABLE — a thread a later run sees again does not move back to page one. So page one is the newest DISCOVERIES, not the newest activity; do not read a thread's position as a recency signal. SOURCE TYPE: every returned community row carries a `source type:` line — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. `marketing_seo` is shown for awareness and is EXCLUDED from automatic community synthesis. It is also excluded from grounding except that a producer-resolved hypothesis receipt may support only a capability about that same named vendor; never cite it as user evidence or independent market evidence. `unclassified` is EXCLUDED from both grounding and automatic community synthesis, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Read-only: no credit cost, no side effects.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {

+ tool added: list_project_files

--- pinned/scan_competitors
+++ observed/scan_competitors
  {
    "description": "Scan the competitive landscape for a product idea or market — a targeted, cheaper alternative to the full clien_research report when you only need the COMPETITOR dimension. Runs one web researcher (not the whole H1-H8 pipeline): typical wall time 2-10 minutes, progress streamed via notifications/progress. Renders every competitor into the result text — name, url, description, pricing, strengths[], weaknesses[], and the four company facts (`funding`, `employeeCount`, `founded`, `hqLocation`). The same list, plus `relevantHypotheses[]`, is mirrored to host-side `_meta.competitors` for your MCP client. TRUST: those four company facts are UN-RECEIPTED here — this tool stores the value the researcher wrote, not the URL it came from, and attaches no grounding object to any of them. Treat all four as unverified, and do not cite them as source-checked. The surface that DOES carry per-fact provenance is `list_competitors`, where each of the same four facts has a sibling `<fact>Grounding` field ({ state: GROUNDED | SPECULATION | NO_RECEIPT, sourceUrl?, sourceRetrievedAt? }) — key on `state` there, and treat anything that is not GROUNDED as unverified. WHAT COUNTS AS A COMPETITOR: direct and adjacent products/services a target user would realistically evaluate or already use to solve the same problem — including incumbents, startups, and notable open-source or DIY alternatives; not tangential tools. Depth is a focused landscape scan (roughly 3-10 competitors), not an exhaustive market map. CHECK THE FREE READ FIRST: `list_competitors` returns the competitors a project has already accumulated across every past run and the web app, at no credit cost. Read it (or `get_project`) before spending here, so you do not pay to rediscover what the project already knows. Use this tool when you need a FRESH scan or the project has no competitors yet. ATTACH TO A PROJECT so results are saved to the web app's Research → Competitors tab: pass `project_id` for an existing project, or `project_name` to auto-create one. Without either, the scan still returns competitors here but does NOT persist them. Composes well: run this for a quick competitor spot-check, or before/after a pivot to compare landscapes; for a COMPLETE validation (personas, interviews, synthesis) prefer clien_research. This debits credits (a scoped web scan). IMPORTANT: if the call drops mid-flight with \"MCP error -32000\", the job keeps running on the backend — do NOT blindly re-call (that starts a new run and debits again); the job_id is logged to the MCP server stderr as `[clien-mcp] scan_competitors started job_id=…`.",
    "inputSchema": {
+       "operation_id": {
+         "description": "Recommended: a UUID you generate for this one paid start and keep. If the call is cut off (a timeout, a dropped connection) call again with the SAME operation_id and the SAME other inputs: if the first attempt did start, you get that run back and are not charged again. If you leave it unset, the tool picks one and reports it only when a failure is worth retrying — which a connection that dies before the tool returns can never do. Never reuse an operation_id for a different request — that is refused.",
+         "format": "uuid",
+         "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+         "type": "string"
+       },
        "product_name": {
          "description": "Optional short product/brand name for research context (2-4 words). Sharpens the researcher's framing; defaults to a slug of `topic` when omitted.",
          "maxLength": 100,

--- pinned/scan_market
+++ observed/scan_market
  {
-   "description": "Research a MARKET — how big it is, whether it is growing, what is moving it, and what it does not serve. A targeted, cheaper alternative to the full clien_research report when you only need the MARKET dimension. Runs one market researcher over news and financial-report sources (not the whole H1-H8 pipeline): typical wall time 2-10 minutes, progress streamed via notifications/progress. Returns the market size, the growth trend, every atomic figure the run recorded with the scope the source named, the key trends, and the positioning gaps — the same five things it publishes to the web app's Research → Market tab. All of it is rendered into the result text you can read; the same block is also mirrored to host-side `_meta.market` for your MCP client. IT DOES NOT DISCOVER COMPETITORS, and it leaves the competitor and community dossiers completely untouched — use `scan_competitors` for the landscape and `search_forums` for user voice. TRUST: the figures are UNGRADED on this surface — no per-figure source state is attached, and the absence of a marker is not a clean bill of health. A figure carrying no scope label is a market SIZE whose slice the source never named; it is NOT a defaulted \"total addressable market\". A run that recorded nothing says so explicitly, and that means the RUN found no figures — never that the market is small, absent, or zero. CHECK THE FREE READ FIRST: `get_market` returns the market snapshot the project already holds, at no credit cost, with the id of the run that produced it. Read it (or `get_project`) before spending here. Use this tool when you need a FRESH read or the project has no market data yet. ATTACH TO A PROJECT so results are saved: pass `project_id` for an existing project, or `project_name` to auto-create one. Without either, the research still returns here but does NOT persist. ⚠️ IT REPLACES THE WHOLE MARKET SNAPSHOT. A project has ONE market record, written by one run, so a successful scan replaces every field — including emptying a list this run did not establish. That is what keeps the record and its source run honest about each other; it is not a merge. This debits credits (a scoped market run). IMPORTANT: if the call drops mid-flight with \"MCP error -32000\", the job keeps running on the backend — do NOT blindly re-call (that starts a new run and debits again); the job_id is logged to the MCP server stderr as `[clien-mcp] scan_market started job_id=…`.",
+   "description": "Research a MARKET — how big it is, whether it is growing, what is moving it, and what it does not serve. A targeted, cheaper alternative to the full clien_research report when you only need the MARKET dimension. Runs one market researcher over news and financial-report sources (not the whole H1-H8 pipeline): typical wall time 2-10 minutes, progress streamed via notifications/progress. Returns zero-to-three ordered strict cited `marketSignals` first, followed by the raw market size, growth direction, atomic figures, key trends, and positioning gaps the run recorded. Strict signals survive exact claim/receipt or derivation checks and include their exact source URL(s) in the result text; host-side `_meta.market.resolvedSignals` mirrors them. The remaining host-side `_meta.market` fields are legacy recorded context, not independently verified. IT DOES NOT DISCOVER COMPETITORS, and it leaves the competitor and community dossiers completely untouched — use `scan_competitors` for the landscape and `search_forums` for user voice. TRUST: cite a strict signal only with the source URL(s) rendered beside it. Treat raw snapshot fields as neutral recorded context, never as cited TAM, SAM, SOM, or growth. A figure carrying no scope label is not a defaulted total addressable market. \"No cited market signals were established\" means no candidate survived strict proof; it does not mean the market is small, absent, zero, or that the run recorded no raw context. CHECK THE FREE READ FIRST: `get_market` returns the market snapshot the project already holds, at no credit cost, with the id of the run that produced it. Read it (or `get_project`) before spending here. Use this tool when you need a FRESH read or the project has no market data yet. ATTACH TO A PROJECT so results are saved: pass `project_id` for an existing project, or `project_name` to auto-create one. Without either, the research still returns here but does NOT persist. ⚠️ IT REPLACES THE CURRENT MARKET SNAPSHOT. A project has ONE market record, so a successful scan replaces the versioned signals, sizing candidates, direction, trends and positioning gaps — including emptying a list this run did not establish. The separately labelled legacy market-size context is compatibility history and may be preserved; it is never attributed to the new run or promoted as strict sizing. This debits credits (a scoped market run). IMPORTANT: if the call drops mid-flight with \"MCP error -32000\", the job keeps running on the backend — do NOT blindly re-call (that starts a new run and debits again); the job_id is logged to the MCP server stderr as `[clien-mcp] scan_market started job_id=…`.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {
+       "operation_id": {
+         "description": "Recommended: a UUID you generate for this one paid start and keep. If the call is cut off (a timeout, a dropped connection) call again with the SAME operation_id and the SAME other inputs: if the first attempt did start, you get that run back and are not charged again. If you leave it unset, the tool picks one and reports it only when a failure is worth retrying — which a connection that dies before the tool returns can never do. Never reuse an operation_id for a different request — that is refused.",
+         "format": "uuid",
+         "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+         "type": "string"
+       },
        "product_name": {
          "description": "Optional short product/brand name for research context (2-4 words). Sharpens the researcher's framing; defaults to a slug of `topic` when omitted.",
          "maxLength": 100,

--- pinned/search_forums
+++ observed/search_forums
  {
-   "description": "Search real community discussions (Hacker News, Stack Exchange / Stack Overflow, Indie Hackers, dev.to, Lobsters, Product Hunt) for PRODUCT-VALIDATION signal about an idea or user problem — a targeted, cheaper alternative to the full clien_research report when you only need the COMMUNITY dimension. Runs one forum researcher (not the whole H1-H8 pipeline): typical wall time 2-10 minutes, progress streamed via notifications/progress. Renders every thread into the result text — title, platform, url, sentimentSummary, its first cached quote, its `source type:` line, and engagement (upvotes · comments) ONLY when the thread carries a real, non-zero count — an absent engagement line means the counters were either never measured or genuinely zero on both sides — the render cannot tell those apart, so do not read a missing line as low traction. When a thread cached more than one quote the row says so — `(+N more cached)` after the quote — so you can tell a heavily-discussed thread from a barely-quoted one; the quotes themselves are in `structuredContent` (also mirrored to host-side `_meta.threads`). WHAT IT LOOKS FOR: evidence about the PROBLEM and demand — people describing the pain point, asking for a solution, or complaining about existing tools — not generic keyword hits. This is NOT a generic web search; frame the topic as a user problem/audience for the best threads. CHECK THE FREE READ FIRST: `list_community_signals` returns the threads a project has already accumulated across every past run and the web app, at no credit cost — including each thread's cached `relevantQuotes[]` excerpts, the same field this tool returns. Read it (or `get_project`) before spending here, so you do not pay to rediscover user voice the project already holds. Use this tool when you need FRESH threads or the project has none yet. SOURCE TYPE: every returned community row carries a `source type:` line — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. The type is stamped from the host by code, never written by a model, and only hosts the forum allowlist recognises get one — so `unclassified` is COMMON. ATTACH TO A PROJECT so results are saved to the web app's Research → Community tab: pass `project_id` for an existing project, or `project_name` to auto-create one. Without either, the threads are returned here but NOT persisted. Composes well with scan_competitors (demand + landscape) for a quick read on an idea — but run the two SEQUENTIALLY when they target the same project: the backend allows one active research run per project, so a parallel second call fails with 409. For a COMPLETE validation (personas, interviews, synthesis) prefer clien_research. This debits credits (a scoped forum scan). IMPORTANT: if the call drops mid-flight with \"MCP error -32000\", the job keeps running on the backend — do NOT blindly re-call (that starts a new run and debits again); the job_id is logged to the MCP server stderr as `[clien-mcp] search_forums started job_id=…`.",
+   "description": "Search real community discussions (Hacker News, Stack Exchange / Stack Overflow, Indie Hackers, dev.to, Lobsters, Product Hunt) for PRODUCT-VALIDATION signal about an idea or user problem — a targeted, cheaper alternative to the full clien_research report when you only need the COMMUNITY dimension. Runs one forum researcher (not the whole H1-H8 pipeline): typical wall time 2-10 minutes, progress streamed via notifications/progress. Renders every thread into the result text — title, platform, url, sentimentSummary, its first cached quote, its `source type:` line, and engagement (upvotes · comments) ONLY when the thread carries a real, non-zero count — an absent engagement line means the counters were either never measured or genuinely zero on both sides — the render cannot tell those apart, so do not read a missing line as low traction. When a thread cached more than one quote the row says so — `(+N more cached)` after the quote — so you can tell a heavily-discussed thread from a barely-quoted one; the quotes themselves are in `structuredContent` (also mirrored to host-side `_meta.threads`). WHAT IT LOOKS FOR: evidence about the PROBLEM and demand — people describing the pain point, asking for a solution, or complaining about existing tools — not generic keyword hits. This is NOT a generic web search; frame the topic as a user problem/audience for the best threads. CHECK THE FREE READ FIRST: `list_community_signals` returns the threads a project has already accumulated across every past run and the web app, at no credit cost — including each thread's cached `relevantQuotes[]` excerpts, the same field this tool returns. Read it (or `get_project`) before spending here, so you do not pay to rediscover user voice the project already holds. Use this tool when you need FRESH threads or the project has none yet. SOURCE TYPE: every returned community row carries a `source type:` line — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. `marketing_seo` is shown for awareness and is EXCLUDED from automatic community synthesis. It is also excluded from grounding except that a producer-resolved hypothesis receipt may support only a capability about that same named vendor; never cite it as user evidence or independent market evidence. `unclassified` is EXCLUDED from both grounding and automatic community synthesis, and means the classification is genuinely unknown, NOT that the source was checked and found benign. The type is stamped from the host by code, never written by a model, and only hosts the forum allowlist recognises get one — so `unclassified` is COMMON. ATTACH TO A PROJECT so results are saved to the web app's Research → Community tab: pass `project_id` for an existing project, or `project_name` to auto-create one. Without either, the threads are returned here but NOT persisted. Composes well with scan_competitors (demand + landscape) for a quick read on an idea — but run the two SEQUENTIALLY when they target the same project: the backend allows one active research run per project, so a parallel second call fails with 409. For a COMPLETE validation (personas, interviews, synthesis) prefer clien_research. This debits credits (a scoped forum scan). IMPORTANT: if the call drops mid-flight with \"MCP error -32000\", the job keeps running on the backend — do NOT blindly re-call (that starts a new run and debits again); the job_id is logged to the MCP server stderr as `[clien-mcp] search_forums started job_id=…`.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {
+       "operation_id": {
+         "description": "Recommended: a UUID you generate for this one paid start and keep. If the call is cut off (a timeout, a dropped connection) call again with the SAME operation_id and the SAME other inputs: if the first attempt did start, you get that run back and are not charged again. If you leave it unset, the tool picks one and reports it only when a failure is worth retrying — which a connection that dies before the tool returns can never do. Never reuse an operation_id for a different request — that is refused.",
+         "format": "uuid",
+         "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+         "type": "string"
+       },
        "product_name": {
          "description": "Optional short product/brand name for research context (2-4 words). Sharpens the researcher's framing; defaults to a slug of `topic` when omitted.",
          "maxLength": 100,

+ tool added: update_project

Changed 2026-09-04 10:34 UTC

4 descriptions rewritten.

--- pinned/clien_research
+++ observed/clien_research
  {
-   "description": "Run a full product-research pass on an idea — the recommended default for validating a new idea end to end. Returns a markdown report, FOLLOWED IN THE SAME TEXT by a machine-checked TRUST DIGEST — read the digest rather than trusting the prose. It states every claim's GROUNDED / SPECULATION / NO_RECEIPT state with its receipt id, the separate market/competitor spine, which personas are ⚠️ QA-FLAGGED, and the anti-sycophancy readout. The digest also reports hypothesis robustness: when a verdict FLIPPED under rephrasing it names the downgraded verdict to act on. Each re-tested row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. When a section is missing the digest says so — absent is not clean. The digest also states the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. The full structured report_data (framing, methodology, safe interview highlights, hypotheses, competitors[], key findings) is mirrored to host-side `_meta.report_data` for programmatic use by your MCP client; everything YOU need to reason is already in the result text above it. Raw typed `report_data` states, source ids, and attestation markers are stored audit data, not citation eligibility. Only the machine-checked TRUST DIGEST's rendered state and receipt arrow authorize Cited: the digest must resolve a canonical, spine-owned pointer to a safe reachable HTTP(S) destination. Dangling, malformed, cross-persona, unsafe, credentialed, or incomplete pointers degrade without an arrow and MUST NOT be cited. report_data carries this same typed TRUST layer: (1) `claims[]` — each has a stored GROUNDED / SPECULATION / NO_RECEIPT state and may carry a `sourceId` of the form \"RCP-p{i}-s{j}\" into `personas[i].sources[j]`; use the digest, not this raw pointer, to decide whether the claim earned Cited. One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. NO_RECEIPT can mean a bad claim OR merely sparse evidence — cross-check `personas[].insufficientEvidence` / `sourcesFound` before discounting it. (2) `hypothesisResults[].robustness` — how many reworded re-asks a verdict survived (`survived`/`total`, e.g. 3/3); when `flipped` is true, trust `robustness.downgradedStatus` as the real verdict, NOT the top-level `status`. (3) `personas[]` — besides `sources[]` receipts, check `qaFlagged` (persona failed a quality check) before relying on its claims. Two DIFFERENT grounding models ride here: forum `sources[]` are receipt-eligible clickable posts, whereas `identityProvenance` (when present) is a PII-free aggregate calibration line (\"calibrated against N real ICP profiles\") — NEVER a receipt, so do not treat it as a source URL; `identityPriors` (seniority + career path) is typed enrichment, not a receipt either. (4) `sycophancySignals` — broken-persona flags (`lowDiscrimination`), disagreement splits, and explicit `totalRejections`. (5) `reportClaims[]` — the SEPARATE market/competitor spine (never crosses the persona one): each stored GROUNDED / SPECULATION / NO_RECEIPT, and may carry a `sourceId` of the form \"RRCP-s{n}\" into `reportEvidence[n]` (its own pool). On THIS spine a NO_RECEIPT claim has one of two provenance readings: only when its complete `attestation` marker ({sourceId, quote}) resolves in the digest to a safe receipt with an arrow is it \"Cited\" — Claude read a supporting page and an independent check vouched it supports the figure, though no exact quote could be pinned (stronger than recall, but NOT a verified receipt; its `attestation.sourceId` indexes `reportEvidence[n]` the same way, but a marker's presence NEVER implies grounding — key on the digest's rendered state and arrow, not raw state/sourceId); otherwise it is \"unsourced\": an evidence-shaped figure Claude wrote from its own training knowledge that could not be verified against a source — often directionally right (a recalled analyst estimate), but treat it as unconfirmed, NOT as a checked fact. Neither reading is ever counted as grounded. (6) The typed `openQuestions[]` field is mirrored for your MCP client at host-side `_meta.report_data.openQuestions`; because host `_meta` is not reliably model-visible, YOU should use the model-visible result text's `## Open Questions` section. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the model-visible result text under \"## Verdict rationale\" — READ IT THERE. The typed field is mirrored for your MCP client at host-side `_meta.report_data.verdictSummary`, which is not reliably model-visible: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. Typical wall time 15-25 minutes; progress is streamed via notifications/progress. This hero tool runs the whole curated pipeline in one call. PREFER it over hand-assembling a full validation from the granular primitives (create_persona + interview_persona + get_report) — those are for targeted, cheaper spot-checks, not a complete report; sequencing them yourself gives lower-quality coverage. See docs/recipes/ for the supported compositions (competitor spot-check, pivot viability, new-market persona validation). ALWAYS attach the run to a project so the report is visible in the Clien.ai web app: pass `project_name` to create a new project (derive a short 2-4 word name from the idea), or `project_id` to reuse an existing one — a run with neither is refused. First call opens a browser for one-time OAuth login; subsequent calls reuse the stored refresh token. IMPORTANT: if this call fails mid-flight with \"MCP error -32000: Connection closed\", do NOT call clien_research again — that spawns a new run and debits credits again for the same idea. Instead call `clien_research_status` with NO arguments — it finds your recent run(s) and lists them so you can pick the one you were researching. The dropped call's error text usually carries the job_id too, and you can pass it directly if you have it. (The id is also in the `[clien-mcp] research started job_id=…` stderr line and in host-side `_meta.job_id`, but both reach the operator's MCP client rather than you.)",
+   "description": "Run a full product-research pass on an idea — the recommended default for validating a new idea end to end. Returns a markdown report, FOLLOWED IN THE SAME TEXT by a machine-checked TRUST DIGEST — read the digest rather than trusting the prose. It states every claim's GROUNDED / SPECULATION / NO_RECEIPT state with its receipt id, the separate market/competitor spine, which personas are ⚠️ QA-FLAGGED, and the anti-sycophancy readout. The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. When a section is missing the digest says so — absent is not clean. The digest also states the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. The full structured report_data (framing, methodology, safe interview highlights, hypotheses, competitors[], key findings) is mirrored to host-side `_meta.report_data` for programmatic use by your MCP client; everything YOU need to reason is already in the result text above it. Raw typed `report_data` states, source ids, and attestation markers are stored audit data, not citation eligibility. Only the machine-checked TRUST DIGEST's rendered state and receipt arrow authorize Cited: the digest must resolve a canonical, spine-owned pointer to a safe reachable HTTP(S) destination. Dangling, malformed, cross-persona, unsafe, credentialed, or incomplete pointers degrade without an arrow and MUST NOT be cited. report_data carries this same typed TRUST layer: (1) `claims[]` — each has a stored GROUNDED / SPECULATION / NO_RECEIPT state and may carry a `sourceId` of the form \"RCP-p{i}-s{j}\" into `personas[i].sources[j]`; use the digest, not this raw pointer, to decide whether the claim earned Cited. One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. NO_RECEIPT can mean a bad claim OR merely sparse evidence — cross-check `personas[].insufficientEvidence` / `sourcesFound` before discounting it. (2) `hypothesisResults[].final` — the versioned effective verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. Prefer this block over the raw top-level `status`/numeric `confidence`; the digest validates its version and refuses any attempted verdict upgrade. The sibling `robustness` block supplies the inspectable `survived`/`total` working. (3) `personas[]` — besides `sources[]` receipts, check `qaFlagged` (persona failed a quality check) before relying on its claims. Two DIFFERENT grounding models ride here: forum `sources[]` are receipt-eligible clickable posts, whereas `identityProvenance` (when present) is a PII-free aggregate calibration line (\"calibrated against N real ICP profiles\") — NEVER a receipt, so do not treat it as a source URL; `identityPriors` (seniority + career path) is typed enrichment, not a receipt either. (4) `sycophancySignals` — broken-persona flags (`lowDiscrimination`), disagreement splits, and explicit `totalRejections`. (5) `reportClaims[]` — the SEPARATE market/competitor spine (never crosses the persona one): each stored GROUNDED / SPECULATION / NO_RECEIPT, and may carry a `sourceId` of the form \"RRCP-s{n}\" into `reportEvidence[n]` (its own pool). On THIS spine a NO_RECEIPT claim has one of two provenance readings: only when its complete `attestation` marker ({sourceId, quote}) resolves in the digest to a safe receipt with an arrow is it \"Cited\" — Claude read a supporting page and an independent check vouched it supports the figure, though no exact quote could be pinned (stronger than recall, but NOT a verified receipt; its `attestation.sourceId` indexes `reportEvidence[n]` the same way, but a marker's presence NEVER implies grounding — key on the digest's rendered state and arrow, not raw state/sourceId); otherwise it is \"unsourced\": an evidence-shaped figure Claude wrote from its own training knowledge that could not be verified against a source — often directionally right (a recalled analyst estimate), but treat it as unconfirmed, NOT as a checked fact. Neither reading is ever counted as grounded. (6) The typed `openQuestions[]` field is mirrored for your MCP client at host-side `_meta.report_data.openQuestions`; because host `_meta` is not reliably model-visible, YOU should use the model-visible result text's `## Open Questions` section. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the model-visible result text under \"## Verdict rationale\" — READ IT THERE. The typed field is mirrored for your MCP client at host-side `_meta.report_data.verdictSummary`, which is not reliably model-visible: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. Typical wall time 15-25 minutes; progress is streamed via notifications/progress. This hero tool runs the whole curated pipeline in one call. PREFER it over hand-assembling a full validation from the granular primitives (create_persona + interview_persona + get_report) — those are for targeted, cheaper spot-checks, not a complete report; sequencing them yourself gives lower-quality coverage. See docs/recipes/ for the supported compositions (competitor spot-check, pivot viability, new-market persona validation). ALWAYS attach the run to a project so the report is visible in the Clien.ai web app: pass `project_name` to create a new project (derive a short 2-4 word name from the idea), or `project_id` to reuse an existing one — a run with neither is refused. First call opens a browser for one-time OAuth login; subsequent calls reuse the stored refresh token. IMPORTANT: if this call fails mid-flight with \"MCP error -32000: Connection closed\", do NOT call clien_research again — that spawns a new run and debits credits again for the same idea. Instead call `clien_research_status` with NO arguments — it finds your recent run(s) and lists them so you can pick the one you were researching. The dropped call's error text usually carries the job_id too, and you can pass it directly if you have it. (The id is also in the `[clien-mcp] research started job_id=…` stderr line and in host-side `_meta.job_id`, but both reach the operator's MCP client rather than you.)",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {

--- pinned/clien_research_status
+++ observed/clien_research_status
  {
-   "description": "Fetch the current state of an existing `clien_research` job. Use this to recover a run that disconnected with -32000 mid-flight (the job keeps running on the backend; this tool re-attaches a read view) and to poll for completion. If the job is complete, returns the full markdown report — followed in the same text by the same machine-checked TRUST DIGEST `clien_research` renders (claim states + receipt ids, QA-flagged personas, and the anti-sycophancy readout). One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. The digest also reports hypothesis robustness: when a verdict FLIPPED under rephrasing it names the downgraded verdict to act on. Each re-tested row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. The digest also states the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. The structured report_data behind that digest is mirrored to host-side `_meta`, the same shape `clien_research` would have returned, but it is the result text you read. A recovered run therefore loses none of the trust signal a completed run would have shown. The typed `openQuestions[]` field is mirrored for your MCP client at host-side `_meta.report_data.openQuestions`; because host `_meta` is not reliably model-visible, YOU should use the model-visible result text's `## Open Questions` section. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the model-visible result text under \"## Verdict rationale\" — READ IT THERE. The typed field is mirrored for your MCP client at host-side `_meta.report_data.verdictSummary`, which is not reliably model-visible: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. If the job is still running, returns a brief status summary. If the job failed or was cancelled, returns the failure reason. RECOVERY WITHOUT A JOB_ID: if the -32000 drop left you with no job_id, call this tool with NO arguments — it discovers your recent run(s). If exactly one is in flight it resumes it automatically; if several come back, it returns a list of runs each with a job_id and an idea snippet — re-call with the job_id whose idea matches the run you were executing (never guess, so run A never receives run B's report). Read-only: no credit cost, no side effects.",
+   "description": "Fetch the current state of an existing `clien_research` job. Use this to recover a run that disconnected with -32000 mid-flight (the job keeps running on the backend; this tool re-attaches a read view) and to poll for completion. If the job is complete, returns the full markdown report — followed in the same text by the same machine-checked TRUST DIGEST `clien_research` renders (claim states + receipt ids, QA-flagged personas, and the anti-sycophancy readout). One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. The digest also states the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. The structured report_data behind that digest is mirrored to host-side `_meta`, the same shape `clien_research` would have returned, but it is the result text you read. A recovered run therefore loses none of the trust signal a completed run would have shown. The typed `openQuestions[]` field is mirrored for your MCP client at host-side `_meta.report_data.openQuestions`; because host `_meta` is not reliably model-visible, YOU should use the model-visible result text's `## Open Questions` section. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the model-visible result text under \"## Verdict rationale\" — READ IT THERE. The typed field is mirrored for your MCP client at host-side `_meta.report_data.verdictSummary`, which is not reliably model-visible: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. If the job is still running, returns a brief status summary. If the job failed or was cancelled, returns the failure reason. RECOVERY WITHOUT A JOB_ID: if the -32000 drop left you with no job_id, call this tool with NO arguments — it discovers your recent run(s). If exactly one is in flight it resumes it automatically; if several come back, it returns a list of runs each with a job_id and an idea snippet — re-call with the job_id whose idea matches the run you were executing (never guess, so run A never receives run B's report). Read-only: no credit cost, no side effects.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {

--- pinned/get_report
+++ observed/get_report
  {
-   "description": "Retrieve the full report for a past `clien_research` job by its `job_id` (from a `list_reports` entry, which prints every run's id, or from the error text of a run that dropped mid-flight). Returns the markdown report as text, FOLLOWED BY A MACHINE-CHECKED TRUST DIGEST rendered into that same text — read the digest rather than trusting the prose. The digest carries: Raw typed `report_data` states, source ids, and attestation markers are stored audit data, not citation eligibility. Only the machine-checked TRUST DIGEST's rendered state and receipt arrow authorize Cited: the digest must resolve a canonical, spine-owned pointer to a safe reachable HTTP(S) destination. Dangling, malformed, cross-persona, unsafe, credentialed, or incomplete pointers degrade without an arrow and MUST NOT be cited. (1) the persona claim spine — every claim's rendered GROUNDED / SPECULATION / NO_RECEIPT state; only an eligible Cited row has a \"RCP-p{i}-s{j}\" receipt arrow into the pool below it. One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. NO_RECEIPT can mean a bad claim OR merely sparse evidence, so check that persona's `insufficientEvidence` / `sourcesFound` line before discounting it. (2) the SEPARATE market/competitor spine — same three rendered states; eligible Cited rows carry \"RRCP-s{n}\" receipt arrows into their own evidence pool; a NO_RECEIPT claim marked \"Cited\" means a supporting page was read and independently vouched but no exact span pinned (NOT a receipt), and an unmarked NO_RECEIPT is recalled model knowledge, unverified. Neither counts as grounded — key on the digest's rendered state and arrow, never raw state or whether a source id is present. (3) the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. (4) per-persona QA — a ⚠️ QA-FLAGGED persona failed a quality check (or could not be checked at all); do not rely on its claims. Its `identityPriors` (seniority rung, career path) are typed enrichment and `identityProvenance` is a PII-free aggregate calibration line — NEVER a receipt, do not cite it as a source. (5) the anti-sycophancy readout — explicit rejection count, `lowDiscrimination` broken-persona flags, and per-hypothesis disagreement splits. (6) The digest also reports hypothesis robustness: when a verdict FLIPPED under rephrasing it names the downgraded verdict to act on. Each re-tested row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. The typed `openQuestions[]` field is returned at `structuredContent.report_data.openQuestions`, where it lists what the run did not settle. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the result text under \"## Verdict rationale\", and typed at `structuredContent.report_data.verdictSummary`: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. When a section is missing the digest SAYS SO (\"NOT PRESENT on this run\") — absent is not clean, so treat the corresponding prose as unverified. The full structured `report_data` (hypotheses, competitors[], key findings, and every field summarised above) is also returned as `structuredContent.report_data`, mirrored in `_meta.report_data`. Use this to RETRIEVE past research instead of re-running `clien_research`, which would debit credits again for the same idea. Backs the competitor spot-check (read `report_data.competitors[]`) and pivot-viability (compare a pivot's report against the original) recipes in docs/recipes/. If the job is still running or you are unsure of its state, use `clien_research_status`. Read-only: no credit cost, no side effects.",
+   "description": "Retrieve the full report for a past `clien_research` job by its `job_id` (from a `list_reports` entry, which prints every run's id, or from the error text of a run that dropped mid-flight). Returns the markdown report as text, FOLLOWED BY A MACHINE-CHECKED TRUST DIGEST rendered into that same text — read the digest rather than trusting the prose. The digest carries: Raw typed `report_data` states, source ids, and attestation markers are stored audit data, not citation eligibility. Only the machine-checked TRUST DIGEST's rendered state and receipt arrow authorize Cited: the digest must resolve a canonical, spine-owned pointer to a safe reachable HTTP(S) destination. Dangling, malformed, cross-persona, unsafe, credentialed, or incomplete pointers degrade without an arrow and MUST NOT be cited. (1) the persona claim spine — every claim's rendered GROUNDED / SPECULATION / NO_RECEIPT state; only an eligible Cited row has a \"RCP-p{i}-s{j}\" receipt arrow into the pool below it. One discussion can carry several bounded excerpts. A claim addressing one shows a second id after \"·\" (form \"rr1:<16 hex>\"), and the receipt pool hangs that excerpt off the source row on its own \"↳\" line: read THAT line, not the row's first excerpt, as what the claim was checked against. These are excerpts from a discussion, never a speaker's exact words. A claim whose second id does not resolve under its own source loses the arrow entirely and MUST NOT be cited. NO_RECEIPT can mean a bad claim OR merely sparse evidence, so check that persona's `insufficientEvidence` / `sourcesFound` line before discounting it. (2) the SEPARATE market/competitor spine — same three rendered states; eligible Cited rows carry \"RRCP-s{n}\" receipt arrows into their own evidence pool; a NO_RECEIPT claim marked \"Cited\" means a supporting page was read and independently vouched but no exact span pinned (NOT a receipt), and an unmarked NO_RECEIPT is recalled model knowledge, unverified. Neither counts as grounded — key on the digest's rendered state and arrow, never raw state or whether a source id is present. (3) the SOURCE TYPE on every receipt — `user_voice` (a real person's first-hand account), `report_evidence` (authoritative/third-person reporting), `marketing_seo` (vendor marketing or SEO content), or `unclassified`. Every \"RRCP-\" market/competitor receipt carries a `source type:` line; a \"RCP-\" persona receipt is a first-hand `user_voice` post unless its row says otherwise, and any that is not carries the same line marked ⚠. `marketing_seo` is shown for awareness but is EXCLUDED from grounding AND from automatic community synthesis — it is vendor marketing or SEO content, never cite it as user evidence. `unclassified` is EXCLUDED from both as well, and means the classification is genuinely unknown, NOT that the source was checked and found benign. Before the proof separator, the result may include carefully labelled MODEL-AUTHORED report framing: `personasSynthesis` plus only the actionable parts of `researchBrief` (target market, value proposition, assumptions, competitive landscape, and key risks). This framing is NOT evidence or findings. Structured `report_data` also carries typed `methodology` without duplicating its existing markdown section, and a safe `interviewHighlights[]` projection with only `personaName`, `personaRole`, `overallImpression`, and `quotesByHypothesis` — internal `researchTaskId` is excluded. The trust digest includes a compact, code-derived competitor source-quality aggregate and names only rows flagged with the exact `marketing_seo` mark; it does not repeat competitor positioning or notes below the proof separator. (4) per-persona QA — a ⚠️ QA-FLAGGED persona failed a quality check (or could not be checked at all); do not rely on its claims. Its `identityPriors` (seniority rung, career path) are typed enrichment and `identityProvenance` is a PII-free aggregate calibration line — NEVER a receipt, do not cite it as a source. (5) the anti-sycophancy readout — explicit rejection count, `lowDiscrimination` broken-persona flags, and per-hypothesis disagreement splits. (6) The digest also reports each hypothesis's reconciled final verdict, categorical reliability, evidence sufficiency and explicit robustness outcome. When a verdict FLIPPED under rephrasing, the final verdict is monotone-guarded so malformed data cannot upgrade it. Each row quotes the hypothesis statement and any scope caveat. A scope caveat means persona support came from outside that persona's credibility domain: treat that support as directional, never grounded. A separate \"Scope caveats on hypotheses not re-tested\" block carries every such qualification on a single-shot verdict; those are not robustness results. The typed `openQuestions[]` field is returned at `structuredContent.report_data.openQuestions`, where it lists what the run did not settle. Its strict `status` is `never_asked`, `nobody_answered`, or `voices_disagreed`. When the run wrote one, its own verdict rationale is rendered in the result text under \"## Verdict rationale\", and typed at `structuredContent.report_data.verdictSummary`: 1-2 sentences the agent wrote at synthesis time saying WHY the overall verdict came out this way. It is RETRIEVED, not derived — never recompute or paraphrase it from the verdict counts or the confidence number. It is often ABSENT, which is normal and not an error: the run may predate the field, have written none, or have had it withdrawn because a robustness re-ask downgraded a verdict it argued for. When it is absent, say no rationale was recorded rather than inferring one. When a section is missing the digest SAYS SO (\"NOT PRESENT on this run\") — absent is not clean, so treat the corresponding prose as unverified. The full structured `report_data` (hypotheses, competitors[], key findings, and every field summarised above) is also returned as `structuredContent.report_data`, mirrored in `_meta.report_data`. Use this to RETRIEVE past research instead of re-running `clien_research`, which would debit credits again for the same idea. Backs the competitor spot-check (read `report_data.competitors[]`) and pivot-viability (compare a pivot's report against the original) recipes in docs/recipes/. If the job is still running or you are unsure of its state, use `clien_research_status`. Read-only: no credit cost, no side effects.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {

--- pinned/list_interview_scripts
+++ observed/list_interview_scripts
  {
-   "description": "Read the INTERVIEW SCRIPTS a Clien.ai research run wrote for a project — the questions that run decided are worth asking real people, one script per hypothesis, ranked least-settled first. Returns each script's hypothesis id, statement, verdict, confidence, who to recruit and its questions as readable text; the full set and the run it came from are also returned as `structuredContent.interviewScripts` / `.sourceRun` (mirrored in `_meta`). Requires a `project_id` — call `list_projects` to find one. CALL THIS BEFORE `interview_persona`. These questions are anchored to the run's open hypotheses, so the answers feed back into its claim spine; questions you invent, or re-derive from `get_report`'s hypothesis list, are not, and re-deriving them is recomputing something the run already produced and stored. STORED, NOT SUGGESTED: this is the persisted output of ONE SPECIFIC RUN, named in the result and written when that run executed. Nothing is generated to answer this call, now or ever — it is a free read of a report that is already immutable, so the verdict beside each script is that run's and may be older than today. NO SCRIPTS IS NOT \"NOTHING WORTH ASKING\": a project can legitimately have none, because scoped runs (`scan_competitors`, `search_forums`) never write them and a failed run writes nothing. The tool says so explicitly and you must not convert it into a claim that the hypotheses are settled. LINKAGE: pass a script's `hypothesisId` to `interview_persona action:start` as `hypothesis_id`, together with this call's `sourceRun.id` as `hypothesis_run_id`. The interview then RECORDS which hypothesis it tested and hands it back on `get_interview` / `list_interviews`, so the tie survives without you carrying the id. Both or neither — an id is only meaningful against the run that defined it. TRUST: the verdicts and confidences here are the source run's reading of its own hypotheses, not graded claims — no GROUNDED / SPECULATION / NO_RECEIPT states attach to them; read the source run with `get_report` for those. Read-only: no credit cost, no side effects.",
+   "description": "Read the INTERVIEW SCRIPTS a Clien.ai research run wrote for a project — the questions that run decided are worth asking real people, one script per hypothesis, ranked by what most needs a real answer — product priority, then the least reliable verdicts, then the thinnest evidence. Returns each script's hypothesis id, statement, verdict, confidence, who to recruit and its questions as readable text; the full set and the run it came from are also returned as `structuredContent.interviewScripts` / `.sourceRun` (mirrored in `_meta`). Requires a `project_id` — call `list_projects` to find one. CALL THIS BEFORE `interview_persona`. These questions are anchored to the run's open hypotheses, so the answers feed back into its claim spine; questions you invent, or re-derive from `get_report`'s hypothesis list, are not, and re-deriving them is recomputing something the run already produced and stored. STORED, NOT SUGGESTED: this is the persisted output of ONE SPECIFIC RUN, named in the result and written when that run executed. Nothing is generated to answer this call, now or ever — it is a free read of a report that is already immutable, so the verdict beside each script is that run's and may be older than today. NO SCRIPTS IS NOT \"NOTHING WORTH ASKING\": a project can legitimately have none, because scoped runs (`scan_competitors`, `search_forums`) never write them and a failed run writes nothing. The tool says so explicitly and you must not convert it into a claim that the hypotheses are settled. LINKAGE: pass a script's `hypothesisId` to `interview_persona action:start` as `hypothesis_id`, together with this call's `sourceRun.id` as `hypothesis_run_id`. The interview then RECORDS which hypothesis it tested and hands it back on `get_interview` / `list_interviews`, so the tie survives without you carrying the id. Both or neither — an id is only meaningful against the run that defined it. TRUST: the verdicts and confidences here are the source run's reading of its own hypotheses, not graded claims — no GROUNDED / SPECULATION / NO_RECEIPT states attach to them; read the source run with `get_report` for those. `confidence` is low/medium/high and describes how RELIABLE the verdict is, never the probability the hypothesis is true; an older run may instead carry a `legacyConfidence` number on a retired scale that must not be compared with it. Read-only: no credit cost, no side effects.",
    "inputSchema": {
      "additionalProperties": false,
      "properties": {
-         "description": "UUID of the project whose interview scripts to read. Get it from `list_projects` (or `create_project`). Rejected with a 404 if you do not own the project. Returns the STORED OUTPUT OF ONE SPECIFIC RESEARCH RUN — the scripts that run wrote when it ran, one per hypothesis, ranked least-settled first — not a live suggestion and not something generated when you call this. The run is named in the result; pass its id to `get_report` for the hypotheses behind the questions. A project can legitimately have NO scripts; that is reported as \"no run has written any\", never as \"there is nothing worth asking\".",
+         "description": "UUID of the project whose interview scripts to read. Get it from `list_projects` (or `create_project`). Rejected with a 404 if you do not own the project. Returns the STORED OUTPUT OF ONE SPECIFIC RESEARCH RUN — the scripts that run wrote when it ran, one per hypothesis, ranked by what most needs a real answer — not a live suggestion and not something generated when you call this. The run is named in the result; pass its id to `get_report` for the hypotheses behind the questions. A project can legitimately have NO scripts; that is reported as \"no run has written any\", never as \"there is nothing worth asking\".",
          "format": "uuid",
          "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
          "type": "string"

Current tools

Watch this server yourself

If you run this server, put the proxy in front of it. It pins these exact fingerprints on first connect and stops the session if they move.

npx -y mcp-pin@0.2.3 -- <your @clien-ai/mcp command>

Or subscribe to this page's RSS feed to be told when it changes.

Badge

The badge states one fact about time and nothing else. It never claims a server is safe.

[![mcp-pin](https://mcp-pin.gautamkhosla.com/badge/71ad2d72d950a4dc.svg)](https://mcp-pin.gautamkhosla.com/servers/71ad2d72d950a4dc.html)