Review proposed MCP access capability by capability before delegating a coding task. Approve the smallest scope needed for the assignment, and pause when a tool's read, write, or external-system effects are unclear.
Separate your policy from mode behaviour
Cursor documents Run Modes as controlling how agent tool calls run and when approval is requested. Auto-review, Allowlist, and Run Everything differ in approval, sandboxing, and classifier behaviour.
That evidence supports checking mode-dependent permissions. It does not establish which MCP services are connected, their capabilities, or a universal approval rule for every call. Build your own intended permission boundary, then verify whether the selected mode and proposed tool arrangement meet it.
Do not treat the existence of a connection as permission to use all of its capabilities.
Write a capability register
For each proposed capability, record the following as editorial planning fields:
- Purpose: Why the coding assignment needs it.
- Read scope: Which specific records or resources may be inspected.
- Write scope: What could be created, changed, or removed.
- External effect: Whether another person or system could receive a change or message.
- Approval owner: Who may authorise that effect.
- Alternative: Whether a synthetic fixture can replace live access.
Record capabilities separately even when one service exposes several. Reading an issue and changing its status should not share a vague “issue access approved” entry. Leave unknown fields visibly unresolved.
Evaluate a hypothetical issue connector
Suppose a Bengaluru team is considering an MCP connector for a synthetic training tracker. For this example only, assume the proposed connector offers three capabilities: read an issue, edit its status, and post a comment. These are hypothetical capabilities, not claims about Cursor or a particular service.
The task is to draft a patch from invented issue DEMO-17. Reading that issue may be sufficient. Changing status and posting a comment are unnecessary external effects for the drafting stage.
Evaluate the register by asking whether removing either write capability prevents the patch from being reviewed. If not, exclude it from the proposed task permission. Use no customer tickets, private discussions, or credentials in the exercise.
Stop at an unexplained write
Stop if a read-only assignment unexpectedly proposes a write or reaches a resource outside the register. Next, obtain a revised task plan or a separate approval describing the exact effect and recipient.
If comparing coding access, visit the coding catalog to check access format and save offer terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or external-system authorisation.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Cursor Run Modes documentation establishes mode-dependent tool-call controls. The capability register and fictional connector are editorial examples, not verified integrations, detailed MCP permission guarantees, or marketplace terms.