Skip to content
DocsOverview & setup
MCP Gateway

MCP Gateway

Agents call tools: MCP servers such as Linear, GitHub or Stripe, and plain REST APIs. The MCP Gateway sits between your agents and those tools. Agents connect to a VectorAxis URL instead of the tool, and every call is checked against the tools you approved, scanned by guardrails, held for a person when it is risky, sent with credentials the agent never sees, and logged.

The MCP Gateway is part of the Pro and Enterprise plans. Tool governance on chat completions (scanning tool results and recording which tools your agents use) works on every plan; see tools on the chat API.
How it fits together
PieceWhat it is
ConnectorOne upstream tool source, registered once: an MCP server, or a REST API described by an OpenAPI spec or by endpoints you declare. It holds the URL, the credentials and the list of capabilities (tools, prompts, resources) the gateway found, each of which you switch on or off. A connector belongs to a workspace, or to the organization and is shared with the workspaces you choose. Connectors
EndpointA workspace’s gateway URL for one connector, https://mcp.vectoraxis.ai/s/mcps-…. Agents point their MCP client here. An endpoint can only narrow its connector: switch tools off, add guardrails, limit who may use it, decide what the server may ask for.
MCP keyThe credential an agent sends, Authorization: Bearer va_…, created on the MCP keys page. It belongs to one workspace, works only on the gateway (never on the VectorAxis API), and can be limited to certain tools and a number of calls per minute and per day. Virtual keys are for LLM providers and are not accepted by the gateway.
PeopleA person using Claude, Cursor or another MCP client signs in through VectorAxis instead of using a key, so calls are made as them and per-person access rules apply. Signing in
One URLhttps://mcp.vectoraxis.ai/s/vectoraxis: the gateway’s own MCP server, with three tools (discover, inspect, run) that reach every endpoint in the key’s workspace. One URL for every endpoint
Egress modeFor agents that call a REST API with a plain HTTP client: point the client’s base URL at https://mcp.vectoraxis.ai/h/mcps-… and every request gets the same controls as a tool call. Egress mode
Set it up
1
Add a connector
MCP Gateway → Connectors → New connector. Choose what it connects to (an MCP server, a REST API with an OpenAPI spec, or a REST API whose endpoints you declare), give its URL, and how the gateway authenticates to it. Workspace admins add connectors for their workspace; organization admins can add one shared across workspaces.
2
Sync, then choose the tools
Sync capabilities reads what the connector offers. On the Capabilities tab, switch on what agents should have, and mark tools Privileged or Needs approval where a person should stay in the loop. Tools imported from a REST API all start switched off, and every operation that changes data starts Privileged.
3
Create an endpoint
Endpoints → New endpoint (or Create an endpoint from this connector on the connector). Its Connect tab shows the URL and ready-made client configuration.
4
Create an MCP key
MCP keys → New MCP key. Copy it when it is shown: only its last four characters are kept in view afterwards. Optionally limit it to some tools and set calls per minute and per day.
5
Point the agent at the endpoint
Claude Code, with the key in the header:
Bash
claude mcp add --transport http linear https://mcp.vectoraxis.ai/s/mcps-0123456789abcdef \
  --header "Authorization: Bearer $VECTORAXIS_MCP_KEY"
Clients configured with a JSON server list that takes headers (Cursor, VS Code and others):
JSON
{
  "mcpServers": {
    "linear": {
      "url": "https://mcp.vectoraxis.ai/s/mcps-0123456789abcdef",
      "headers": { "Authorization": "Bearer <MCP key>" }
    }
  }
}
6
Watch and decide
Every call is in Logs → MCP calls, with its arguments and result when your plan keeps log bodies. Calls held for a person appear on Approvals.
What happens on every call

The gateway reads each message once, strictly (a message with a key given twice is refused), and what it checked is exactly what it forwards. For a tool call, in order:

  1. Who is calling: the MCP key, or the signed-in person. Keys and people are refused outside their workspace.
  2. Rate limits: the key’s own limits and the plan’s limit per workspace, counted apart from LLM traffic.
  3. The registry: the tool must be known, switched on for the connector and the endpoint, unchanged since it was approved, not quarantined, and in the key’s tool allowlist. Anything unknown is refused.
  4. The call policy: a Privileged tool is held when the caller recently received untrusted content; a Needs approval tool is always held for a person.
  5. Guardrails on the arguments, then the call, made with the connector’s credentials. The agent’s own credentials never reach the tool.
  6. Guardrails on the result, before the agent sees it.
  7. The record: the call is logged, the result marks the caller as having received untrusted content (unless the tool is marked Trusted output), and the tool’s health is updated.

Tool lists are filtered the same way, so an agent is only shown tools it may call, and only in the exact form that was approved. A refused tool call comes back as a tool result the model can read, saying what was stopped and why.

In the dashboard
PageFor
EndpointsEndpoints, their URLs and settings; Find a tool across every endpoint; the one-URL server.
ConnectorsConnectors, sync, capabilities and their switches, guardrails, which workspaces may use a shared connector, audit log.
MCP keysAgents’ keys: create, limit to tools, rate limits, revoke.
ApprovalsCalls waiting for a person, and what was decided.
Tool inventoryEvery tool your agents used, including tools no connector exposes (shadow tools).
Logs → MCP callsEvery governed call and every refusal, with the caller, the result and what the guardrails found.
NVIDIA Inception Program member

VectorAxis is built by GK Labs, a member of NVIDIA Inception.