Self-hosted ADHD progress hub — MCP + REST for unfinished threads, wiki progress, and optional OpenClaw nudges.
ADHD Hub demonstrates solid tool definition quality with consistent naming conventions, comprehensive parameter schemas, and thoughtful descriptions. All 15 tools follow verb_noun patterns (check_overlap, list_open_threads, upsert_project, etc.). Parameter schemas are well-formed with type definitions, descriptions, and appropriate constraints (enums for energy/status, minLength/maxLength for strings, min/max for integers). Tool descriptions are substantive (100-300+ chars) and explain WHEN to use each tool alongside what it does. Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) are properly applied. However, there are moderate gaps: output schemas are not documented in the tool definitions, error handling guidance is minimal, and some descriptions could better explain downstream dependencies. The server uses HTTP transport (FastAPI/Streamable HTTP), which is current-spec compliant.
Find open threads that may overlap a planned task. Use before starting potentially new work. The query should describe the intended task, and the result is read-only; compare likely matches before creating another thread.
Schedule a reminder for a thread or project.
Queue project deletion for human confirmation in /ui. Nothing is deleted immediately. The flags describe what the confirmed action should remove; use list_pending_actions to inspect the queued request before confirmation.
Retrieve a single thread by ID with full context.
Index a workspace directory for threads and progress.
List unfinished threads without changing them. Filter by project or energy when narrowing existing work. Use session_digest when you want a session-start summary with reminders and resume context instead of the raw thread list.
Output schemas are not documented in tool definitions. LLMs cannot infer what fields to expect from responses, forcing them to guess what data is available for downstream tool calls.
mark_done tool description is minimal (21 chars: 'Mark a thread as complete and archive it.'). Description lacks guidance on WHEN to call it vs other thread-state tools, and does not explain the archival consequence.
create_reminder and get_thread descriptions lack context about what data they return or how to use results downstream. Description does not explain the structure of reminder scheduling or thread context.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2026-07-28+ | v2 |
List project rename/delete requests waiting for /ui confirmation. This is read-only and is useful after rename_project or delete_project to show the operator exactly what remains pending.
List registered Hub projects with open/done thread counts. Use for project discovery or navigation. This is read-only; use resolve_project or upsert_project when a project needs to be resolved or changed.
Mark a thread as complete and archive it.
Queue a project rename for human confirmation in /ui. Use when the project identity should change. This request does not apply the rename immediately; list_pending_actions shows queued confirmations.
Resolve the current Hub project from a workspace path or slug. Use at session start before session_digest. With create_if_missing=true, this may create a local project registry entry; set it false when lookup must be read-only. Use upsert_project for explicit metadata or forge configuration changes.
Get a session-start summary: open threads by energy, reminders, resume context. Call at session start after resolve_project to warm up your session context with reminders, grouped threads, and suggested resume points. If the project has PROGRESS.md, the digest includes wiki-indexed recent updates.
Save a checkpoint to active thread state and project PROGRESS.md. Prefer a known thread_id so the checkpoint anchors to existing context. If the query is ambiguous and create_thread_if_missing is true, the tool may ask which thread to update via needs_thread_selection; pass thread_id or force_new_thread to resolve it.
Create or update a project registry entry and its explicit metadata. Use when setting title, workspace path, repository, energy, or forge targeting. This persists local Hub project configuration; it does not by itself create, rename, or delete a remote forge repository.
Create a new finishable work thread or explicitly update one. One thread should represent one independently finishable outcome, not a whole project. Pass thread_id when updating a known thread. For routine checkpoints on active work, prefer upsert_progress so progress notes and PROGRESS.md stay in sync.
No pagination guidance in tool descriptions. list_open_threads and list_projects accept limit parameters, but descriptions do not explain whether results are paginated or how to iterate through large result sets.
Error handling and recovery guidance is absent. Tool descriptions do not explain what errors might occur (e.g., 'thread not found'), how to detect them, or what the LLM should do next (e.g., 'try search_threads first').
Some WRITE operations lack confirmation/dry-run patterns. delete_project queues deletion, which is good, but upsert_project and upsert_thread could benefit from explicit confirmation guidance for destructive cases.
Parameter relationships are undocumented. upsert_thread and upsert_progress have overlapping params (thread_id, force_new_thread, create_thread_if_missing) with unclear interaction rules. LLMs may pass conflicting values.