Server data from the Official MCP Registry
Feynman's twelve-problems method as an MCP server: dormant problems + an evoke loop for new tricks.
Feynman's twelve-problems method as an MCP server: dormant problems + an evoke loop for new tricks.
This is a well-designed local MCP server for persistent problem tracking with solid security fundamentals. It operates entirely on the local filesystem with no network or external API dependencies, no authentication requirements (appropriate for local-only operation), and clean code structure. Minor code quality observations around input validation and error handling exist but do not present material security risks. Supply chain analysis found 2 known vulnerabilities in dependencies (0 critical, 2 high severity). Package verification found 1 issue.
5 files analyzed · 6 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
Set these up before or after installing:
Environment variable: SEVEN_DPT_DB
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-pierreb4-seven-dpt-mcp": {
"env": {
"SEVEN_DPT_DB": "your-seven-dpt-db-here"
},
"args": [
"-y",
"seven-dpt-mcp"
],
"command": "npx"
}
}
}From the project's GitHub README.
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.
The server holds state and scaffolding; the connected model does the thinking — no LLM runs inside the server, no API key.
| Tool | Purpose |
|---|---|
add_problem | Add a long-running problem to your set |
list_problems | See your open problems |
get_problem | One problem + every spark (idea, next step, outcome) — the memory |
evoke | The loop. Feed it a trick; returns your problems + a scaffold walking evocation → transcendence → approach |
capture_spark | Persist a candidate idea + concrete next step against a problem (+ an optional cost estimate) |
update_spark | Record a spark's outcome — status (tried/worked/failed), cost (effort spent), value (graded payoff, 0 for a miss). Log failures too; the zero-value outcomes are the signal a background-effort policy is learned from |
Storage: ~/.local/share/seven-dpt/store.json (override with SEVEN_DPT_DB). One store,
shared by every project = one brain.
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 cost (effort to a verdict) and,
once resolved, 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.
Published on npm — no build step. Register it for every project (user scope):
claude mcp add --scope user seven-dpt -- npx -y seven-dpt-mcp
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.)
add_problem.evoke it; watch Claude test it
against every problem and reframe the ones that light up.capture_spark the hits, then update_spark once you've tried them.get_problem — if that accumulated trail feels useful, the idea's proven.retire/solve/update_problem yet — the 12-cap only warns. (Tracked as one of
seven-dpt's own seeded problems.)evoke matching is done by the connected model, not pre-ranked by embeddings.Apache-2.0 — see LICENSE.
Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
by Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.