Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TASK_RUNNER_DBNoPath to the database file (default is ~/.task-runner/memory.db).
TASK_RUNNER_HOMENoFolder for the database instead of a file (default is ~/.task-runner).
TASK_RUNNER_PROJECTNoThe project key. The server finds the project from its working directory; set this when your client starts servers in another directory.
TASK_RUNNER_REMOTE_KEYNoThe 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_EXCLUDENoHides 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 19 tools

Disambiguation3/5

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.

Naming Consistency3/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues