Servers
Group tools into collections — give the right capabilities to the right MCP clients
Servers
You have 50 tools but a given client only needs a handful. A support client needs order lookup and ticket creation. An internal client needs everything. Exposing all 50 to each one is noisy and risky.
A server is a named, curated collection of tools. Create a "Support" server, add the right tools, and point a client at it — that client gets exactly those capabilities, nothing more.
How Servers Work
A server bundles tool IDs and can override how each tool is named or described per context. Servers let you:
- Curate tool collections for specific use cases
- Override a tool's name or description for a given client
- Gate sensitive tools behind human approval with toolset policies
Quick Start
Name it, describe it, and optionally seed it with tools:
protobox toolsets create "Support Tools" \
--description "Tools for customer support" \
--tool lookup_order --tool create_ticketcurl -X POST "https://platform.protobox.ai/api/v1/toolsets" \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Support Tools",
"description": "Tools for customer support",
"tools": ["tool-id-1", "tool-id-2"]
}'protobox toolsets add <toolset> <tool-slug-1> <tool-slug-2>Or in the dashboard: open the server and add tools from your workspace.
Point the client's MCP connection at your workspace endpoint with the server selected — the CLI emits (and offers to install) the config block:
protobox mcp connect claudeThe client now sees only the tools in that server.
Managing Servers
# List toolsets
protobox toolsets list --search "support"
# View a toolset and its members
protobox toolsets get <toolset>
# Add / remove tools
protobox toolsets add <toolset> <tool-slug-1> <tool-slug-2>
protobox toolsets remove <toolset> <tool-slug-1>
# Rename / re-describe a tool as this toolset serves it (applies live)
protobox toolsets override <toolset> <tool> --name find_order --description "Find a customer order"
# Gate a tool behind human approval
protobox toolsets policy <toolset> --require-approval <tool>
# Delete
protobox toolsets delete <toolset>Server Strategy
| Client Type | Server | Tools |
|---|---|---|
| Customer support | support | lookup_order, create_ticket, check_warranty |
| Sales | sales | get_pricing, book_demo, check_availability |
| Internal | internal | All enabled workspace tools |
Use protobox toolsets override to rename or re-describe a tool for a specific server without touching the underlying tool. The same lookup_order tool can read as find_order in one server and order_status in another.
End users sign in as themselves
A server you build isn't only for you — turn on end-user sign-in and anyone your workspace admits (any signed-in email, an allowed domain, or an invited address, your choice) can connect their own MCP client to it and authorize with their own account instead of sharing your workspace API key.
Each end user gets a distinct identity, not a copy of yours: their tool calls are audited under their own name, never lumped in with the workspace owner's, and you govern them individually from Users in the dashboard — see who's connected, when they were last active, and revoke one person's access without touching anyone else's.
Turn it on from Users in the dashboard (the access panel at the top of the page), or via the API:
curl -X PATCH "https://platform.protobox.ai/api/v1/workspaces/YOUR_WORKSPACE_ID" -H "Authorization: Bearer YOUR_TOKEN" -H "Content-Type: application/json" -d '{"endUserAuth": {"access": "anyone"}}'access is "off" (default), "anyone" (any signed-in email), "domains" (restrict to
domainAllowlist), or "invited" (only an address you've explicitly invited — never admits
speculatively). Once it's on, a client authorizing against your server's endpoint sees a sign-in
prompt instead of asking for an API key.