Self-hosted MCP tool aggregator. One endpoint, per-user OAuth, 194 tools across 16 integrations — behind 9 meta-tools.
Website · Documentation · Quickstart · Integrations · Build a plugin · Deploy
Give an agent one MCP endpoint instead of sixteen. workbench holds a separate OAuth connection per user per provider, encrypts every token at rest, and exposes every integration through a fixed set of nine meta-tools — so the agent's tool list stays the same size whether one integration is connected or all of them.
flowchart LR
Agent["Agent"] -->|JSON-RPC| MCP["POST /mcp"]
Script["Script / cron"] -->|plain JSON| REST["POST /rest/:integration"]
MCP --> Meta["9 meta-tools"]
Meta --> Reg["Plugin registry<br/>16 integrations · 194 tools"]
REST --> Reg
Reg -->|credential injected| APIs["Jira · GitHub · Slack · Google · …"]
Portal["Portal"] --> Store[("Encrypted tokens")]
Meta -.-> Store
Anything that is not an agent can skip MCP entirely:
POST /rest/:integration runs the
same tools over plain JSON, on the same credentials, with no JSON-RPC framing and no
60,000-character result cap.
Quickstart
git clone https://github.com/barockok/workbench.git && cd workbench
npm install
cp .env.example .env
# Both are required — the server refuses to boot without them.
echo "ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env
echo "SESSION_SECRET=$(openssl rand -base64 32)" >> .env
npm run dev
Then open the portal, connect an integration, mint an API key, and point your MCP
client at http://localhost:3000/mcp. The full walkthrough is in the
Quickstart.
Documentation
The docs are the product surface — start there, not here.
| Section | What's in it |
|---|---|
| Get started | What it is, how it works, connecting an agent |
| Guides | Discovering and executing tools, OAuth, browser sessions, raw API calls, troubleshooting |
| Integrations | Every provider: exact scopes, setup steps, full tool list |
| Build plugins | Manifest reference, plugin context API, the four auth modes |
| Deploy | Docker, PostgreSQL, portal SSO, security, observability, releases |
| Reference | All 9 meta-tools, every HTTP route, every environment variable, the tool catalog |
| Field notes | Production failures, root causes, and what changed |
What's in the box
| Integrations | 16 on disk, plus 2 internal (browser, jots) |
| Tools | 194 plugin tools, reached through 9 meta-tools |
| Auth modes | oauth2, apikey, cookie, none |
| Agent auth | Workbench API key or OAuth 2.1 (dynamic registration + PKCE) |
| Portal SSO | Google, Keycloak, or both |
| Database | SQLite or PostgreSQL, with a migration path between them |
| Stack | TypeScript, Fastify, MCP TypeScript SDK, React portal |
Development
npm run dev # start dev servers
npm run test # run tests
npm run build # build all packages
npm run lint # lint all packages
The docs site is generated from Markdown by a script with no framework:
node docs/site/build.mjs # _content/*.md + nav.json → static HTML in docs/site/_site/
Commit the Markdown only. docs/site/_site/ is build output, is not tracked,
and is regenerated by the Docs workflow on every push to main. CI runs the same
build on every pull request, and a broken internal link fails it.
See Contributing for the branch, commit, and release conventions, and SECURITY.md for reporting a vulnerability.