io.github.pierreb4/seven-dpt-mcp
NPM · SEVEN-DPT-MCP · SCANNED OCT 2
Feynman's twelve-problems method as an MCP server: dormant problems + an evoke loop for new tricks.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 31 of 93 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 58 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability68
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1604 tokens (~200/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management80
- Stability observed for 24 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 8 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the io.github.pierreb4/seven-dpt-mcp server?
io.github.pierreb4/seven-dpt-mcp runs locally as an npm package, launched with npx -y seven-dpt-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · seven-dpt-mcp
claude mcp add pierreb4-seven-dpt-mcp -- npx -y seven-dpt-mcp
{
"mcpServers": {
"pierreb4-seven-dpt-mcp": {
"command": "npx",
"args": [
"-y",
"seven-dpt-mcp"
]
}
}
} {
"servers": {
"pierreb4-seven-dpt-mcp": {
"command": "npx",
"args": [
"-y",
"seven-dpt-mcp"
]
}
}
} codex mcp add pierreb4-seven-dpt-mcp -- npx -y seven-dpt-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"pierreb4-seven-dpt-mcp": {
"type": "local",
"command": [
"npx",
"-y",
"seven-dpt-mcp"
],
"enabled": true
}
}
} openclaw mcp add pierreb4-seven-dpt-mcp --command npx --arg -y --arg seven-dpt-mcp
mcp_servers:
pierreb4-seven-dpt-mcp:
command: "npx"
args: ["-y", "seven-dpt-mcp"] {
"McpServers": {
"pierreb4-seven-dpt-mcp": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"seven-dpt-mcp"
]
}
}
} assistant mcp add pierreb4-seven-dpt-mcp -t stdio -c npx -a -y seven-dpt-mcp
{
"mcpServers": {
"pierreb4-seven-dpt-mcp": {
"command": "npx",
"args": [
"-y",
"seven-dpt-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 2 Oct 26 −3
- Stability: pass → 0.80 functional
- 1 Oct 26 +1
- Stability: 0.97 → pass security
- 29 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 25 Sept 26 −3
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 24 Sept 26 +1
- Stability: 0.97 → pass security
- 22 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 2 Oct 2026 · Analysed npm/seven-dpt-mcp@0.1.5
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 93 packages
| Packages resolved | 93 |
|---|---|
| Stale | 31 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_problem Add a favorite problem ~143
Add a long-running problem to your global Feynman set — the ~dozen you keep dormant in mind across every project. Keep the active set small; that constraint is the method.
| Name | Type | Req | Description |
|---|---|---|---|
| origin | string | – | Where it came from (project, context) |
| overCap | boolean | – | Override the ~twelve-problem cap for this add (only after weighing a retire/merge first — the cap is the method) |
| statement | string | – | Fuller description / what 'solved' would look like |
| tags | array | – | Freeform tags, e.g. domains or project names |
| title | string | yes | Short name for the problem |
No output schema declared.
No examples provided.
capture_spark Capture a spark (approach motivation) ~502
Persist a candidate solution plus a concrete next step against a problem — the output of a successful evocation. This is the memory that lets long-running issues progress across sessions.
| Name | Type | Req | Description |
|---|---|---|---|
| claimType | string | – | Logical type of the claim, so a null result kills the right thing: 'universal' = a clean null anywhere kills the CLAIM; 'existential-bounded' = the claim asserts existence within a named frame, so a… |
| cost | number | – | Legacy alias for costToOpen at capture time (kept for older callers). Prefer costToOpen. |
| costToOpen | number | – | Rough EXPECTED effort to chase this spark to a verdict, on a consistent scale (e.g. minutes, or a 1-5 effort score). This is the Pandora 'cost to open' the spend-policy ranks on — the a-priori estima… |
| exhaustion | string | – | The retirement predicate: when to ABANDON this spark rather than re-park it (the dual of wakeCondition — wake says when it revives, exhaustion says when it dies). E.g. 'second unpowered read at n>=50… |
| forbids | string | – | One sentence naming an observation this spark RULES OUT — the content statement (a spark that forbids nothing is unfalsifiable spend). Write-once, immutable like `prior`: revising it after results is… |
| idea | string | yes | The candidate solution or insight |
| nextStep | string | yes | ONE concrete next experiment or action |
| prior | number | – | Your honest stated probability (0-1) at capture that chasing this spark yields a worked outcome. IMMUTABLE afterwards — update_spark cannot revise it — so stated credences can later be calibrated aga… |
| problemId | integer | yes | Which problem this advances |
| trick | string | yes | The trick / stimulus that evoked it |
| wakeCondition | object | – | Optional: park this spark behind a computable gate from birth (captured now, actionable when X) — the ambient digest evaluates it and surfaces ripeness. |
No output schema declared.
No examples provided.
evoke Evoke — test a new trick against all your problems ~92
The core loop. Give it a trick, result, idea, or observation you just encountered. Returns your open problems plus a scaffold that walks you through evocation -> transcendence -> approach. Call this whenever you learn something that might generalize.
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | – | Optional: which project you're in right now |
| trick | string | yes | The new trick / result / insight / observation to test against your problems |
No output schema declared.
No examples provided.
get_problem Get a problem and its history ~49
Show one problem plus every spark (idea + next step + outcome) captured against it — the long-running memory that makes a stuck issue accumulate progress across sessions.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | Problem id |
No output schema declared.
No examples provided.
list_problems List your favorite problems ~39
Show your global set of long-running problems. Defaults to open ones only.
| Name | Type | Req | Description |
|---|---|---|---|
| includeClosed | boolean | – | Also show solved/retired problems |
No output schema declared.
No examples provided.
update_problem Update / retire / solve a problem ~256
Edit a problem or move it out of the active set — the retire/solve/merge loop that keeps the set near twelve. When closing (status solved/retired), write a resolution saying WHY plus, for a retirement, the explicit RE-OPEN trigger: a retired problem is parked with a wake condition, not deleted. A merge is a retirement whose resolution names the absorbing problem. Reopen later by setting status back to open.
| Name | Type | Req | Description |
|---|---|---|---|
| framing | string | – | New framing (the 'instance of what?' reframe) |
| id | integer | yes | Problem id |
| resolution | string | – | Why it left the open set + the re-open trigger in prose (write one whenever closing; for a merge, name the absorbing problem) |
| statement | string | – | New fuller description |
| status | string | – | open (reopen) | solved | retired |
| tags | array | – | Replace the tag list |
| title | string | – | New short name |
| wakeCondition | – | – | Structured, COMPUTABLE re-open trigger — the machine half of the resolution prose. The ambient digest evaluates it every session and surfaces ripeness (see wake_status). Parked problems only; pass nu… |
No output schema declared.
No examples provided.
update_spark Record a spark's outcome ~466
Record what happened when you acted on a spark — an outcome note, a new status (tried / worked / failed), and ideally the cost (effort spent) and value (graded payoff). LOG FAILURES TOO: 'most bets fail' is the premise of problem #2, so failed and zero-value outcomes are exactly the signal a spend-policy is learned from — recording only wins makes the history unusable. This outcome history is what lets the system learn when surfacing a dormant problem is worth the attention.
| Name | Type | Req | Description |
|---|---|---|---|
| claimType | string | – | Backfill the claim's logical type IF never stated (write-once: ignored when already set). 'universal' = a null kills the claim; 'existential-bounded' = a null kills only the tested frame. |
| cost | number | – | ACTUAL effort spent chasing it to a verdict (same scale as capture's estimate). |
| costToOpen | number | – | Revise the FORWARD cost-to-open estimate (uncommon — normally set once at capture). Resolution never changes it automatically. |
| exhaustion | string | – | State the retirement predicate (when to ABANDON rather than re-park — the dual of wakeCondition) IF never stated. Write-once. A parked spark with a wake but no exhaustion is unkillable-in-practice; l… |
| forbids | string | – | Backfill the content statement (one observation this spark rules out) IF never stated. Write-once: an existing forbids is immutable — revising it after results is the post-hoc rescue it exists to blo… |
| id | integer | yes | Spark id |
| outcome | string | – | What happened when you tried it |
| status | string | – | New status for the spark |
| value | number | – | Graded payoff of the outcome: 0 if it failed or yielded nothing, higher for bigger wins (heavy-tailed). The reward signal the budget policy is fit on — log it for failures too. |
| wakeCondition | – | – | Park a HOLD/STOPped spark with its computable re-run trigger — the digest owns the wait (see wake_status). Pass null to clear; resolving worked/failed auto-clears. |
No output schema declared.
No examples provided.
wake_status Wake-condition ledger ~57
Evaluate every parked problem/spark's wakeCondition right now: ripeness, progress, and current/target echoes per atom. Read-only. The ambient digest shows the compact version at session start; this is the full view for curation passes.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
What is the io.github.pierreb4/seven-dpt-mcp server?
io.github.pierreb4/seven-dpt-mcp is listed in the public MCP registry as io.github.pierreb4/seven-dpt-mcp. Feynman's twelve-problems method as an MCP server: dormant problems + an evoke loop for new tricks. This page covers its npm package (seven-dpt-mcp).
Is the io.github.pierreb4/seven-dpt-mcp server safe to use?
io.github.pierreb4/seven-dpt-mcp scores 80 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 2 October 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.pierreb4/seven-dpt-mcp server expose?
io.github.pierreb4/seven-dpt-mcp exposes 8 tools: add_problem, update_problem, list_problems, get_problem, evoke, and 3 more. Their descriptions and schemas cost roughly 1,604 tokens of context every time the server is loaded.
Is the io.github.pierreb4/seven-dpt-mcp server still maintained?
io.github.pierreb4/seven-dpt-mcp is still listed as active in the MCP registry. We last reached this channel on 2 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the io.github.pierreb4/seven-dpt-mcp server under?
io.github.pierreb4/seven-dpt-mcp declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.