mcp-session-threads
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_threadA | Open a thread on this project's board (one per finding/question/note). |
| add_messageA | Append an agent message to a thread (Markdown). Start with a one-line summary of what the user asked. Optionally refresh |
| resolve_threadA | Mark a thread resolved (only small/clear-cut items — leave heavy/uncertain changes open for the user). |
| reopen_threadA | Reopen a resolved thread to continue it. |
| defer_threadA | Park a thread as "deferred": it drops into a Deferred lane below Waiting-on-agent and is excluded from the review counts and the "needs your attention" set, so the user can ignore it for now. Use for real work that is not a good time to tackle yet (blocked, out of scope for this pass, better done after X). Optionally pass a short |
| resume_threadA | Un-defer a parked thread AND post a message recommending the user pick it up now — |
| list_threadsC | List threads on this board (id, title, tags, status, work-state, message count). |
| set_summaryA | Pin an overall TL;DR (Markdown) at the top of the board. Empty string clears it. |
| get_board_urlA | Return this project's stable board URL. Share it with the user. |
| wait_for_feedbackA | Block until the user submits their batched replies/notes on the board, then return them. ONE long call (default ~55 min) — do not poll in a loop; it returns instantly on submit and sends progress so it will not time out. Automatically flips the board to "your turn" (title + sound) while blocking and back to idle on return. Survives a daemon restart mid-wait (reconnects and keeps waiting); only if reconnection keeps failing does it return with a hint to call it once more. Create the threads BEFORE calling this. |
| get_notesA | Return ALL free-form "other notes" the user submitted on this board (durable; each submission a separate entry). |
| start_workingC | Tell the UI you started acting on the feedback (shows a working indicator). |
| finish_workingC | Tell the UI the whole batch is done (title highlights, optional sound). |
| work_on_threadB | Tell the UI you are now working on a specific thread (highlighted as in-progress). |
| mark_thread_done | Mark that you finished working on a specific thread (counts toward the progress bar). |
| list_boards | List all boards on the daemon (id, label, key, thread counts, URL). |
| use_board | Switch THIS session to an existing board by id (e.g. to recover stranded threads). Reverts to the stable per-project board on the next restart unless switched again. |
| import_threads | Copy threads (with full message history) from another board into THIS board. mode "append" (default) or "replace". |
| export_board | Export the full JSON of THIS board (all threads + messages + summary). |
| backup_boardA | Write a timestamped backup file of THIS board to the daemon's backups/ folder. Returns the path. |
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 15 tools
Most tools map cleanly to distinct lifecycle actions (create, resolve, defer, resume, list, backup). However, add_message reopens resolved threads, which overlaps with reopen_thread, and resume_thread acts like a reopen for deferred threads, so an agent could occasionally misselect.
Core thread operations follow a clear verb_noun pattern: create_thread, resolve_thread, defer_thread, reopen_thread. A few outliers like wait_for_feedback, work_on_thread, and start_working/finish_working break the pattern but remain readable and predictable.
Fifteen tools is at the high end of the typical well-scoped range, and most earn their place in the thread lifecycle. The set feels slightly over-scoped because working-state indicators and backup_board are auxiliary UI/durability extras rather than core thread operations.
The lifecycle is well covered: create, message, resolve, reopen, defer, resume, list, and feedback collection. The notable gap is the lack of a tool to retrieve a thread's full message history or body—only list_threads summaries and get_notes are available—so an agent cannot reconstruct previous thread content from the server alone.