MCP Workspace in 60 Seconds — Team MCP Setup — Aerostack Blog

The Problem at Scale

Day 1 covered the personal pain — switching editors, reconfiguring MCPs, scattered credentials. That's annoying for one developer. It becomes a real operational problem when your team grows.

When a team goes from 1 to 10 to 50 developers, per-machine MCP config breaks down in predictable ways:

No visibility. You have no idea which developers are using which tools, how often, or whether they're failing.
No revocation. A developer leaves. Their API keys are pasted into config files on their laptop, maybe in a shared .env someone copied months ago. You can't revoke access without tracking down every copy.
No onboarding. A new hire joins. Someone spends 30 minutes walking them through which MCPs to install, which config format each editor expects, and which Slack thread has the current API keys.
No rotation. You need to rotate a credential. You email the team. Half of them update immediately. The other half break their setup and don't notice for a week.

A workspace solves all of this with one URL and per-member tokens.

What a Workspace Is

A workspace is a managed gateway that sits in front of your MCP servers. You create one, add MCPs from the registry (or your own servers), configure secrets once, and share the gateway URL with your team.

https://mcp.aerostack.dev/ws/engineering-team

Behind that URL: every MCP you've added, credentials encrypted, access controlled by token. Your team connects to one endpoint. They don't install MCPs locally. They don't copy API keys. They don't maintain per-editor config files.

When you add a new MCP to the workspace, every team member can use it immediately. When you rotate a credential, it updates everywhere at once. When someone leaves, you revoke their token and access stops instantly.

Creating a Workspace

From the dashboard, it's straightforward:

Name your workspace. Give it a name and you get a gateway URL with a slug.

Add MCPs. Browse the registry, search by name, or add your own MCP server URL. Each MCP you add becomes available as a set of tools through the gateway. You can add as many as you need — GitHub, Jira, Stripe, your internal database tool, whatever.

Configure secrets. Each MCP that needs authentication gets its credentials through workspace secrets. You enter the credential once. It's encrypted with AES-256-GCM and only decrypted at the moment a tool call needs it. The secret is never logged, never returned in API responses, and never visible to the LLM.

Issue tokens. Create tokens for your team members. Each token can have a role (Admin, Developer, Read-only) and an optional expiry date.

That's a workspace. The 60 seconds is realistic — we've done it. The time cost is the credential gathering, same as Day 2.

Access Control

Not everyone needs the same level of access.

Admin — add and remove MCPs, rotate credentials, revoke tokens, view audit logs, change workspace settings. This is your team lead or platform engineer.

Developer — use all configured MCPs, view their own execution logs. Can't change credentials or add new MCPs. This is most of your team.

Read-Only — can invoke MCP tools (run queries, searches), but can't view credentials or change configuration. This is for contractors, temporary access, or stakeholders who need to query but not configure.

The revocation model matters. When a developer leaves:

Revoke their token from the dashboard.
Access stops immediately, everywhere.
No per-machine credential cleanup.
No "email the team to rotate keys."
No hunting through git history for exposed secrets.

For contractors: create a Read-only token with a 14-day expiry. When the engagement ends, the token expires automatically. No manual cleanup.

Encrypted Secrets

Every credential in your workspace is encrypted with AES-256-GCM before storage.

The flow:

You enter a credential (GitHub token, API key, database connection string).
It's encrypted and stored. The plaintext is discarded immediately.
At runtime, when a tool call needs that credential, it's decrypted, injected into the MCP request, and discarded again.
Credentials never appear in logs, error messages, or API responses.

This is the security model you'd build yourself if you had time — except you don't have to. The workspace handles it so your team can focus on using the tools, not managing the secrets.

Observability

One of the hardest problems with decentralized MCPs is that you have no visibility into how your team uses them. MCPs installed locally on developer machines produce no telemetry. You can't answer basic questions: Who ran which tool? How often? Did it fail? How long did it take?

With a workspace, every tool call through the gateway is logged:

Which MCP and which tool
Which team member (by token)
Latency
Success or failure
Timestamp

Workspace observability dashboard showing per-developer tool usage and execution metrics

You can drill into any call to see what happened. The structural metadata is logged — the data payload is not. Observability without credential exposure.

This is how you answer questions like "why is the Jira MCP slow this week" or "which team member is hitting the GitHub rate limit" — questions you can't answer when MCPs live on individual machines.

Why This Matters Now

MCPs started as a developer convenience — a nice thing to have in your editor. But they're becoming operational infrastructure.

Your AI bots call internal tools through MCPs. Your workflows dispatch to them. Your agent endpoints route through them. At that scale, "install it on your machine" doesn't work. You need centralized configuration, encrypted credentials, per-member access control, and an audit trail.

That's a workspace.

The before/after:

Before: every developer manages their own MCPs. Credentials scattered. No visibility. Onboarding takes hours. Offboarding is a security risk.

After: one gateway URL. Secrets encrypted. Tokens per member. Instant revocation. Full audit trail. New hire gets one token and has access to everything.