blackboard
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BLACKBOARD_ROOT | Yes | The absolute path to the Blackboard root directory. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_server_infoA | Report this MCP server process's version, git SHA, start time, and Blackboard root. A long-lived stdio connection keeps the tool schema it had at startup, so a tool added to the source after connecting (e.g. a newly released one) will not appear until a fresh connection is made. If an expected tool seems to be missing, call this first: an old started_at/git_sha relative to the source you expect means the connection is stale, not that the feature is missing. |
| read_memoryA | Read a persistent Memory document by id. |
| list_memoryA | List Memory metadata in deterministic ID order without full content. |
| write_memoryA | Create or update Memory. Updates require the revision returned by read_memory. |
| list_plansA | List named Plans in this Blackboard root, each with its in_progress tasks. Check this before claiming work when multiple actors may be active: it shows what is already claimed, by whom, across every Plan in this root. |
| list_actor_rolesA | Report which roles each actor_id has claimed tasks under, across every Plan. This is an observation aid, not authentication: actors still self-declare their role on every call, and nothing here is enforced. Use it to sanity check who has been active and under which roles before trusting a Memory/Event entry attributed to an unfamiliar actor_id. |
| read_planA | Read one Plan and its executable tasks, optionally for one Role. |
| validate_planA | Diagnose Plan metadata, task audit fields, dependencies, and Outbox without changing it. |
| add_taskA | Append one new task to an already-initialized Plan. A stale revision is rejected as a conflict.
|
| edit_taskB | Edit a pending task's text, required Role, or dependencies with revision CAS. Task IDs are immutable. Pass |
| cancel_taskA | Logically cancel a pending or owned in-progress task with an audit Event. |
| set_task_priorityA | Set a pending task's advisory P0-P3 priority with CAS and an audit Event. Priority is human-facing backlog guidance. It does not choose, claim, or block work for any LLM. |
| recover_taskA | Recover a blocked task to pending; the declared Role needs recover_task permission. |
| claim_taskA | Atomically claim one executable task. A stale revision is rejected as a conflict.
|
| update_taskA | Finish, block, cancel, or recover a task. Claim owners may set done/blocked/cancelled on in_progress tasks. Roles with recover_task permission may set pending on blocked tasks. The Plan state is authoritative. Its corresponding audit Event is placed in the Plan Outbox and is retried idempotently if Event persistence fails. |
| read_stateA | Read a State document by id. The response includes a |
| list_stateA | List State metadata in deterministic ID order without full content. |
| write_stateB | Create or update current State. Updates require the revision returned by read_state. |
| read_eventA | List audit Events, optionally filtered by type, task, or created time range. |
| emit_eventA | Append an independent audit Event. This tool does not change Plan state. |
| initialize_projectA | Create the Blackboard directories and one named Plan file. This bootstrap utility is used by a human when creating a project. LLM collaboration thereafter uses the core Blackboard tools above. Additional Plans may be created in the same root by calling this again with a new plan_id. |
| flush_event_outboxC | Retry pending Plan-generated Events after a previous Event write failure. |
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 22 tools
Several lifecycle verbs overlap: update_task can recover tasks, while recover_task exists separately; cancel_task also nests inside update_task. Plan validation vs. plan reading are distinct, but task mutation operations create some ambiguity.
Tool names follow a consistent lowercase snake_case verb_noun pattern. Minor deviations like get_server_info, initialize_project, and flush_outbox are still recognizable.
22 tools is on the high end for a planning/coordination server. Most earn their place, but any smaller set could be more economical.
The surface is essentially complete for this domain: plans, tasks, act, dependencies, claim, restore, validate, memory, state, and audit events are all covered. But there are still no global query for all tasks or a delete for memories/states, but not required.