Does AgentGuard bound Cursor?

No, not through MCP alone.

The goal is a brake on your agents that only you control: verifiable, no third party, no data leaves your machine for AgentGuard. The current MCP server gives Cursor a local spend decision tool and signed receipts. It does not sit between Cursor and its model provider, Cursor is not forced to call it, and the tool has no capability-ceiling input.

The exact Cursor configuration we ran

With Cursor CLI 2026.07.23-e383d2b, we put this in .cursor/mcp.json:

{ "mcpServers": { "agentguard": { "command": "npx", "args": ["-y", "@agentguard-run/[email protected]"], "env": { "AGENTGUARD_MCP_DAILY_CAP_CENTS": "500", "AGENTGUARD_MCP_PER_CALL_CAP_CENTS": "100" } } } }
agent mcp enable agentguard ✓ Enabled and approved MCP server: agentguard

Cursor accepted and approved the server. Its status-list command did not return before our timeout, so we tested the same configured stdio process through the MCP protocol directly. The published package initialized, listed its tools, returned decisions, and verified receipts.

What the MCP server really returned

ALLOWED DECISION
action=allow projected=2c seq=0 entryHash=22d496872b5b28ab1adb05fc8bdba644a87c4b8e3a6c85392023d28ef3600e42
signer=d115189ce375dfe6 signature prefix=eb9b55e741e6bac1f556e30a
SPEND DECISION REFUSED
action=block seq=1 reason=Cap 'per_call=3c' exceeded (spent=0c, +call=6c, total=6c) to block
CAPABILITY TEST FAILED
supported=false probeAction=allow note=extra capability fields are ignored
spend_decide inputs: endpoint_url, input_tokens, model, output_tokens

Offline verification

MCP_VERIFY valid=true tampered=false OFFLINE_VERIFY valid=true entries=3

Those receipts are real. What they prove is that the local MCP tool made and signed a decision. They do not prove Cursor consulted the tool before every provider call.

Why the verdict is no

A hard brake must be unavoidable on the path to the action. Cursor can call its model without calling spend_decide. An instruction that says “ask first” is agent cooperation, not enforcement. The current MCP schema also ignored the capability fields in our probe, so there was no honest capability refusal to show.

To make this a yes, Cursor needs a mandatory before-model or before-tool hook that can deny execution, or the provider client must be wrapped below Cursor. The MCP server also needs capability claim and required capability fields backed by the same server-side policy evaluation as the SDK.

Cursor integration verdictno
MCP loads
yes
signed spend decisions
yes
mandatory interposition
no
capability ceiling
no

The exact protocol harness is in scripts/adoption-smoke/mcp-outcomes.mjs. Use the MCP server for explicit decisions and receipt inspection today. Do not market it as a hard Cursor-wide bound.