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 |
| tail_dispatchA | Read what a dispatch has printed so far, without waiting for it to finish.
Arguments:
dispatch_id — the id Returns state streaming | quiet | no_output_yet | exit_only last_output_age_sec seconds since the newest line output_lines lines emitted so far Read
Lines are raw agent output (often JSON events) — summarize them for
the user; do not paste them. Once |
| 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 20 tools
Most tools have clearly distinct purposes (dispatch vs check_dispatch vs tail_dispatch vs cancel_dispatch are well separated), and project_status vs project_pulse is explicitly contrasted. However, the read-side portfolio tools overlap: portfolio_digest, orchestration_history, dispatch_history, and list_dispatches all report on dispatch/activity state and could be misselected without careful reading of the long descriptions.
There is a mix of conventions: verb_noun tools (list_projects, update_project, cancel_dispatch, add_project) alongside noun-only tools (project_status, project_pulse, token_usage, portfolio_digest, orchestration_history) and bare 'dispatch'. The names remain readable, but the inconsistent verb/noun framing means the pattern isn't predictable.
20 tools is on the heavy side, but the domain is broad (registry CRUD, dispatch lifecycle, sessions, user preferences, and portfolio/token analytics), so most tools earn their place. A few analytics/read tools could plausibly be consolidated, keeping it just short of ideal.
Coverage is strong: full registry CRUD (list/get/add/update/remove/reorder), the full dispatch lifecycle (dispatch/check/tail/cancel/list/history), session listing, preference read/write, and multiple analytics views. Minor gaps exist around per-dispatch detail retrieval and note management, but core workflows have no dead ends.