Deploy with Cursor for Teams

This doc is for a Cursor for Teams / Business admin rolling Data Workers out to the whole workspace, rather than each engineer configuring their own .cursor/mcp.json.

Before you begin

• Cursor for Teams admin access (Settings → Team → MCP Servers).
• Your team install bundle and team API key from your onboarding engineer. The key is a secret — distribute it through your team’s secret store (1Password, AWS Secrets Manager, etc.), never embedded in the pushed config.

Push the team config

1. Get the team bundle from your onboarding engineer — it’s the standard Cursor config plus team identification, with the key referenced from the environment rather than pasted in:

   {
     "mcpServers": {
       "dataworkers": {
         "url": "https://mcp.dataworkers.io/v1",
         "headers": {
           "X-Mcp-Source": "cursor",
           "Authorization": "Bearer ${env:DW_API_KEY}"
         }
       }
     }
   }

2. Paste it into Settings → Team → MCP Servers and mark it Required + Locked. Cursor syncs it to every member’s config (typically under a minute); members see the server with a “Managed by your team” badge and can’t edit or remove it.

3. Distribute DW_API_KEY through your secret store so it’s present in each member’s environment.

Checkpoint: a member restarts Cursor, sees dataworkers managed and green in Settings → MCP, and “What’s the status of my data connectors?” answers.

Key rotation

Team keys rotate through your onboarding engineer (self-service rotation is on the roadmap). Rotation includes a short grace window in which both keys work; members pick up the new key on their next environment reload — no Cursor restart needed, because the key is read from the environment per call.

What Cursor for Teams doesn’t do (so we cover it server-side)

• No per-role allowlists inside a team — the pushed config applies to every member, on a shared team key. Sub-team policy (“data engineers can call write tools, analysts read-only”) and per-user attribution are enforced on the Data Workers side via your SCIM group mapping — which is why identity wiring should start in parallel, not after fleet rollout.
• No programmable push API (as of current Cursor releases) — config updates are re-pasted by the admin in the web UI; your onboarding engineer tells you when the bundle needs updating.

Audit

Every request from the team lands in the audit trail tagged with its source and team identity — session opens, tool calls (argument hashes, never argument contents), auth failures (with admin alerting on repeated failures), and key rotations. Ask your onboarding engineer for the current export during the pilot.