workhorse-ai-mcp
OfficialClick on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@workhorse-ai-mcpsearch the journal for past incidents related to payment timeouts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
workhorse-ai-mcp
Your AI is the workhorse. You are the orchestrator.
A delegation journal for orchestrator/worker AI workflows: an append-only
event log over SQLite (tasks, reports, artifacts, incidents, full-text
search) exposed as an MCP server. Zero dependencies — only Node.js >= 22.5
with the built-in node:sqlite.
The journal enforces a simple discipline: DRAFT → DELEGATED → REPORTED → ACCEPTED | REWORK | FAILED, where reported (the worker thinks it is done)
is never the same as accepted (the orchestrator verified it).
Quick start
Claude Code — two commands (installs the MCP server and the skill):
claude plugin marketplace add https://github.com/workhorse-ai/workhorse-ai-mcp
claude plugin install workhorse-ai@workhorse-aiAny other agent — install the skill, then add the MCP server to your agent's MCP config:
npx skills add workhorse-ai/workhorse-ai-mcp{ "mcpServers": { "workhorse": { "command": "npx", "args": ["-y", "workhorse-ai-mcp"] } } }Optionally, pin the rule at the project level — copy this into your
AGENTS.md / CLAUDE.md:
Delegation goes through the `workhorse` MCP journal. Worker duties:
`search_precedents` before starting, `record_artifact` (progress notes)
along the way, `submit_report` at the end. Never commit and never accept
your own work — acceptance requires the orchestrator's own test run.Related MCP server: shinobi
Install
Add the server to your .mcp.json:
{
"mcpServers": {
"workhorse": {
"command": "npx",
"args": ["-y", "workhorse-ai-mcp"]
}
}
}Or run it straight from a checkout:
{
"mcpServers": {
"workhorse": {
"command": "node",
"args": ["apps/mcp/server.mjs"]
}
}
}Data lives in ~/.workhorse-ai/journal.db (override with WORKHORSE_DB).
On first start the server creates the directory and the database itself.
sync.json always sits next to the database.
Connect to the cloud (optional)
connect needs only a token — the managed Workhorse AI cloud is the default:
connect { "token": "pln_..." }Self-hosted (on-premise)
Pass the base URL of your instance; endpoint paths are derived by the server, so a reverse-proxy prefix works as-is:
connect { "url": "https://workhorse.acme.internal", "token": "pln_..." }
connect { "url": "https://tools.acme.com/workhorse", "token": "pln_..." }The resolved base is stored in sync.json next to the database. To point every
run at your instance without passing a URL, set WORKHORSE_CLOUD_URL.
Configure from .mcp.json instead
If you would rather keep the credentials with the rest of your MCP config —
no connect call, no sync.json — pass them as environment variables. They
take precedence over the file:
{
"mcpServers": {
"workhorse": {
"command": "npx",
"args": ["-y", "workhorse-ai-mcp"],
"env": {
"WORKHORSE_SYNC_URL": "https://app.workhorse-ai.dev",
"WORKHORSE_SYNC_TOKEN": "pln_..."
}
}
}
}WORKHORSE_SYNC_URL takes the same base URL as connect. The journal id
defaults to <user>-<host>; override it with WORKHORSE_SYNC_JOURNAL_ID when
one machine feeds several journals.
Several workspaces at once
One machine, one journal — but projects may belong to different teams. List the
targets in sync.json and the journal is pushed to every one of them, each with
its own cursor and its own scope:
{
"targets": [
{ "alias": "acme", "url": "https://wh.acme.internal", "token": "pln_...", "journalId": "kv-mac" },
{ "alias": "lab", "url": "https://app.workhorse-ai.dev", "token": "pln_...", "journalId": "kv-mac" }
]
}connect { "alias": "lab", "token": "pln_..." } adds a target instead of
replacing the config. On a flat config without an alias it overwrites, exactly
as before; once a targets list exists it replaces only its own entry — matched
by alias, or by url plus journal id — and leaves the neighbours alone. The
flat single-target form ({url, token, journalId}) keeps working untouched, and
so do the WORKHORSE_SYNC_* variables — they describe one target, so when a
targets list is present they are ignored with a line on stderr rather than
silently adding a third destination.
A target that is down does not hold up the others: the push reports per target, and a failing one is a line on stderr, never a crash.
Which projects are pushed (sync scope)
The journal is one per machine and holds every project you work on, while a cloud workspace belongs to a team. Bind the projects that may go there:
sync_scope {} # what would be pushed, and why
sync_scope { "projects": ["acme-web"] } # bind these to the connected workspacesync_scope asks the cloud for the workspace id itself and records it as
cloud_workspace_id in the project registry — no manual ids, no SQLite editing.
With several targets, sync_scope {} reports each of them and binding names the
target by its alias: sync_scope { "target": "acme", "projects": ["acme-web"] }.
WORKHORSE_SYNC_PROJECTS="acme-web,acme-api" overrides the registry for one
process. With no mapping anywhere the push stays as before — everything goes —
and warns about it on every run.
While a scope is active, events that belong to no project (journal-level
incidents, _general) and ProjectRegistered stay local. Widening the scope
re-pushes from seq 0 so previously filtered events catch up; the cloud drops
duplicates by seq. The last scope is remembered per target in sync-state.json
next to the database (keyed by workspace id), so widening the scope of one target
does not re-push everything to the others.
If your instance uses a certificate from an internal CA, give Node the root
certificate — otherwise the TLS handshake fails and connect refuses to write
the config:
NODE_EXTRA_CA_CERTS=/etc/ssl/certs/acme-root.pemSync is one-way: the journal is pushed up, the cloud never rewrites it. The
cursor request is sent with Cache-Control: no-store, so a caching proxy in
front of an on-premise instance cannot serve a stale cursor.
Skills
The package ships three skills — pick the one that matches your setup:
Skill | Install it on | What it teaches |
| the agent that assigns and accepts work | the full discipline: bootstrap, drafting assignments, line-by-line review, acceptance by your own test run |
| the agent that executes delegated tasks | the three journal duties, the report format, and the prohibitions (never accept your own work) |
| a single agent playing both roles | the solo discipline: the report and the acceptance stay separate acts with separate evidence |
Install via the Claude Code plugin (all three come along), or pick one:
npx skills add workhorse-ai/workhorse-ai-mcp --skill workhorse-ai-orchestratorLicense
MIT
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Shared task queue for humans and AI agents: leases, handoffs, approvals and signed receipts.
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
ADHD system of record for agents: tasks, goals, loops, calendar, focus stats.
Handwritten iPad journal your AI can read and write tasks back to, over MCP.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to track, search, and retrieve their progress across projects with persistent memory using SQLite storage and LLM-powered summarization. Supports logging completed work, searching previous entries, and retrieving context for multi-step or multi-agent workflows.17MIT
- AlicenseNot gradedqualityAmaintenanceTask spine + searched dead-ends + mobile approvals for AI coding agents — one shared brain across every session, machine, and device. Local SQLite or remote streamable-HTTP MCP, MIT.732MIT
- AlicenseNot gradedqualityCmaintenancePersistent activity journal for AI agents - enables logging and querying decisions, changes, errors, and observations across sessions.131MIT
- AlicenseNot gradedqualityBmaintenanceAn append-only coordination memory for multi-agent and human work, backed by SQLite, with a local dashboard and acceptance contracts that enforce integrator review before work is considered accepted.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/workhorse-ai/workhorse-ai-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server