seven-dpt-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SEVEN_DPT_DB | No | Override path for the store file | ~/.local/share/seven-dpt/store.json |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| add_problemA | 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. |
| list_problemsA | Show your global set of long-running problems. Defaults to open ones only. |
| get_problemA | 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. |
| evokeA | 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. |
| capture_sparkA | 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. |
| update_sparkA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct action: adding problems, capturing sparks, recalling problems with evocation, viewing one problem, listing all, and updating spark outcomes. No two tools serve overlapping purposes.
Most tools follow snake_case verb_noun pattern (add_problem, capture_spark, get_problem, list_problems, update_spark), but 'evoke' is a single verb without a noun, breaking the pattern slightly.
With 6 tools, the set is well-scoped for the problem management domain it serves. Each tool has a clear role without redundancy, and the count feels neither too sparse nor too heavy.
The tools cover core workflows: add problems, generate and update sparks, and list/retrieve. Missing are deletion capabilities and the ability to modify spark ideas directly, but these are minor gaps given the specific methodology.