MCPWorks is Now Open Source — Plus Third-Party MCP Server Plugins
Today we made the MCPWorks API repository public. The codebase is source-available under BSL 1.1, converting irrevocably to Apache 2.0 in 2030. Self-host with docker compose up, or use MCPWorks Cloud for managed hosting.
This post covers what MCPWorks does, how the token savings architecture works, and the feature I am most excited about: third-party MCP server plugins.
GitHub: MCPWorks-Technologies-Inc/mcpworks-api
What MCPWorks is
MCPWorks is a platform for hosting AI agent functions with 70-98% token savings through sandboxed code execution.
The core idea: instead of your AI assistant calling tools that dump raw data into the context window, the AI writes code that runs inside a secure sandbox. The data is processed in the sandbox. Only the result comes back.
Traditional approach:
AI: "Get all 500 leads from the database"
Tool returns 500 records → 47,000 tokens consumed
AI summarizes → 200 token response
MCPWorks approach:
AI writes: result = store_lead(action='stats')
Code runs in sandbox → data stays inside
Only the stats return → 300 tokens total
Same answer. 99% fewer tokens.
How it works — the architecture
The token savings are not marketing. They are an architectural property of how code execution works.
Code mode
When your AI connects to a MCPWorks namespace, it gets a single execute tool. The AI writes Python (or TypeScript) that runs inside an nsjail sandbox — a Linux namespace jail with process isolation, filesystem isolation, network isolation (veth pair for paid tiers), and syscall filtering via seccomp-bpf.
The AI sends ~50 tokens of code. The sandbox processes the data. Only the result variable returns. Everything else — intermediate variables, loop state, data structures — is destroyed when the sandbox exits.
The functions package
Every function you create in your namespace is injected into the sandbox as importable Python:
from functions import check_email, format_report
emails = check_email(account="[email protected]")
urgent = [e for e in emails if e['priority'] == 'high']
result = format_report(data=urgent)
Three function calls, data filtering, and report generation — all inside the sandbox. The AI context only sees the final report.
Security
The sandbox runs inside nsjail with:
- PID namespace (process isolation)
- Mount namespace (read-only rootfs)
- Network namespace (veth pair for paid tiers, zero connectivity for free tier)
- cgroups v2 (memory and CPU limits)
- seccomp-bpf (syscall filtering)
- Output size caps (1MB result, 64KB stdout)
User code cannot access the host, other sandboxes, or the MCPWorks API process.
What shipped today
Core platform (v0.1.0)
- Code execution sandbox — Python and TypeScript in nsjail
- Namespace-based function hosting — organize functions into services, each with its own MCP endpoint
- Autonomous agent runtime — scheduling, persistent state, webhooks, Discord integration
- BYOAI — bring Claude, GPT, Gemini, or any OpenAI-compatible provider. No vendor lock-in.
- REST API — JWT + OAuth2 authentication, subscription billing via Stripe
- Self-hosting — Docker Compose with bundled PostgreSQL, Redis, and Caddy (automatic TLS)
- Envelope encryption — AES-256-GCM for all stored secrets
- Credential scanning — user-submitted code is scanned for leaked secrets
Namespace Git export/import
Back up your namespace to any Git repository — GitHub, GitLab, Gitea, Bitbucket, or self-hosted. MCPWorks serializes all your services, functions, and agent definitions into YAML + code files, commits, and pushes.
# Your AI assistant says:
"Export my analytics namespace to Git"
# MCPWorks produces:
analytics/
namespace.yaml
services/
utils/
functions/
analyze-csv/
function.yaml # schemas, requirements, tags
handler.py # the actual code
agents/
leadgenerator/
agent.yaml # config, prompts, schedules
Import from any Git URL to recreate the namespace on a different instance. Secrets are never exported — env var names only.
Third-party MCP server plugins (the big one)
This is the feature that makes MCPWorks a platform, not just a sandbox.
You can now bolt any third-party MCP server onto your namespace. Google Workspace, Slack, GitHub — add it once, and every function in the sandbox can call its tools with the same token efficiency as native functions.
How MCP server plugins work — an example
Let us walk through a concrete scenario: building an email response agent using Google Workspace.
Step 1: Add the MCP server
"Add the Google Workspace MCP server to my namespace
at https://google-workspace-mcp.example.com/mcp
with token ya29.xxx..."
MCPWorks connects, discovers 40+ tools (search Gmail, read Sheets, create Docs, etc.), encrypts the token, and caches the tool schemas.
Step 2: Write a function that uses Google Workspace
from functions import mcp__google_workspace__search_gmail_messages
from functions import mcp__google_workspace__read_sheet_values
# Search Gmail for unread emails from clients
emails = mcp__google_workspace__search_gmail_messages(
query="is:unread from:(@clientcorp.com)"
)
# Load response templates from a Google Sheet
templates = mcp__google_workspace__read_sheet_values(
spreadsheet_id="abc123",
range="Templates!A1:C50"
)
# Match emails to templates (all inside the sandbox)
responses = []
for email in emails:
subject = email.get('subject', '').lower()
for row in templates.get('values', []):
if row[0].lower() in subject:
responses.append({
'to': email['from'],
'subject': f"Re: {email['subject']}",
'template': row[1],
'priority': row[2]
})
result = {
'matched': len(responses),
'unmatched': len(emails) - len(responses),
'responses': responses[:5] # preview first 5
}
What just happened
The AI sent ~80 tokens of code. Inside the sandbox:
- Two MCP calls went through the internal proxy to Google Workspace
- Google returned 50 emails and 50 template rows — potentially 20,000+ tokens of data
- The matching logic ran locally in the sandbox
- Only the summary (
matched,unmatched, 5 previews) came back — ~150 tokens
The AI never saw the full email contents or the entire spreadsheet. The Google Workspace credentials never entered the sandbox — the proxy decrypted them server-side.
The data flow
Sandbox MCPWorks API Google Workspace
| | |
| search_gmail_messages() | |
|-- POST /internal/mcp-proxy ->| |
| + bridge key |-- MCP tools/call ------->|
| | + decrypted token |
| |<-- 50 emails ------------|
|<-- emails (in sandbox) ------| |
| | |
| read_sheet_values() | |
|-- POST /internal/mcp-proxy ->| |
| |-- MCP tools/call ------->|
| |<-- 50 rows --------------|
|<-- rows (in sandbox) --------| |
| | |
| [match emails to templates] | |
| [all processing in sandbox] | |
| | |
|-- result: {matched: 12} ---->| (to AI context) |
"MCP servers as a service with credential isolation is the right primitive. The moment agent credentials enter the sandbox, you've lost the security model. Token-wrapped access is how OAuth should've always worked for agents."
This is exactly the architecture. The sandbox calls functions. The proxy handles credentials. They never meet.
Step 3: Tune settings
Each MCP server has LLM-configurable settings:
"Set the response limit for google-workspace to 2MB"
"Set the timeout to 60 seconds"
"Disable the slack server temporarily"
Settings include response_limit_bytes, timeout_seconds, max_calls_per_execution, retry_on_failure, and enabled. All tunable by the AI or the user through MCP tools.
Step 4: Give the agent access
"Configure my email-responder agent to use the
google-workspace MCP server"
The agent can now call Google Workspace tools during its scheduled runs. The orchestrator resolves server names from the namespace registry, decrypts credentials, and makes tools available — the agent never sees raw tokens.
The namespace hierarchy
MCP servers sit as a parallel concept to services within your namespace:
Namespace: assistantpam
├── Services (native)
│ └── email-tools
│ └── format_report → code_sandbox
│ └── check_priority → code_sandbox
├── RemoteMCP (external)
│ └── google-workspace
│ └── search_gmail_messages → proxied
│ └── read_sheet_values → proxied
│ └── slack
│ └── send_message → proxied
│ └── list_channels → proxied
Both are callable from the sandbox. Native functions run locally as Python. RemoteMCP functions route through the internal proxy. The mcp__ prefix distinguishes them:
# Native function (runs in sandbox)
from functions import format_report
# Remote MCP function (proxied to Google)
from functions import mcp__google_workspace__search_gmail_messages
Self-hosting
git clone https://github.com/MCPWorks-Technologies-Inc/mcpworks-api.git
cd mcpworks-api
cp .env.self-hosted.example .env
# Edit .env — set your domain, generate keys
docker compose -f docker-compose.self-hosted.yml up -d
Community edition is free with no limits. The sandbox runs in dev mode on macOS/Windows (no isolation) and production mode on Linux (full nsjail isolation).
What is next
We are building in public and looking for contributors. The GitHub Discussions are open. The spec-first development workflow means every feature starts with a specification before code — and those specs are in the repo for everyone to read.
Near-term priorities:
- Console UI for MCP servers — expandable cards showing settings, env vars, and tools per server
- OAuth flows for MCP servers — connect Google/Slack without manually generating tokens
- Git-first workflow — edit functions in your IDE, push, namespace updates automatically
- Namespace registry — share and discover namespaces like npm packages
If you think AI agents should cost 99% less to run, star the repo and try it.
GitHub: MCPWorks-Technologies-Inc/mcpworks-api | MCPWorks Cloud | Bluesky: @mcpworks.io
MCPWorks is open source.
Self-host free forever, or try MCPWorks Cloud — 14-day Pro trial, no credit card.