url per
MCP consumer, and the agent sees the merged toolkit that consumer
is routed to. Copy the endpoint from the consumer Connect tab (Cursor snippet):
ag_. A
TrustGuard collector key (tgk_…) never authenticates MCP.
Where the config lives
Both files load. When the same server name exists in both, the project file wins in
that workspace. Cursor infers the transport from the keys:
url means remote, command
means local — never mix them in one entry.
OAuth consumers (recommended)
Omitheaders and let Cursor run the handshake. TrustGate advertises discovery at
/.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource and
supports dynamic client registration, so no client ID or secret is pasted anywhere.
https://www.cursor.com/agents/mcp/oauth/callback (web and Cloud Agents) and
http://localhost:8787/callback (desktop) — and TrustGate accepts both shapes, so nothing
has to be whitelisted per developer. Cursor’s static auth block (client ID and secret) is
for providers without dynamic registration and is not needed here; which IdP backs the login
is a property of the consumer, set once in the console.
Use OAuth for consumers that resolve tools per user — the identity Cursor logs in with
selects the roles, and therefore the registries and tools, on
Identity-based consumers.
API-key consumers
Send the consumer key as a header. TrustGate acceptsX-AG-API-Key, x-api-key, or
Authorization: Bearer ag_….
${env:VAR} in url and headers, so a committed project file carries no
secret. Export the variable where Cursor can read it (shell profile or your secret tooling)
and reload the window.
Authenticating to TrustGate is not the same as authenticating to the upstream servers. When
a registry uses OAuth (forwarded), the first call for a user without a stored credential
returns a connect link; the user authorizes once and TrustGate vaults and refreshes the
credential from then on.
Private (Hybrid) data plane
Add the gateway slug unless the MCP host already scopes the gateway:X-AG-Gateway-Slug alone.
Apply changes
After editingmcp.json, refresh the server (or toggle it off and on) in Customize.
Editing the file alone does not reconnect an already-loaded server, which is the most
common “my tools did not appear” cause.
Tools and approvals
Two products decide two different things here, and the setting names are easy to confuse:
The two Cursor rows are per laptop. Limits that must hold for every client belong on the
consumer or role. For an execution ceiling on MCP tool calls, attach the
Per-Tool Rate Limiter policy — the other tool
governance policy, Tool Injection, is LLM-only and does not affect MCP.
Team rollout
A gateway consumer is the same URL for everyone, so it distributes well from the Cursor dashboard instead of asking each developer to editmcp.json:
Allowlisting approves a configuration; it does not install or enable the server. Keep the
authoritative tool scope on the consumer or role — the Cursor-side tool allowlist governs
automatic execution, not what the agent can see.
With the NeuralTrust plugin
The Cursor plugin can register the same server from plugin variables (Customize → Plugins → Configure), so a team admin sets it once instead of shippingmcp.json:
Use the plugin entry or
mcp.json — two entries with the same URL duplicate every
tool. cursor.json is the TrustGuard firewall config and never holds MCP values.
Firewall hooks are a separate plane: TrustGuard Cursor.
When both are installed, MCP tools/call traffic is still evaluated by the preToolUse
and postToolUse hooks.
Verify
- Customize lists TrustGate as enabled, and its tools appear under Available Tools in chat.
- Ask the agent to call a tool bound to that consumer.
- Confirm the call in TrustGate telemetry — see Metrics.
Cmd+Shift+U) and select
MCP Logs.
Troubleshooting
Related
- MCP overview — consumers, catalog merging, upstream auth
- Auth — MCP consumers use API key or OAuth2
- TrustGuard Cursor — firewall hooks
- Cursor MCP docs