MCP Gateway. One URL for every AI tool.

An MCP gateway is a single URL that routes to all your MCP servers, skills, and functions — so any AI agent only needs one connection instead of one per tool. Without a gateway, wiring Claude, Cursor, or ChatGPT to a dozen tools means a dozen config entries, a dozen separate secrets, and a dozen things to update when anything changes. Aerostack acts as an MCP aggregator: you compose every server and skill you need into one workspace, and the platform handles routing, auto-namespacing (so tools from different servers never collide), and encrypted secret injection at the edge. Paste the workspace URL once into your Claude Desktop, Cursor, or ChatGPT config and every tool in that workspace is immediately available. No per-tool routing logic, no credential sprawl, no re-config when you add a new server.

In the Aerostack dashboard, create a workspace and open the composer. Add any MCP server from the marketplace — Stripe, GitHub, Notion, Linear, or your own custom servers — by searching for it by name. Each server's tools are auto-namespaced so a tool called "search" from two different servers never conflicts. You can also add Aerostack skills (pre-built agents for common tasks) and edge functions from the same composer. Once saved, the workspace URL is live: any AI agent that connects to it sees the full merged tool list as if it were a single MCP server. Adding or removing a server from the workspace updates every connected agent instantly — no reconnect required on the client side.

Human-in-the-loop AI means an agent cannot execute a sensitive tool call — sending a message, writing to a database, charging a card — until a designated human approves it. Aerostack gives you two layers. Tool Gates intercept specific MCP tool calls (or whole servers via a wildcard) and require approval before execution; each gate has a risk level from low to critical, an approval expiry window, and optional auto-approve by role. Local Guardian works one level up, at the semantic level: it ships 25 built-in rule templates across 8 categories — file operations, shell and system, git, deploy and release, database, communication, financial and billing, and infrastructure — and the agent must call a guardian tool to request approval before a matching operation. When a gate or rule fires, execution pauses and an approval request is routed to the workspace owner or a team member; you approve or reject from the Aerostack dashboard or the OpenClaw mobile app, and the agent resumes where it left off with your decision logged. The agent never takes an irreversible action unattended.

Any client that speaks the Model Context Protocol works out of the box: Claude Desktop, Claude.ai Projects, Cursor, ChatGPT (via the MCP connector), Gemini, and any custom agent built on the Anthropic, OpenAI, or Google SDKs. Because the workspace exposes a single standard MCP URL, there is nothing platform-specific to install on the client side. Copy the workspace URL, paste it into the MCP servers config of whichever client you use, and the full tool list appears immediately. Aerostack is intentionally client-agnostic — swapping Claude for Cursor or vice versa is a config change, not a migration.

Secrets are stored encrypted at rest in Aerostack and are never sent to the AI client. When an agent calls a tool that needs a credential — an API key, OAuth token, or database connection string — the platform injects the secret at the edge at call time, so the value never travels through the agent's context window or appears in logs. You configure secrets once per workspace in the dashboard; all team members and all connected agents share the same injected credentials without ever seeing them. This zero-trust model means rotating a credential is a one-field update in the dashboard, not a hunt through every tool's config.

A workspace can be shared with any number of team members across three roles. Admins can add or remove servers, manage secrets and tokens, and approve tool gates. Members can call tools, create their own tokens, and view their own usage. Viewers can list the available tools but cannot call any of them. You invite people by email — if they are not on Aerostack yet, they get a pending invite with resend and cancel controls. Revocation is instant: removing a member cuts off their workspace access immediately and revokes all of their tokens, including any agents they were running under their credentials. Per-user analytics let you see which team member's agent called which tool and when, so you have a clear audit trail without instrumenting anything yourself.

Workspaces run on Cloudflare Workers at the edge, which means your MCP gateway is deployed globally with near-zero cold start. Tool calls route to the nearest Cloudflare location to the agent making the request — there are no servers to provision, no warm-up delays, and no capacity to manage. The free tier includes 500K AI tokens per month; if you bring your own model key (BYOK), the platform markup drops to zero and you pay only Cloudflare's edge compute rate. Because the entire Aerostack platform — workspaces, workflows, bots, and functions — runs on the same edge infrastructure, a tool call from a workspace into a workflow or a function adds no extra network hop.

If you only need one MCP server and one AI client and you control both ends, a direct server-to-client connection is simpler and a workspace adds no value. Workspaces are designed for the composition problem — multiple servers, multiple clients, or multiple team members sharing the same tool set. Similarly, if you are building a fully automated pipeline with no human-facing approval steps, no team access requirements, and no need to swap tools at runtime, a single Aerostack edge function or a workflow is a leaner fit. A workspace shines when the answer to any of these is yes: more than one MCP server, more than one AI agent, human-in-the-loop approval, or team-shared credentials. If all three answers are no, start with something simpler.

Each workspace has a policy engine that applies governance rules across every agent and token. You can write tool allow-lists with wildcard patterns (for example, allow only github__* tools), tool deny-lists that override the allow-list, IP allow-lists in CIDR notation, and a max-calls-per-day rate cap. Rules are named and prioritized, so a higher-priority deny rule always wins. There are five built-in templates to start from — Safe Agent, Production Guardrails, Read-Only Observer, Communication Safe, and Developer Sandbox — and each rule has its own enable and disable toggle. Policies apply at the workspace level before any per-token scoping, so the same guardrails protect every agent connected to that workspace.

Yes. Every workspace token can be scoped to a subset of the workspace tools, either at the moment you issue it or afterward. For example, you can issue a CI token that can only call github__create_issue and nothing else, or a webhook token with read-only access. Tokens are named, carry an expiry you choose (30 days, 90 days, 1 year, or never), and can be soft-revoked instantly. This is separate from workspace policies: policies set the outer boundary for every agent, and per-token scoping narrows what a single token is allowed to do inside that boundary.

Besides static API keys, a workspace has an OAuth connection manager for 15+ providers — including Google, GitHub, Slack, Discord, Notion, Microsoft, Figma, Trello, Asana, Dropbox, Linear, Atlassian, HubSpot, Salesforce, and Canva. You connect with a standard OAuth flow, so the agent acts on your behalf without you ever pasting a password. Tokens are AES-256-GCM encrypted on the OAuth broker, each connection shows its live status (active, degraded, or expired) and the scopes granted, and tokens are refreshed automatically by a background job so they do not silently expire. For Google you can bring your own OAuth client credentials, and you can connect any RFC 7591 compliant MCP server by URL through dynamic client registration without pre-registering credentials.

Both terms describe the same pattern. An MCP proxy intercepts MCP requests and forwards them to upstream servers, and the Aerostack workspace gateway does exactly this — adding credential injection, tool namespacing, policies, and access control in the proxy layer. Gateway is the more common term for hosted, managed deployments; proxy is more common for self-hosted setups. Aerostack is both: a hosted MCP proxy you do not have to operate yourself, acting as an MCP aggregator that merges many servers into one URL, with enterprise governance on top.