1Password MCP Server Cursor IDE Setup 2026

How do you set up the 1Password MCP server in Cursor? Install it as a plugin through Cursor's Agents customization panel — search "1Password," add it, restart — rather than hand-editing mcp.json. Authentication runs through the 1Password desktop app itself: when Cursor needs access to an Environment, the 1Password app shows a local authorization prompt you approve. The detail that matters most here: this official server can list and manage 1Password Environments and variable names, but it cannot return the actual secret values to the model. Secrets stay in 1Password and only ever land in locally mounted .env files, never in Cursor's chat context.

That's a fundamentally different security model than most credential-adjacent MCP servers, and it's worth understanding before you connect anything holding production secrets to an AI coding assistant.

What the 1Password MCP Server Enables (and What It Deliberately Doesn't)

Once connected, Cursor can:

What it explicitly cannot do: return secret values to the MCP client. Even if a prompt directly asks for a value, the server won't hand it over through the protocol. Secrets are injected into the mounted .env file locally and never transit through the model's context window, chat history, or Cursor's request/response payloads.

This is a deliberate design choice by 1Password, not a current limitation — the whole point of the Environments MCP Server is giving coding agents the ability to use secrets without ever being able to see them.

Prerequisites

Step 1: Install via the Cursor Plugin

1. Open Cursor and go to the Cursor Agents window
2. Select Customize → Plugins
3. Search for "1Password" and select Add
4. Restart Cursor

The plugin registers the MCP configuration automatically — you don't hand-edit mcp.json for the standard setup. If you're on a client that supports manual stdio entries and need to configure it directly, the equivalent block is:

{
  "mcpServers": {
    "1password": {
      "command": "1password-mcp"
    }
  }
}

Step 2: Verify the Connection

Go to Settings → Tools & MCP in Cursor and confirm the 1Password entry shows as connected.

In chat, try:

List my 1Password Environments

The 1Password desktop app will show a local authorization prompt the first time — approve it. You should not be prompted for a password or token inside Cursor itself; the desktop app handles the actual auth.

Step 3: Set Up an Environment for a Project

Create a new 1Password Environment called "myapp-dev" and add a variable for DATABASE_URL

Cursor will prompt you (via the 1Password app) to actually supply the value the first time — it doesn't invent one, and it can't read one back to you afterward either.

Practical Workflows

Scaffolding a new project's local secrets

Create a 1Password Environment for this project called "checkout-service-local" and mount it as a .env file in this repo

Auditing what's configured without exposing values

List every variable name in the "production-api" Environment so I can check we're not missing a required config key — don't show me the values, just the names

Onboarding a new environment variable across dev and staging

Add a new variable called STRIPE_WEBHOOK_SECRET to both the "dev" and "staging" Environments — I'll enter the actual values when prompted

Confirming an app reads from the right mounted file

Show me which .env files are currently mounted from 1Password Environments in this project directory

Troubleshooting

No authorization prompt appears when a tool call needs approval
Confirm the 1Password desktop app is running and unlocked — the MCP server delegates the actual auth UI to the app, not to Cursor or a browser. If the app is locked or not running, tool calls will hang or fail rather than prompt.

A prompt asks for a secret value that already exists
This happens if you're creating a variable name that doesn't yet have a stored value in that Environment — the server can add empty variable slots, but it needs a human to actually supply the first value through the 1Password app's own UI, by design.

Cursor can't find the "1password-mcp" command
This means the plugin install didn't complete correctly. Reinstall through Customize → Plugins rather than trying to hand-write the mcp.json entry — the plugin path handles binary installation that a manual JSON block assumes is already done.

Team members report different Environments visible
Environment visibility follows normal 1Password account and vault permissions — the MCP connection doesn't grant broader access than what the signed-in 1Password account already has. If a teammate can't see an Environment you can, check their 1Password vault membership, not the MCP config.

When This Doesn't Make Sense

If your workflow genuinely needs the AI to read a secret value directly — for example, debugging why an API call is failing with a specific malformed key — this integration won't help, and that's intentional. For that narrower case, community alternatives exist that use a 1Password Service Account token and do return secret values through the MCP channel, but that's a materially different security posture: those secrets do transit the model's context. Understand which one you're actually running before connecting either to a vault holding production credentials — the official Environments server and community service-account-based servers are not interchangeable in what they expose.

Frequently Asked Questions

Q: Can the AI ever see my actual secret values through this integration?
A: No. The official 1Password Environments MCP Server is built specifically so secret values never transit the model's context window, terminal output, or on-disk files outside the locally mounted .env file. It can list variable names and manage Environments, but not read values back.

Q: Do I need a 1Password Service Account token to use this?
A: No — that's a different, community-built approach (like the @takescake/1password-mcp package), which does use a Service Account token and does return secret values. The official Environments MCP Server authenticates through the 1Password desktop app instead, with no static token involved.

Q: What actually happens when my app needs to read a secret at runtime?
A: The value lives in a locally mounted .env file that the 1Password app manages — your application reads it the normal way any app reads environment variables. The MCP server's role is managing which Environments and variable names exist and are mounted, not serving as a runtime secrets proxy.

Q: Does this work for team-shared secrets, or only personal vaults?
A: It follows standard 1Password vault and Environment permissions, which support team sharing. Anyone on the team with access to a given Environment through their normal 1Password permissions can use it through their own MCP connection — access isn't broadened or narrowed by the MCP layer itself.

Q: Is this compatible with other coding agents besides Cursor?
A: Yes — 1Password's own documentation lists Codex and Kiro alongside Cursor as supported MCP clients for the Environments server, since it's a standard MCP server rather than a Cursor-specific integration.

Related Guides

---