central-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CENTRAL_MCP_HOME | No | User-state directory path. | ~/.central-mcp |
| CENTRAL_MCP_REGISTRY | No | Registry path override. |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List registered projects. Defaults to the current workspace. workspace:
|
| project_statusA | Return the registry entry for one project. This is metadata only — the working directory, adapter, description, and tags. Dispatch work via dispatch_query to actually hit the agent. |
| project_pulseA | What actually happened in a project, where it stands, what's live. Use this when the user returns to a project after time away, asks
"what's the state of X?", or before dispatching into a project you
haven't touched this session. Unlike Sections (each degrades independently, with a
Nothing is stored: every call recomputes from source. Synthesize the result into a short narrative ("since your last visit … currently … next …") rather than reciting the fields back to the user. |
| project_noteA | Record what was done / what was left / what comes next for a project. This is the durable memory a return briefing is built from. When to call it — this matters more than the arguments. Call it at the end of any stretch of real work in a registered project, whether or not that work came through central-mcp. A session someone opened directly in the repo is the most common case and the one most likely to be forgotten. Also call it when you learn something that changes the plan, and especially when you abandon an approach: "tried X, it fails because Y" leaves no commit, no diff, no trace at all, and is the single most valuable thing this file can hold. Do not call it for trivia (a typo fix, a question answered) — an over-full ledger gets skimmed, which is the same as empty. Arguments:
note — free text: what happened, what was left, what was learned.
name — registered project name. Omit if passing |
| dispatchA | Dispatch a prompt to a project or workspace. NON-BLOCKING. name: project name, or @workspace to fan-out to all projects in that workspace. When a workspace is targeted, each member project is dispatched independently and a list of dispatch_ids is returned. Spawns a one-shot subprocess (e.g. agent (optional): override the project's registered agent for this one dispatch only. Useful for e.g. sending a design-heavy task to a different agent without mutating the registry. Registry is unchanged. fallback (optional): list of agent names to try in order if the
primary agent exits non-zero (e.g. token/rate limit, crash). If omitted,
the project's saved permission_mode controls how the agent handles permission prompts:
session_id (optional): one-shot override for conversation resumption.
language (optional): one-shot override for the response language.
|
| check_dispatchA | Poll a background dispatch started by dispatch_background. Returns |
| list_dispatchesA | List active and recently completed background dispatches,
including those started by other central-mcp processes (shared
state via status (optional): filter to one of since (optional): ISO 8601 timestamp; only dispatches whose
Together these back the resident-agent failure watch without
central-mcp holding subscriber state: call
|
| cancel_dispatchA | Abort a running background dispatch. No-op if already finished. Sets a cancel flag so |
| add_projectA | Append a project to registry.yaml. Registration is immediate. The agent is not spawned until the next
language (optional): preferred response language for dispatches (e.g. "Korean", "ko", "Français", "fr"). When set, every future dispatch prepends "Respond to the user in ." to the prompt. Omit or leave empty for the agent's own default (English). workspace (optional): if given, also add the project to this workspace. |
| reorder_projectsA | Reorder the registry's
Raises an error for unknown names, duplicates, or (in strict mode)
missing ones. The reorder persists to |
| remove_projectC | Remove a project from registry.yaml. |
| update_projectA | Update an existing project's fields. Omitted args stay unchanged. Use this to permanently change a project's primary agent, edit its
description/tags, flip its permission_mode preference, set a
fallback chain of agents to try when the primary fails (e.g. token
limits hit), pin a specific
Agent names in |
| list_project_sessionsA | List resumable agent conversation sessions for one project. Queries the project's agent for sessions saved in its own store
scoped to the project's cwd (filesystem scan for claude/codex/droid,
subprocess call for gemini/opencode). Returns at most Each session dict carries
|
| get_user_preferencesA | Return the current content of ~/.central-mcp/user.md and the available preference sections. The file holds only user-authored rules — there is no scaffolded
template, so an empty |
| update_user_preferencesA | Persist a user preference to ~/.central-mcp/user.md. Call this when the user expresses a PERSISTENT preference — reporting style, language, routing hints, or process rules. Applied every future session. NOT for one-off turn instructions; those need no persistence. section — one of: "Reporting style" how to format and present responses "Routing hints" which agents/projects to prefer for task types "Process management rules" concurrency or approval constraints "Other preferences" anything else content — new full text for that section (replaces its existing content; other sections are untouched). Plain language, bullet points recommended: "- Switch to Korean for all responses." "- Prefer claude for architecture.\n- Use codex for shell scripting." Tip: call get_user_preferences() first so you can merge old and new content. |
| dispatch_historyA | Return the last N completed/failed/cancelled dispatches for one project. Reads |
| portfolio_digestA | Pre-rendered portfolio summary for push delivery — paste
Built for the resident-agent digest loop (a cron that forwards the
portfolio state to chat every morning), and equally usable by a
terminal orchestrator when the user asks for a daily/weekly recap.
The rendering is fixed server-side for the same reason
Data spine is the pulse, so — unlike
workspace: same semantics as Nothing is stored; every call recomputes from source. Scheduling
and alert watermarks belong to the caller ( |
| orchestration_historyA | Portfolio-wide snapshot: in-flight dispatches + recent milestones + per-project stats. Answers "how is everything going?" without per-project polling. Pulls:
workspace (optional): when given, filters recent milestones, per-project stats, and in-flight dispatches to only projects in that workspace. include_archives (optional): when True, attach |
| token_usageA | Portfolio-wide token-usage aggregation (SQL over Separated from period: Returns: { "ok": True, "period": "today", "window": {"start": ISO, "end": ISO} | {"start": null, "end": null}, "group_by": "project", "breakdown": { key: {dispatch, orchestrator, total, input, output} }, # When group_by="project", # tokens that aren't tied to # any registered project # (orchestrator-session usage) # are bucketed under the # special key "ORCHESTRATOR", # always emitted first in the # breakdown. "total": {dispatch, orchestrator, total, input, output}, "quota": { # only when include_quota=True "claude": {"mode": "pro", "five_hour": {"used_pct", "resets_in"}, "seven_day": {"used_pct", "resets_in"}}, "codex": {"mode": "chatgpt", "primary": {...}, "secondary": {...}}, "gemini": {"mode": "auth_only", "auth_type": ..., "note": ...}, "fetched_at": ISO, "cached": bool, }, "summary_markdown": "Token Usage — ...\n```text\n..." # only when include_summary=True # — pre-rendered HUD; surface # verbatim, do not re-format. } |
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 19 tools
The tools fall into clear clusters—project registry, dispatch lifecycle, history/portfolio reporting, preferences—and each tool has a distinct primary purpose. Some pairs could still be confused at first glance (dispatch_history vs list_dispatches, portfolio_digest vs orchestration_history), but the descriptions make the differences recoverable.
Most tools follow a snake_case verb_noun pattern like add_project, remove_project, list_projects, and cancel_dispatch. A few break the pattern with noun-first names like project_status, project_pulse, and portfolio_digest, but the overall convention is predictable and readable.
At 19 tools, the set is on the heavier side, but the breadth is justified for a central orchestration server covering project registry management, dispatch lifecycle, monitoring, history, preferences, and token usage. It feels slightly dense rather than bloated, and few tools are obvious candidates for removal.
The core domain is well covered: project CRUD plus reorder, dispatch start/check/list/cancel, per-project and portfolio history, project state/note, preferences, and token usage. Minor gaps exist—no dedicated workspace lifecycle tools, and check_dispatch references a dispatch_background tool that is not present in the set—but agents can work around these.