A Cursor MCP integration checklist

Add a Cursor MCP server only after choosing the account, resources and operations it should expose. Verify one known read before relying on its output in a code change. This is a proposed integration exercise for a team, not a certification that a server is safe.

The three earlier setup notes repeated the same configuration and review loop. This consolidated guide keeps their useful distinctions: personal versus project configuration, task-specific tool access, and a verification check that another engineer can repeat.

What should the server be allowed to do?

Start with a concrete use case, such as reading architecture documentation for one service. Name the integration owner and the resource collection. Use a dedicated read-only account where the provider supports one. Leave production writes and unrelated document collections outside that account's permissions.

Cursor rules and AGENTS.md can explain the intended use to an agent. They do not revoke a token's permissions. A server-side access check must enforce the actual boundary, including when an external document contains instructions to read another resource. Treat retrieved text as data, not authorization.

Where does the configuration belong?

Cursor supports project configuration in .cursor/mcp.json and user configuration in ~/.cursor/mcp.json. Choose project scope when the team shares the integration definition, and user scope for personal setup. Keep credentials out of committed files. Follow the server's documented authentication method and the Cursor MCP documentation for the supported transport and configuration fields.

Do not copy a server command from a third-party article without reviewing the package and publisher. A local server runs code on its host. A remote server receives the information sent to it. Those are different trust decisions even when both appear as tools inside the editor.

How can the team verify it?

Choose a harmless fixture: a known issue or documentation page in a test project. Ask Cursor to read that record, report its identifier and summarize one fact that you can check yourself. Do not combine this first test with a production code change.

Next, ask the integration owner to test a forbidden operation using disposable data. A read-only account should be rejected by the provider when it attempts a write. An agent following a rule and refusing the request is useful behaviour, but it is not evidence of server-side enforcement. Record what was actually tested.

When do rules, skills and subagents help?

Use a short rule for durable guidance about when this integration belongs in a task. Add a skill only if the procedure repeats. A separate subagent is useful when the work has a bounded output, such as collecting relevant documentation, but is not required for every server. Configure its tools and permissions separately from the prose describing its role.

For one-off work, the setup and review note may be enough:

Integration purpose and owner:
Configuration scope:
Allowed resources and operations:
Credential permissions checked:
Known read and denied-action results:
External context used in the change:
Remaining uncertainty:

Review the resulting diff and run normal repository checks after using the context. Stop if required context is unavailable or contradicts the task; do not silently substitute another account or broader credentials. Keep the subagents and skills guide for the wider workflow.

Editorial update

Updated 20 September 2026: combined three MCP setup articles, removed unrelated SDK release claims, and made the distinction between instructions and enforced access explicit.