Task Runner
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TASK_RUNNER_DB | No | Path to the database file (default is ~/.task-runner/memory.db). | |
| TASK_RUNNER_HOME | No | Folder for the database instead of a file (default is ~/.task-runner). | |
| TASK_RUNNER_PROJECT | No | The project key. The server finds the project from its working directory; set this when your client starts servers in another directory. | |
| TASK_RUNNER_REMOTE_KEY | No | The key for the remote Task Runner server, set instead of passing it on the command line, so it stays out of your shell history. | |
| TASK_RUNNER_WORKLOG_EXCLUDE | No | Hides projects from the worklog report, e.g. "app-*,scratch". `*` is a wildcard. |
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 |
|---|---|
| set_contextA | Override the auto-detected project, branch or PR for this session. Optional: the project is detected from the working directory, so call it only to correct the scope. |
| list_projectsA | Projects that have memory, newest first. Rarely needed: the current project is detected. |
| get_contextA | Recent saved notes for this project (project-wide notes plus the current branch and PR). Long notes are clipped unless full is set. |
| save_memoryA | Save a session note (what was done, decided or found) for this project. Use remember for durable facts; use this for narrative. |
| rememberA | Create or update a knowledge-graph entity and add facts to it (an existing name is extended, duplicates are skipped). One fact per item, under 1000 characters; the name stays short. Add keywords so later searches find it. Entities named in the facts are linked automatically, and facts that seem to contradict a stored one come back as possible_conflicts. Scope 'global' is for facts about the user that hold in every project. |
| correct_factA | Replace a wrong or outdated fact (by the id recall and what_do_i_know show), or retire it by omitting new_fact. |
| linkA | Connect two existing entities, or with remove: true disconnect them. Types are needed only when a name matches more than one entity. |
| recallA | Search memory by keywords: graph entities with their dated facts, linked entities as related, and matching notes. Matching ignores accents, finds word starts and stems, and falls back to parts of words; it is not meaning-based, so search with the words, synonyms and both languages the facts would use. Includes global facts. Start work with this. |
| what_do_i_knowB | Everything about one entity: dated facts, direct relations and neighbours up to two hops away. |
| forgetA | Retire an entity with its facts and relations. It stops appearing in searches; the data stays in the database. |
| graph_statsA | Counts of entities, relations, facts and notes, orphan entities (no relations) and the top entities. With check: also old low-importance entities and notes, and file entities whose path no longer exists. |
| rulesA | The user's standing rules for this project, organization and device, as injected at session start. action 'show' returns them. action 'propose' queues a rule the user explicitly asked to make standing; the user approves it in the panel, the web page or the CLI. Preferences you pick up from the conversation go to the taste tool instead. Never propose secrets or one-off instructions. |
| tasteA | How the user wants things, learned from what they said: style, workflow, wording, tools. They are injected at session start and apply at once, with no approval. action 'show' lists them with ids. action 'learn' records what a message taught: 'new' for a wish not seen before, 'reinforce' when they say an existing one again, 'refine' when they adjust it, 'replace' when they now want something different on the same point, 'drop' when they take it back. Write each rule as a general, short instruction (one step more general than the message, never their words as a log). scope 'global' for how they work everywhere, 'org' for this organization, 'project' for this codebase. In Claude Code the panel learns these by itself; call learn when the user asks you to remember how they want something. Never store secrets or people's private data. |
| worklogA | How long the user and the agent worked, per project and task (a branch or ticket), for a period. Read from the session transcripts. Use it to answer 'how much time did I spend on X this week' or 'what did I do this week'. Agent time adds up across parallel sessions; wall time counts each minute once. |
| create_task_groupA | Split work into ordered tasks, from markdown ('## Task 1: Title' sections) or a tasks array. Then loop get_next_task, do the task (ideally in a subagent), complete_task. |
| get_next_taskA | Claim the next pending task and mark it running. A task running for over 30 minutes counts as abandoned and is offered again. |
| complete_taskA | Record the outcome of a task: done with its result, or failed with the reason. Elapsed time is measured automatically. |
| get_task_statusA | Summary counts and every task's status for a group; with task_id, that task in full including its result or error. |
| clear_tasksA | Delete one task group, or all task groups of this project. Memory is not touched. |
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 19 tools
The memories cluster (save_memory / remember / correct_fact / recall / get_context / what_do_i_know) has real boundary overlap, though most descriptions explicitly cross-reference each other to steer selection. The pair 'rules' vs 'taste' is the weakest split: both are standing user preferences injected at session start, differing only in approval flow. Task tools themselves are clearly distinct.
Most names are snake_case verb_noun (create_task_group, get_next_task, complete_task, clear_tasks, correct_fact), which is readable and mostly predictable. But several are bare nouns (rules, taste, worklog, graph_stats) and one is a question phrase (what_do_i_know), so the pattern breaks down noticeably.
19 tools is at the heavy end for a server named 'Task Runner' whose actual task surface is only four tools (create_task_group, get_next_task, complete_task, get_task_status). The remainder spans memory/knowledge graph, rules, taste, and worklog, so the count feels large relative to the advertised scope.
Memory has near-full lifecycle (remember, link, recall, what_do_i_know, correct_fact, forget, graph_stats) and the task loop (create, next, complete, status, clear) is workable. Gaps remain: no way to update/reopen/delete a single task, no note edit or delete, and rules support only show/propose with no withdraw path. Agents can work around these, so it stays above mid.