seven-dpt-mcp
The seven-dpt-mcp server helps you manage a persistent set of long-running problems using Feynman's "twelve favorite problems" method, enabling cross-session idea capture and progress tracking.
Add problems (
add_problem): Register up to ~12 persistent problems with a title, description, origin, and tags. The cap enforces the method's constraint of keeping the set small.List problems (
list_problems): View open (or all, including closed) problems at a glance.Retrieve full history (
get_problem): Get a single problem along with every spark ever captured against it — forming a persistent memory across sessions.Run the evocation loop (
evoke): Feed in a new trick, insight, or observation; the server returns your open problems plus a scaffold guiding you through evocation → transcendence → approach motivation, testing whether the new idea applies to any dormant problem.Capture a spark (
capture_spark): Persist a candidate idea and concrete next step against a specific problem, with an effort estimate and probability it will work.Record outcomes (
update_spark): Log what happened when you acted on a spark — status (tried/worked/failed), actual effort spent, and graded payoff. Failures are explicitly encouraged to build a reward history.Retire/solve/reopen problems: Attach computable
wakeConditions to parked problems or sparks to surface ripe opportunities for re-evaluation.Self-seeds on first run: Seeds five foundational problems automatically, so the system can immediately dogfood its own method and build an initial history.
seven-dpt-mcp
A tiny, local MCP server that gives Claude (in any project) a persistent set of long-running problems and a loop for cracking them — Feynman's twelve favorite problems method, driven by the tripartite model of inspiration.
Feynman's method (via Gian-Carlo Rota): keep ~a dozen problems dormant in mind; every time you meet a new trick, test it against all of them.
Inspiration = evocation + transcendence + approach motivation (Thrash & Elliot): a stimulus evokes a possibility, you transcend the problem's current framing, then you're motivated to act on it.
The server holds state and scaffolding; the connected model does the thinking — no LLM runs inside the server, no API key.
Tools
Tool | Purpose |
| Add a long-running problem to your set (refused past the ~12 cap until you retire/merge something — or pass |
| Edit, retire, solve, or reopen a problem. Closing takes a |
| See your open problems |
| One problem + every spark (idea, next step, outcome) — the memory |
| The loop. Feed it a trick; returns your problems + a scaffold walking evocation → transcendence → approach |
| Persist a candidate idea + concrete next step against a problem (+ optional |
| Record a spark's outcome — status (tried/worked/failed), |
| Evaluate every parked problem/spark's |
Storage: ~/.local/share/seven-dpt/store.json (override with SEVEN_DPT_DB). One store,
shared by every project = one brain.
Related MCP server: CotForce-MCP
Wake conditions (0.1.4)
Retiring a problem parks it with a re-open trigger — but a trigger written in prose is a
wait owned by "someone will remember." A wakeCondition makes it computable: a small
predicate (all/any over atoms like sparkCount, a date gate, fileMatches /
fileLines / fileCount on a path, or an explicit manual note) attached when you
retire/solve a problem (update_problem), park a spark (update_spark), or capture one
born gated (capture_spark). The ambient digest evaluates every condition at session
start and surfaces what's ripe (with an act/re-park pointer), what's ripening (with
current/target progress), and — loudly — any condition whose source became unreadable:
a wake source that vanished must scream, not sit at 0% forever. Everything echoes its aim
(prior-ledger.jsonl 12/20), so a wrong path or unit is visible when you arm it, not
months later. No auto-reopen: ripeness is surfaced, you decide. --wake prints the full
ledger from the CLI.
How it bootstraps
On first run (no store file yet), the store seeds itself with seven-dpt's own five open
product problems — auto-detection of recurring issues, the background-spend policy,
proactive surfacing, keeping the set near twelve, and storage scaling. Design decision,
made deliberately: the seeds are tool-generic (identical for every install, about the
tool rather than about you), so the server dogfoods its own method from minute one and the
ambient digest has something to show before you add your own problems. They are ordinary
rows in your store — edit, replace, or clear them freely; an existing store is never
touched. So the moment it runs it is already "taking care of its own problems": while you
work on anything else, those sit in context and can be sparked by unrelated discoveries.
The policy for how/when/how-much to chase background problems is deliberately not
coded — it's meant to be learned later from the accumulated spark → outcome history,
which is why update_spark exists.
That history is the reward channel: each spark carries a prior (your stated probability-it-works
at capture — immutable afterwards, so stated credences can be calibrated against realized outcomes
once enough sparks resolve), a costToOpen (the forward effort estimate, set at capture and
preserved), a cost (the actual effort, once chased to a verdict), and a value
(graded payoff, 0 for a miss). analysis/reservation_value.py turns it into a Pandora's-Box / Gittins
reservation-value ranking — but it gates on data sufficiency and refuses to emit numbers until enough
resolved sparks (with cost + value, including failures) accrue, so the policy is never fit on false
precision. A companion, analysis/reservation_value_bayes.py, adds a posterior-predictive prior (so it
can rank under sparse data) and models the one-time costToOpen against a compounding-but-saturating
benefit stream — ranking by profitability index, which is invariant to the value↔cost exchange rate.
analysis/calibration.py closes the loop on the prior field: it audits stated priors against realized
outcomes (reliability table, Brier/skill, drift check) from any two-line JSONL ledger of
pre-registered priors + resolutions, and --json persists a de-bias map that
reservation_value_bayes.py picks up — so the index runs on calibrated stated credences instead of a
deemed hit-rate.
Install (turn on for all projects)
Via npm (recommended)
Published on npm — no build step. Register it for every project (user scope):
claude mcp add --scope user seven-dpt -- npx -y seven-dpt-mcpFrom source (alternative)
npm install && npm run build
# Register for every project (user scope). Use an ABSOLUTE node path — hooks and MCP
# servers don't source your shell profile, so nvm-style setups need one:
claude mcp add --scope user seven-dpt -- "$(command -v node)" "$(pwd)/dist/index.js"Then make the problems ambient — merge into ~/.claude/settings.json so every
session opens with your dormant problems in context:
{
"hooks": {
"SessionStart": [
{ "matcher": "startup", "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] },
{ "matcher": "resume", "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] },
{ "matcher": "clear", "hooks": [{ "type": "command", "command": "npx -y seven-dpt-mcp --digest", "timeout": 10 }] }
]
}
}(Installed from source instead? Replace each command with an absolute node path +
/absolute/path/to/seven-dpt-mcp/dist/index.js --digest — hooks don't source your shell
profile, so nvm-style setups need the absolute path.)
(--digest prints nothing when no problems are open; a fresh install prints the five
seeded ones — that's the bootstrap working, not noise.)
Validate the idea
Add a few of your own long-running problems —
add_problem.When you hit an interesting technique in any repo,
evokeit; watch Claude test it against every problem and reframe the ones that light up.Let it
capture_sparkthe hits, thenupdate_sparkonce you've tried them.Days later,
get_problem— if that accumulated trail feels useful, the idea's proven.
Known MVP limits (intentional)
JSON file, last-write-wins (fine for one user).
evokematching is done by the connected model, not pre-ranked by embeddings.
License
Apache-2.0 — see LICENSE.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseAqualityDmaintenanceA TypeScript Model Context Protocol (MCP) server to allow LLMs to programmatically construct mind maps to explore an idea space, with enforced "metacognitive" self-reflection.Last updated52728MIT
- AlicenseAqualityCmaintenanceGive brains to your small models. MCP server that enforces step-by-step Chain-of-Thought — turns 4B models into methodical reasoners.Last updated155MIT
- Alicense-qualityDmaintenanceAn MCP server enabling AI agents to record, query, and share structured problem-solving experiences with human review and confidence decay.Last updated7MIT
- Alicense-qualityBmaintenanceOne MCP that turns Claude Code into your whole dev stack by swallowing other MCP servers, delegating to Codex & Gemini on your CLI subscriptions, remembering projects in a searchable knowledge graph, and carrying setup across sessions — secret-free by design.Last updated1MIT
Related MCP Connectors
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Person-owned, portable AI memory as a remote MCP server, readable and writable by any MCP client.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pierreb4/seven-dpt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server