Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CASEFILE_AUTO_UPDATENoSet to false to turn off auto-update. Default is true.

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
extensions
{
  "io.modelcontextprotocol/skills": {}
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_taskA

Returns everything about one task in a single call: card, parent and children, links from both sides, computed features, latest summary, open questions, unresolved remarks, case index and transition targets.

parent and children are fields of their own and are absent from links, which holds blocks, blocked_by and relates, each named by this task's role. The parent's summary and decisions are in the parent's own case.

The summary covers the case up to its own no; entries with a greater no are returned by read_entries with after_no. The index carries titles only, and entry bodies come from read_entries.

A remark in remarks changes nothing in the task: it does not block in_progress, does not change the status and does not unlock the sections. It stays in remarks and in open_remarks until resolve gives it an outcome.

transitions lists the targets of the transition table from the current status, not moves checked in advance: sections, summary, verdicts, blockers and children are checked by the transition call itself. Whether in_progress is open shows in the blocked feature.

search_tasksA

Searches tasks by a query language string, by separate conditions, or by both.

Conditions from both sources combine with and and give the same result as one string of the same meaning; no condition at all selects every task of the projects that are not archived. A task of an archived project is found only when the search names it with = or in: its project in project, the task itself in key, or its parent in parent. Rows are ordered by sort, by key when it is left out. A long text is cut at the installation limit and marked by <field>_truncated and <field>_length; one task in full, with its case and links, is returned by get_task.

An unknown field, operator or value is refused with search_field_unknown, search_operator_not_supported or search_value_invalid, the allowed values listed in details.

create_taskA

Creates a task in backlog; a new task starts in no other status.

With parent, the task is born as the parent's child in the same call: the link files link_added both in the new task's case and in the parent's case, and parent_entry in the response is the number of the parent's entry.

A child task takes a part of the parent's work when the parent's output falls into separate results, its checks cannot all pass in one pass, the work does not fit one pass, or it depends on something that does not exist yet. These signs appear on entry into the parent and after each attempt.

The response carries the key issued by the tracker. An empty title or description is refused with task_fields_invalid.

update_taskA

Changes the given fields of a task; fields left out stay as they are.

Title, description and sections are fixed from open on. A task past backlog has them edited by a return to backlog through transition with a reason, this call, and a move forward again to open and in_progress.

Each changed field files section_changed or field_changed, an assignee change files assignee_changed. An edit of one check names its number, and the earlier verdicts on that check become outdated.

transitionA

Moves a task to another status along the fixed transition table.

Refusals: leaving in_progress without a summary filed since the last entry into it — summary_required; entering in_progress without an assignee — assignee_required, by anyone but the assignee — assignee_mismatch (assignee and caller signature in details), with an open blocker — task_blocked; open with incomplete sections — task_sections_incomplete; cancelled with open children — task_has_unclosed_children; done — closing_not_a_transition, since a task is closed by close_task; a move outside the table — transition_not_allowed, the allowed targets in details.allowed.

The tracker never moves a task into or out of waiting by itself: both moves are the caller's. Each entry into in_progress, from any status including waiting, starts a new pass of the task.

cancelled takes no verdicts. It clears the blocked feature of the tasks this one blocked (blocks), with no entry in their cases.

The response names the new status and version and the number of the filed status_changed entry.

close_taskA

Closes a task: files the given entries, then the verdicts, then the final summary, and moves the task to done, all in one transaction. It is the only way into done.

A refusal of any part files nothing and leaves the status as it was. The exit conditions are checked after filing: a passing latest verdict on every review check within the current pass (checks_not_passed), closed children (task_has_unclosed_children), the task in in_progress (transition_not_allowed). An empty summary part is refused with entry_fields_invalid.

For a parent task the final summary covers the whole work: the children's results are in their own closing summaries.

Tasks this one blocked (blocks) lose the blocked feature, without an entry in their cases.

move_taskA

Moves a task to another project, recording the move, both keys and the reason as a moved entry of the task. Available to a main token alone.

The task gets the next number of the new project, or its own earlier key there when it returns to a project it has been in: a task holds at most one key per project. The key it leaves goes to previous_keys and keeps addressing the task in every call that takes a key; no other task ever gets it. Status, sections, links, parent, children and case stay as they are, and a closed task moves too. One key moves one task: its children stay in their project.

Moving into or out of a frozen project fails with project_archived.

A list of keys moves each task on its own, in list order, so new numbers follow that order; each moved task gets its own moved entry with the one reason. The answer is results, one per listed key, repeats included: moved, already (the task is in that project already) or error with the code a single move would give, such as task_not_found or project_archived of the task's own project. A refusal of one task leaves the others moved. A missing main scope, a blank reason, an unknown or archived target project and a list size out of range refuse the whole call before any move.

read_entriesA

Returns entry bodies of one task's case, with payload, in number order.

Filters combine with and: types=["summary"] gives every summary, after_no everything filed after the named entry, and both together the entries of those types filed after it. decision and attempt entries hold the choices already made and the attempts already tried, failed ones included.

Entries of many cases in one stream, with a wait for new ones, come from wait_journal.

add_summaryA

Files a summary: the handover note of a case, in four parts, none of them empty (entry_fields_invalid lists the empty ones).

A significant step is a decision made, a finished part of the work, a failure that changes the plan, or any point where a colleague would need an explanation of where the work stands.

Its index title is the first line of done, returned in the response. The final summary, with unmeasured, is filed by close_task.

add_entryA

Files an entry without payload: a decision, attempt, finding, artifact, remark or note.

Entries are immutable: no call edits or deletes one, and a mistaken entry is corrected by a new entry that references it in refs. Summaries, questions, answers, verdicts and resolutions have their own tools: add_summary, ask, answer, add_verdict, resolve.

An empty title is refused with entry_fields_invalid, which lists the fields.

askA

Files a question to registry participants. The tracker delivers nothing: an addressee sees the question when reading the feed or their inbox.

A question stays open until an answer with its number is filed in the same task; it counts toward open_questions, and with blocking toward open_blocking_questions.

What the cases of the parent, its ancestors and sibling tasks already record is readable through get_task and read_entries, without a question.

answerA

Answers a question of the same task. Any holder of a task token answers, in any task.

The first answer closes the question and later ones add to it; neither a question nor an answer changes the task status. The tracker builds the title from the question reference.

resolveA

Resolves a remark on a task: its outcome and where the work went.

Any outcome resolves the remark, needs_detail included: the resolution removes it from open_remarks, while accepted keeps it in remarks_in_work until the continuation task is closed. Its title is made of the remark reference and the outcome.

add_verdictA

Files the outcome of one review check, as run by the task's assignee within the current pass.

A pass starts with each entry into in_progress, a return from waiting included. Only verdicts of the current pass count for closing, and the latest verdict on a check replaces the earlier ones: a failed verdict is filed when it happens, like a passed one. Verdicts of earlier passes stay in the case without counting. close_task also takes verdicts, together with the closing.

read_project_entriesA

Returns the bodies of a project's case entries, payload included, ordered by entry number.

The project's case holds decisions, findings, artifacts and notes about the project, and the tracker's own entries about its card. Filters combine with and, as in read_entries. attribute gives one attribute's history: attribute_created, attribute_changed, attribute_removed entries with that name. The case index, titles only, comes with get_project.

add_project_entryA

Files an entry in a project's case: a decision, finding, artifact or note that concerns the project rather than one of its tasks.

The entry number counts inside the project, and TRK#7 addresses the entry from refs of any task or project case. Like a task entry filed by add_entry, a project entry stays as filed. A task token files project entries as it files task entries.

An empty title, or a reference to a missing entry, task or project, returns entry_fields_invalid naming the offending fields.

linkA

Links two tasks and files link_added in both cases.

kind is the role of key: blocks means key blocks other, and the card of other shows the link as blocked_by. A link is stored once: the same link from the other side is refused with link_exists, like a repeat. A link closing a cycle is refused with link_cycle_detected, a link of a task to itself with link_self_not_allowed.

parent and child set the hierarchy, shown by get_task in the fields parent and children rather than in links. A task has one parent: a second one is refused with task_has_parent, the current parent named in details.parent.

An open blocker raises the blocked feature of the blocked task and keeps it out of in_progress with task_blocked.

A closed task (done, cancelled) accepts only relates, the link to a continuation grown from it; parent and blocks on it are refused with task_closed. Only a link shows the lineage on the cards of both tasks: a key mentioned in an entry body or in refs does not.

unlinkA

Removes a link and files link_removed in both cases.

A link is removed from either side and under either name of its kind: blocks from TRK-1 to TRK-7 and blocked_by from TRK-7 to TRK-1 are the same link. On a closed task parent and blocks stay (task_closed), relates is removed. A link that does not exist is refused with link_not_found.

get_projectA

Returns one project by its key: key, title, description, current attribute values and the index of the project's case.

The keys of the installation's projects are listed by list_projects.

list_projectsA

Lists the installation's projects, one page at a time: key, title and archive time. A project's description is returned by get_project.

list_participantsA

Lists the participant registry: humans and permanent agents, the possible addressees of a question. Temporary agents are not registered and are absent from it.

create_projectB

Creates a project with a key, a title and a description. Only a main token creates projects.

update_projectA

Changes a project's title and description; a field left out stays. Only a main token edits projects. The key never changes. Each changed field files a field_changed entry with the previous and the new value in the project's case; a value equal to the current one files nothing.

archive_projectA

Archives a project with a reason and files an archived entry in its case. Only a main token archives.

The project and its tasks freeze as they are: statuses stay, open tasks need no closing. From then on any change in the project or its tasks — a new task, an entry, a transition, an edit, an attribute, a new link — is refused with project_archived, until restore_project. The one change still accepted is unlink of a link with its task: an open archived task keeps blocking its blocked_by tasks and holding its parent until the link is removed. Reads work as before.

An already archived project is refused with project_archived.

restore_projectA

Brings an archived project back: files a restored entry carrying the reason in its case, and its tasks resume where the archive left them. Only a main token restores.

A project that is not archived is refused with project_not_archived.

set_attributeA

Sets the value of a project attribute: a reference fact of the project such as its repository or main branch. One call both creates and changes; which entry it files follows from the attribute's state.

  • No attribute with this name, ignoring case: the attribute is created and an attribute_created entry is filed; the reason is optional.

  • An attribute with another value: the value changes and an attribute_changed entry is filed with the previous value; the reason is required.

  • The same value: nothing changes and nothing is filed.

The name keeps the spelling it was created with; another spelling addresses the same attribute and does not rename it. Attributes carry no types and no search: the tracker stores the text and acts on none of it. A task token sets attributes.

remove_attributeA

Removes a project attribute and files an attribute_removed entry in the project's case with its last value and the reason. The attribute's history stays in the case; a later set_attribute with the same name creates it anew.

A name that matches no attribute of the project is refused with attribute_not_found. A task token removes attributes.

register_participantA

Registers a human or a permanent agent. Only a main token registers participants; the new participant's token is issued through the REST API. An existing participant's description is changed by update_participant.

update_participantA

Changes a participant's description. Only a main token edits participants. Name and kind never change: the name signs entries already filed. The previous description is not kept.

wait_journalA

Returns journal entries after the sequence number after, waiting for new ones.

The journal is every case entry of the installation in one stream, task cases and project cases alike, in seq order; task, project and types narrow it. The call returns as soon as a matching entry appears, and after timeout seconds at the latest. The next call continues from the seq of the last entry received. With types=["answer"] and task, one call covers an answer expected within timeout.

Entries already filed in one case, by number, are returned by read_entries and read_project_entries.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
casefileConnecting an agent harness (Claude Code, Codex, Hermes or another MCP client) to a Casefile task tracker installation over MCP, either one installed on the same machine or a shared one running on a server, recovering when the casefile MCP server refuses a call with 401, watching the tracker journal for news between agent sessions, and installing or updating this skill as a plugin. Applies when Casefile is being installed or connected, when an agent joins an installation that runs on a server, when the casefile server is missing from the harness or answers 401 unauthorized, when answers and remarks in the tracker have to reach an agent with no open session, and when this skill was read from the server and is not yet installed in the harness. The working rules of the tracker itself arrive with the MCP server, in its instructions and tool descriptions, and are not part of this skill.

TDQS

A4/5.0

Scored across 30 tools

Disambiguation4/5

Most tools target clearly distinct resource+action pairs, and descriptions explicitly delineate entry types (summary, verdict, question, answer, resolution, generic entry). A couple of near-overlaps exist: transition (status change) vs move_task (project move), and add_entry vs add_project_entry share the same action on different scopes, which could cause occasional misselection.

Naming Consistency4/5

The dominant pattern is consistent snake_case verb_noun (read_project_entries, create_task, update_task, close_task, add_verdict, etc.). A handful of tools break it with bare verbs (link, unlink, ask, answer, resolve, transition), and the get_/read_ prefix usage is not perfectly uniform, but everything remains readable and lowercase.

Tool Count3/5

30 tools is above the comfortable range and feels heavy, but the domain is genuinely broad (projects, tasks, entries, links, participants, attributes, journal). Each tool maps to a distinct operation, yet the surface could likely be consolidated (e.g. entry-creation variants).

Completeness5/5

Full lifecycle coverage: project create/update/archive/restore/list/get, task create/update/move/transition/close/get/search, entry add/read, links link/unlink, participant register/update/list, attributes set/remove, and a journal stream. Entries are intentionally immutable and projects archived rather than deleted, so no obvious dead ends.

Maintenance

ActivityActive
ResponsivenessNo issues