Self-hosted MCP hub 2.7.0 stable

Turn your APIs and services
into MCP tools.

One integration. Multiple accounts. Your local and cloud AI clients.

Give your AI useful tools for the services you already use. Start with a bundled integration or build an API adapter with the assistant, then configure each account and connect your MCP-capable client.

Runs on your server. Connects through the Model Context Protocol.

Connect through an MCP-capable client

Use compatible MCP connection features where available. ChatGPT custom MCP access and actions depend on plan, workspace permissions and supported connection options; Claude requires an available custom connector; LibreChat requires MCP server configuration. Each client must support the station’s transport and authentication, and be able to reach its endpoint. Local models require an MCP-capable client to call tools.

Client names describe connection options, not endorsements or certification. Live end-to-end compatibility has not been verified for every client and tool.

Useful tools, from the start

18 bundled modules.
Your next API, too.

Read and send email. Work with files and repositories. Manage infrastructure, tasks and alerts—using the tools and permissions each integration exposes.

Included in 2.7.0 stable. The release bundles 18 service modules, including eight additions: Gmail, Google Drive, GitHub, Docker Hub, Todoist, Pushover, Proton Pass and Cloudflare. Credentials and service permissions are required; bundled does not mean connected or live-tested. A fresh install seeds all 18; missing folders are added on startup, while existing module folders are never overwritten.

For another service, you need a usable API or a purpose-built adapter, authentication and permission to perform each action. This is not universal website automation. Review generated adapters before running them.

A clearer working surface

Know what you’re connecting.

Choose an account. Check its settings and tools. Connect when you’re ready.

Integrations workspaceSample data
MCP Station Integrations workspace showing service accounts, their configuration status, and workspace actions using sanitized sample data.
Real 2.7.0 application screenshot from the complete 18-module bundle, using blank example accounts. The viewport shows part of the scrollable library, not proof of connected services. Sample accounts do not represent live service connections.

From service to useful tool

One source.
Room for each account.

Keep the integration code together without mixing the configuration that makes each account yours.

  1. Bring a service in.

    Start with a bundled integration or build a module for your API. Inspect the source and the tools it exposes.

  2. Make the account explicit.

    Reuse one source with separate settings and endpoints. New accounts start blank, disabled, and untested—not with copied credentials.

  3. Test. Enable. Connect.

    Review the configuration, run the available test, then enable the endpoint. Authorize your compatible client for the account you selected.

Shared source, shared responsibility. Editing or reloading integration code affects all of its accounts. Separate settings are not process isolation.

A station to work from

Connect it.
Understand it.
Make it your own.

Less switching between configuration, source code, and conversation. More context for the next useful step.

Build with context

An assistant, with a place to work.

Use the dedicated Assistant or a source-scoped conversation to develop integrations. Bring API documentation, review generated code, and test before enabling.

How the Assistant works
See actual activity

Usage from real tool calls.

See calls, errors, and latency from completed authenticated tool calls. Bounded operational metadata—not invented activity, full audit logs, or provider cost tracking.

What usage measures
Keep it close

Your server. Your everyday workspace.

Self-host with Docker and persistent storage. Install the web app where your browser supports it over HTTPS. It’s a PWA, not a native desktop app or offline access to private content.

Plan your setup

Control starts with clarity

Self-hosted.
Not trust-free.

Keep the station on infrastructure you control. Be deliberate about the code you run and the context you share.

Read the account boundaries
One administrator, not many tenants.
Service accounts are configurations—not separate user logins. The station administrator can manage every account.
Installed modules are trusted code.
Modules run in the station process. Review source and permissions; account scoping is not a sandbox. Management access and master tokens carry broad authority.
Know where assistant context goes.
Conversations, relevant source, station context, and tool output can go to your selected AI provider or gateway; self-hosting the station does not keep a cloud model’s processing local. Provider billing and privacy terms apply. Keep secrets in settings, not chat.

Start with 2.7.0 stable

Make room for
your first connection.

Pull MCP Station 2.7.0 stable, then follow the full guide for credentials, persistent storage, and networking. A pull downloads the image; it does not start the station.

Open the full installation guide
Docker · 2.7.0 stable
docker pull dbzocchi/mcp-station:2.7.0

Persist /data and /app/mcps, plus /files when used. Before upgrading, back up and validate in an isolated instance with separate volumes.

Pin a release, or follow stable updates.

2.7.0 stable: pin 2.7.0 for this release. Moving 2.7 and latest follow stable updates. All 18 modules are bundled; configure credentials and permissions before connecting. Multi-account means service configurations under one administrator—not multi-user hosting.

Versions & images