# workbench [Health: Active]

**Category:** 🔗 Aggregators  
**Repository:** https://github.com/amarthaid/workbench  
**GitHub Stars:** 7  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/workbench-2

## Description
One MCP endpoint. Every tool your agent needs. Self-hosted, per-user OAuth. 20+ SaaS integrations and invite you to add more.

## Claude Desktop Quick Installation
No generated config for this server: it installs through its own setup steps.

The project's own setup steps (from https://github.com/amarthaid/workbench), copied verbatim. Run them in order; they are not an mcpServers config.

1. Install:

```sh
git clone https://github.com/barockok/workbench.git && cd workbench
```

2. Install:

```sh
npm install
```

3. Configure:

```sh
cp .env.example .env
```

4. Start the server:

```sh
npm run dev
```

5. Start the server:

```sh
npm run dev      # start dev servers
```

## Documentation

## What workbench does

workbench is a self-hosted MCP tool aggregator. It brings 194 tools from 16 integrations into one endpoint, while exposing those tools through nine meta-tools rather than registering every provider tool directly with the agent. The fixed meta-tool set keeps the agent’s visible tool list consistent as integrations are connected or removed.

Supported provider examples include Jira, GitHub, Slack, and Google. The project also includes two internal integrations, `browser` and `jots`. Integrations can use OAuth 2, API keys, cookies, or no authentication, depending on the provider.

Per-user, per-provider OAuth connections are kept separately. Access tokens are encrypted at rest. Agents authenticate with a Workbench API key or OAuth 2.1, with dynamic registration and PKCE available for the latter.

## How it works

An MCP client sends JSON-RPC requests to `POST /mcp`. The meta-tools route discovery and execution through a plugin registry, which supplies the appropriate provider credentials before calling the external API.

Non-agent callers can use `POST /rest/:integration` instead. This route accepts plain JSON, uses the same stored credentials, and avoids JSON-RPC framing. REST responses are not subject to the 60,000-character result cap applied to MCP results.

The portal is used to connect integrations and mint API keys. Portal single sign-on can use Google, Keycloak, or both. SQLite and PostgreSQL are supported as database backends, with a migration path between them.

## Setup and configuration

A basic local setup requires cloning the repository, installing dependencies with `npm install`, creating `.env` from `.env.example`, and defining both required secrets:

- `ENCRYPTION_KEY`, generated as a 32-byte hexadecimal value
- `SESSION_SECRET`, generated as a random Base64 value

Start the development server with `npm run dev`. After opening the portal, connect an integration and create an API key, then configure the MCP client to use `http://localhost:3000/mcp`.

The project also documents Docker deployment, PostgreSQL configuration, portal SSO, security, observability, and release procedures. Development commands include `npm run test`, `npm run build`, and `npm run lint`.

## Tools and capabilities

- Discover and execute provider tools through nine meta-tools.
- Maintain separate credentials for each user and provider.
- Support OAuth 2, API-key, cookie, and unauthenticated integrations.
- Expose the same integration actions through MCP and REST.
- Add integrations through the plugin system, which includes a manifest reference and plugin context API.
- Keep agent tool-list size stable across different integration combinations.

## Limitations and notes

The MCP interface is intentionally indirect: agents work through nine meta-tools rather than receiving 194 individual tools. MCP results have a 60,000-character cap, although the REST route does not. The service is self-hosted, so deployment, secret management, provider setup, and portal configuration remain part of the operator’s responsibilities.

_Full upstream README: https://allmcps.com/mcp/workbench-2/readme_