Waxell MCP Gateway

The MCP Gateway is one MCP server that fronts all of them. Your agents, your team's Claude (Cowork, Desktop, Claude Code), and any MCP-capable client connect to a single endpoint:

https://mcp-gateway.waxell.dev/mcp

Behind that endpoint, the gateway brokers to every upstream MCP server your tenant has installed — Notion, Linear, Slack, Stripe, Snowflake, your internal servers — from a catalog of 160+ connectors. Every tools/list and every tools/call passes through Waxell's policy engine, identity resolution, and audit log before it reaches the upstream.

Why a gateway

When an employee connects Claude directly to Notion, that connection is invisible to you. When fifty employees connect a dozen tools each, you have hundreds of ungoverned pathways between AI and your company's data — each with its own token, no policy, and no audit trail.

The gateway collapses all of that into one connection per person:

• One consent surface. Users connect tools once, through your tenant, with their own accounts. Calls run as them — attribution survives all the way to the upstream.
• Preventive control. Deny, redact, require approval, rate-limit, and cost-cap rules evaluate before the upstream call happens — not after the damage.
• One audit log. Every call, decision, and result lands in a durable, exportable record with user, agent, tool, and policy outcome.
• Tool hygiene at scale. Fingerprinting detects when an upstream silently changes a tool's behavior (rug-pull defense), and tool subsetting keeps model context lean even with hundreds of tools available.

How it relates to MCP Governance (SDK)

Waxell ships two complementary control points:

	SDK-level governance	MCP Gateway
Where it runs	Inside agents you build (auto-instrumentor)	Between any client and the upstream
Best for	Your own Python agents — deepest context, reasoning traces	Cowork, Claude Desktop/Code, employees' tools, third-party agents you can't instrument
Sees	Agent reasoning, session, cost attribution	Every caller, every upstream, in one place

They share the same policy concepts and feed the same audit plane. Instrument what you build; route everything else through the gateway.

Agents & identity

A connection through the gateway is never just a token — it's bound to a specific agent identity. That's what makes every tool call attributable and governable: you always know which agent did what, acting for which person.

It works in three steps:

1. Register an agent. Give it a name, role, and playbook. This mints the agent's identity (its key). Each person can have several — "Research bot," "Ops bot," "My Cowork."
2. Connect a client and pick the agent. In Claude (Cowork, Desktop, or Code) you hit Connect, sign in to Waxell, and choose which of your agents this client is. The OAuth token is bound to that agent — there's no key to paste.
3. It acts as that agent. Calls are scoped to the agent's tools (via its tool subsetting tags) and attributed to the agent — and to you — on every audit row. When that agent writes to Notion, it writes as you, with your permissions, attributed to you in both Notion's log and Waxell's.

This is why the gateway is a governed surface rather than a raw proxy: identity travels with the call. Picking the agent at connect time is what ties the token, the person, and the agent's scope together.

End users don't need admin access. Everyone registers agents, connects their clients, and picks their agent from the Connect workspace (/c) — the same place they make tool connections. Admins manage upstreams, policy, approvals, and the audit log here in Governance.

Architecture at a glance

Claude / Cowork / Claude Code / your agents
                 │  (one MCP connection, OAuth or API key)
                 ▼
        ┌─────────────────────┐
        │   Waxell Gateway    │  identity → policy → (approval?) → dispatch
        │  policy · audit ·   │
        │  fingerprint · DLP  │
        └─────────────────────┘
          │       │        │
          ▼       ▼        ▼
       Notion   Linear   …160+ upstreams (catalog) + your internal MCPs

The gateway speaks standard MCP downstream (streamable HTTP) and standard MCP upstream — including the MCP authorization spec, which is how most catalog connectors work with zero manual credentials.

Where to go next

• Quickstart — connect Claude to the gateway in two minutes.
• Connector catalog — install upstreams and connect user accounts.
• Authentication modes — how upstream auth works, from fully automatic to bring-your-own.
• Policies — the rule engine: deny, redact, approve, rate-limit, cost-cap.
• Security — fingerprinting, drift defense, DLP, audit.