The Box open-source MCP server just shipped a few updates that fix crucial problems. Three new features bring you more tools and eliminate some frustrating authentication steps.
What changed
Here’s what’s new:
usage: mcp_server_box.py [-h]
[--transport {stdio,sse,http}]
[--host HOST] [--port PORT]
[--auth {oauth,ccg}]
Box MCP Server options:
-h, --help Show this help message and exit
--transport
{stdio,sse,http} Transport type (default: stdio)
--host HOST Host for SSE/HTTP transport (default: 0.0.0.0)
--port PORT Port for SSE/HTTP transport (default: 8000)
--auth {oauth,ccg} Authentication type (default: oauth)
As you can see, we’ve made three additions: SSE transport, HTTP transport, and CCG authentication. Read on to see why each one matters for your local development setup.
CCG authentication: Service accounts
The biggest improvement is CCG (Client Credentials Grant) authentication. OAuth was functional but frustrating. When using this for the first time, you’d get interrupted by browser popups asking you to authorize the application.
CCG eliminates that flow entirely. More importantly, it opens up service accounts. Your Box admin can create a dedicated account for your MCP server and control exactly what it can access:
- Read-only access to specific folders
- Document generation permissions but no deletion rights
- Access to shared content without personal account dependencies
This is cleaner for testing and gives your admin proper control over what your local MCP server can touch.
Important caveat: The Community MCP Server was built for single-user, local test deployments, and does not implement MCP Client authentication. When using it, credentials get cached locally. Don’t just slap this on a shared server and call it production-ready without thinking through the security implications.
Transport options: Because not everything speaks STDIO
The original STDIO-only approach created compatibility problems. Plenty of MCP clients only support HTTP or SSE transport, which meant you couldn’t use them with the Box MCP server at all.
Now you have options. Your local MCP server can speak whatever protocol your client tools expect.
Real example: n8n integration
Let’s see this in action with n8n, a workflow automation tool that benefits from SSE transport. In n8n, MCP servers can only be used if they support SSE transport.
Server configuration:
uv run src/mcp_server_box.py \
--transport sse --host 0.0.0.0 --port 8001 \
--auth ccg
INFO: Started server process [4959]
INFO: Waiting for application startup.
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)
Environment configuration for a service account CCG authentication:
BOX_CLIENT_ID = YOUR_CLIENT_ID
BOX_CLIENT_SECRET = YOUR_CLIENT_SECRET
BOX_SUBJECT_TYPE = enterprise
BOX_SUBJECT_ID = YOUR_ENTERPRISE_ID
n8n Workflow setup:
An MCP node configuration will look like this in n8n:
Here is a simple chat bot workflow example:
And if we go back to our server, we can see the requests going in:
uv run src/mcp_server_box.py \
--transport sse --host 0.0.0.0 --port 8001 \
--auth ccg
INFO: Started server process [4959]
INFO: Waiting for application startup.
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)
INFO: 127.0.0.1:55299 - "GET /sse HTTP/1.1" 200 OK
INFO: 127.0.0.1:55300 - "POST /messages/?session_id=d09a455a79ad4eefa2200c05e3b5fef6 HTTP/1.1" 202 Accepted
INFO: 127.0.0.1:55300 - "POST /messages/?session_id=d09a455a79ad4eefa2200c05e3b5fef6 HTTP/1.1" 202 Accepted
INFO: 127.0.0.1:55301 - "POST /messages/?session_id=d09a455a79ad4eefa2200c05e3b5fef6 HTTP/1.1" 202 Accepted
INFO: 127.0.0.1:55300 - "POST /messages/?session_id=d09a455a79ad4eefa2200c05e3b5fef6 HTTP/1.1" 202 Accepted
Why this matters
These updates solve two specific problems that were blocking real use cases, even in local development.
More authentication options: CCG authentication cuts out the whole browser-based OAuth flow. No more “click here to authorize” popups interrupting your workflow. More importantly, your Box admin can create a service account with exactly the scopes your application needs — nothing more, nothing less. Want read-only access to specific folders? Done. Need document generation but no file deletion? Easy. The admin controls the permissions, not the user clicking “allow.”
MCP client compatibility: Here’s the reality — not every MCP client implements STDIO transport. Some only do HTTP. Others prefer SSE for real-time updates. Before these updates, you were out of luck if your preferred MCP client couldn’t speak STDIO. Now you can actually use tools like n8n or other workflow platforms that expect HTTP endpoints.
The n8n example isn’t theoretical. You can literally point n8n at http://localhost:8000 running your Box MCP server and start building workflows that interact with Box content. Same goes for any other tool that consumes HTTP APIs but has never heard of STDIO transport.
These aren’t massive architectural changes — they’re practical fixes for problems that make you ask, “Why can’t I use this with my existing tools?”
The bottom line
These updates remove friction. No more OAuth interruptions during development. No more “this MCP client doesn’t work with STDIO” limitations. Just cleaner authentication and broader tool compatibility.
To learn more, check out our community GitHub repo.
