powerplan
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_current_iterationA | JSON for the current iteration (what to work on now). Preferred agent entry — avoids reading all of PLAN.md. |
| get_iterationC | JSON for one iteration by version (goal, tasks, progress). |
| list_iterationsB | List iterations filtered by open | complete | all. |
| find_taskC | Locate tasks by substring match (JSON). |
| get_backlogC | Backlog section items (JSON). |
| show_miniplanA | Raw PLAN.md snippet: the current (or named) iteration byte-for-byte under its major header, with the neighbouring iterations collapsed to their header lines. The plan's own format is the view — start every session here instead of reading the whole file. |
| show_current_iterationA | ASCII view of the resolved current iteration (humans/logs). |
| show_planA | Compact index: counts + current iteration. Agents should prefer get_current_iteration / get_iteration over this or full PLAN.md. |
| check_planC | Structure lint: duplicates, multiple current, complete-with-open-tasks. |
| create_planA | Bootstrap a new PLAN.md when none exists (powernote-style skeleton). Default path: ./PLAN.md in cwd. Refuses overwrite unless force=true. |
| create_majorC | Create ## vX.Y — Title major section. |
| create_iterationD | Create ### vX.Y.Z — Title iteration. |
| set_iteration_goalC | Set/replace Goal: on an iteration. |
| add_taskC | Append a checkbox task to an iteration. |
| add_tasksA | Append several checkbox tasks in one write. Prefer this over repeated add_task. Shared done/agent apply to every item. |
| complete_taskA | Tick one or many tasks in one write. For several, pass indexes (preferred after get_iteration) or tasks. For exactly one, index or task still work. |
| reopen_taskA | Untick one or many tasks in one write. For several, pass indexes or tasks. For exactly one, index or task still work. |
| update_taskB | Rewrite task text, preserving done state. One task: text + index/task. Several: changes[{text, index|task, expect?}]. |
| remove_taskA | Delete one or many tasks in one write. For several, pass indexes or tasks. Resolve-all then drop (indexes do not shift). |
| defer_taskA | Move one or many tasks to the backlog in one write. For several, pass indexes or tasks. Shared reason/agent apply to every item. |
| add_to_backlogB | Append one (text) or many (texts) items to Future (Backlog) in one write. |
| append_proseC | Append freeform markdown at top level. |
| start_iterationA | Mark iteration ACTIVE / current; clears other current markers. |
| close_iterationB | Mark iteration COMPLETE. Requires force=true if open tasks remain. Optional stamp (e.g. date) appended to title. |
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 24 tools
Most tools target distinct resources, but there is notable overlap in the view/entry-point family: show_miniplan, show_current_iteration, show_plan, get_current_iteration, and get_iteration all retrieve current or selected plan state in different formats. Descriptions help, yet show_miniplan and get_current_iteration both claim to be the preferred entry, which creates ambiguity.
The set mostly follows a clear verb_noun pattern: create_iteration, get_iteration, update_task, remove_task, close_iteration, etc. Minor inconsistencies exist, such as add_task vs add_tasks, append_prose, and show_miniplan, but overall the convention is predictable and readable.
24 tools is on the heavy side for a plan-management server, and some operations could be consolidated (add_task/add_tasks, multiple show/get variants). The count is not extreme, but the surface feels larger than necessary for the domain.
The lifecycle coverage is strong: plans can be bootstrapped, majors and iterations created, tasks added/updated/completed/reopened/removed/deferred, and iterations started/closed. Minor gaps exist, such as no explicit way to delete an iteration or major section, but core workflows are well-covered.