Connect your agent · Cursor

Give Cursor Agent an inbox for the work it does.

Connect Cursor to a purpose-built email mailbox for issues, releases, and customer follow-up. Your own email account remains separate from the agent’s access.

For product engineers and Cursor Agent users who want an agent address for issue triage, release correspondence, or bounded customer follow-up.

Connect your agent See setup steps ↓
Set it up

Register Connect in Cursor’s MCP settings

Cursor can store the endpoint at project or personal scope; pick the scope intentionally.

  1. Create the mailbox in Connect

    Make the agent identity and mailbox in Stacksona Connect. Decide which contact and communication rules should govern the messages before granting send access.

  2. Choose Cursor’s configuration scope

    For a project, add a remote server to .cursor/mcp.json. For a personal setup, use Cursor’s global MCP configuration. Keep credentials and OAuth state tied to the user who authorizes the mailbox.

  3. Add the remote server

    Register stacksona-connect with the Connect endpoint as its URL. Cursor’s MCP settings can also add a remote HTTP server; save the configuration and start or reload the server.

  4. Authorize and inspect tools

    Complete the browser sign-in to Connect. Check the server and tool list in Cursor, then ask for a connection and permission check before using mailbox content.

Project configuration for Cursor

Add this server entry to the MCP configuration file for the project.

{
  "mcpServers": {
    "stacksona-connect": {
      "url": "https://connect.stacksona.com/mcp"
    }
  }
}
Provider instructionsCursor MCP documentation ↗
For coding agents with real-world communication

Give Cursor a clean boundary around email.

Cursor can use the agent mailbox to receive issue reports, draft a release note, or prepare a customer response. Connect keeps the mailbox and the email-provider account separate, then evaluates outgoing actions under your policies.

Desktop agents and cloud runs are different

Authorize the runtime that will actually run.

A local Cursor session and a Cursor cloud automation can use different identities. Set up and test authorization for the environment that will execute the work; a desktop login should not be assumed to carry into a cloud run.

Set the correct Cursor runtime before granting email access.

A shared Cursor project file should contain the endpoint, not personal authorization material. Authenticate the desktop or cloud runtime that will execute the work, and keep send access gated by Connect contacts and review rules.

Cursor’s project configuration and its runtime identity are separate parts of the setup.

Compare the available integration paths
Questions people ask about Cursor

Cursor configuration and agent runs

Can my whole team share one Cursor connection?

The project can share an MCP server configuration, but each person’s OAuth access is tied to their own Connect authorization. Do not put a user token into the shared project file.

Will Cursor automatically read and reply to messages?

Adding the MCP server makes tools available; it does not start a background job. A prompt, an automation, or your own runtime must tell Cursor when to check the inbox.

Does Cursor Cloud use my desktop connection?

Do not assume so. Cursor cloud automations run under a separate service identity and need their own supported authorization path.

Related setup guides

A shared project can describe the server while each developer keeps their own consent.

Stacksona Connect

Give Cursor a mailbox with its own rules

Set up the mailbox, configure Cursor at the right scope, and authorize the runtime that will use it.

Create an agent mailbox