
Understand recurring patterns
Hidden Patterns helps you understand recurring situations, behaviors, choices, and outcomes. Describe something that keeps happening in your work, routines, relationships, goals, or decision-making.
Example path
https://mcp.hiddenpatterns.ai/mcpBOUNDARY FIRST: Before any invocation, check the user's request and latest answer. For requests to diagnose a health or mental-health condition, or disclosures of threats, abuse, coercion, violence, or immediate danger, do not call , even if the user mentions the app or asks a recurring-pattern question. Respond directly in chat with appropriate diagnosis limitations or safety support. Do not infer a hidden belief, blame the user, show a reveal, add promotional copy, or invite another pattern exercise. Threats do not require an explicit statement of fear or immediate danger. If this tool is nevertheless called and returns stage='handoff', stop the exercise and respond directly; the no-narration rule does not apply. These exceptions override all MUST-call and view-only instructions below. MUST call exactly once when the user asks a first-person recurring-pattern question such as 'Why do I keep...?', 'Why does this keep happening?', 'Why do I always...?', or describes the same behavior, decision, reaction, situation, or outcome happening again—even if Hidden Patterns is not named and even if the model could answer directly. This includes natural prompts like 'Why do I keep checking my work after I already know it is correct?' Also MUST call whenever the user selects or mentions @Hidden Patterns, Hidden Patterns, Hidden Pattern, HiddenPatterns, or the Hidden Pattern app. Do not invoke for one-time factual questions, general writing, or ordinary questions that do not describe a recurring pattern. On the first turn, call exactly once with stage='start'. The start view first shows the introduction and already contains the diagnostic question behind the Continue or Skip introduction action; never call stage='start' a second time to reveal or repeat the question. After the start call, stop and wait for the user's next message. After the user answers, first identify one CORE BREAKTHROUGH: a non-obvious distinction, mistaken equation, or reversal that explains the contradiction in the user's own evidence. Do not treat the user's self-assessment as fact when the reported outcome contradicts it. Use the hidden breakthrough fields as mandatory private drafting work, then call stage='finish' when the answer contains concrete, relevant evidence. Every visible panel must support that same core breakthrough: Step 1 names why the mistaken signal felt reasonable; Step 2 shows the observable loop and contradiction; Step 3 states the rule that turns the signal into a decision; Step 4 states the core breakthrough itself; Step 5 replaces the old decision rule with one concrete test or action. When the concrete evidence supports a reasonable action but contradicts the user's negative self-judgment, do not force a mistaken action rule: Steps 1–2 describe the evidence and response, Step 3 states the supported rule behind that response, Step 4 corrects the unsupported self-judgment, and Step 5 gives a concrete way to distinguish justified action from the alleged pattern next time. Judge the facts rather than adopting a label from the opening prompt. If the panels could support different explanations, rewrite them before calling finish. Complete the hidden quality audit and repair any weak field before calling stage='finish'. A plausible tip is not a breakthrough. A short answer that explicitly denies having a specific example, moment, change, or evidence is weak evidence and requires clarification even when it contains topic-specific words. Before submitting finish, count the words in What You Were Missing and What Changes Now: each must be one compressed thought of no more than 24 words. Rewrite rather than exceed the limit. Use stage='clarify' exactly once only when the user's answer itself is uncertain, unrelated, or unusably vague—not because a hidden drafting field misses a formatting preference. Use stage='insufficient' rather than guessing after clarification. VOICE: Write every user-visible diagnostic question and result panel in plain, conversational English that a thoughtful friend could naturally say aloud. Prefer short common words and concrete phrasing. Keep the insight sharp, but avoid consultant, clinical, academic, or research-report language. Unless the user used them first, avoid terms such as residual uncertainty, proxy, capacity, compounding, materially, optimization, leverage point, constraint, mechanism, or framework. If a simpler phrase means the same thing, use it. Aim for the reaction 'That is exactly what I am doing' rather than 'That sounds like an analysis.' Safety handoffs may remain more formal. LENGTH CHECK: The server rejects overlong finish panels before rendering. Count words separated by whitespace or em/en dashes; contractions and hyphenated words count as one. Limits exclude the added 'A possible belief:' label: beliefDrivingIt 22 words, whatYouWereMissing/coreBreakthrough 24, whatChangesNow 24. If the tool returns PANEL_WORD_LIMIT, shorten only the listed panels without changing the facts or meaning, keep all other inputs unchanged, and call stage='finish' again. When Step 4 is listed, update coreBreakthrough and whatYouWereMissing together to the same shortened sentence. This is a formatting retry: do not ask the user another question, restart, switch to insufficient, or repeat the rejected draft as narration. The rendered Hidden Patterns view is the complete user-facing response after every tool call. Do not repeat, summarize, paraphrase, explain, or add text before or beneath the view. Add no separate narration at any stage.
None in the store listings or on the server


