Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BLACKBOARD_ROOTYesThe 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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.

task uses the same shape as one entry of initialize_project's tasks (id/task/role). dependencies lists the IDs of tasks the new task requires; targets must already exist in the Plan.

edit_taskB

Edit a pending task's text, required Role, or dependencies with revision CAS.

Task IDs are immutable. Pass dependencies=[] to remove all dependencies.

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.

work_scope optionally declares the files/paths you expect to touch (e.g. ["src/blackboard/service.py", "tests/test_service.py"]). It is recorded on the task_started Event for other actors to see before they start their own work, but it is not enforced.

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 stale_warning field if the document hasn't been updated in a while. This is a read-time nudge only — State is never auto-rewritten from Plan (see CONTRIBUTING.md).

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.3/5.0

Scored across 22 tools

Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count3/5

22 tools is on the high end for a planning/coordination server. Most earn their place, but any smaller set could be more economical.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues