Using the Asana MCP Server in Cursor

To use Asana in Cursor, you connect Cursor to Asana’s official MCP server at https://mcp.asana.com/v2/mcp. Asana does not let clients register themselves during sign-in, so there is one step before the usual one: create an MCP app in Asana’s developer console with Cursor’s redirect URL, and keep its client ID and secret in environment variables. Then add the server to mcp.json with an auth block that reads those variables, select Connect, and approve in the browser. Asana also publishes a Cursor Marketplace plugin that ships the same configuration; it still needs the app and the variables.

This guide is only about Cursor. Whether Asana has an MCP server at all, the full tool list, and the setup for Claude and Claude Code are in Asana MCP with Claude. If MCP itself is new, start with what MCP is.

Step 1: create an MCP app in Asana

1. Open Asana’s developer console and choose Create new app. Name it something you will recognise later, such as “Cursor MCP”.
2. Select MCP app as the app type and create it. Note the client ID and client secret.
3. Under OAuth, add the redirect URL cursor://anysphere.cursor-mcp/oauth/callback, exactly as written: no trailing slash, and the cursor:// scheme rather than http.
4. Under Manage distribution, choose which workspaces the app may be used in. If you pick specific workspaces and select none, sign-in fails.

The requirement for a pre-registered app, the app type and the distribution settings all come from Asana’s guide to integrating with its MCP server↗ (opens in a new tab). The redirect URL is the one Asana gives for Cursor. Cursor’s own documentation lists two other fixed callback addresses, http://localhost:8787/callback for the desktop app and https://www.cursor.com/agents/mcp/oauth/callback for the web and Cloud Agents. If sign-in fails with a redirect mismatch, compare the address in the error with the one you registered.

Step 2: keep the secret out of the file

Asana asks you never to commit these credentials, to give each developer their own, and to rotate them. Put them in your shell profile, then quit Cursor completely and reopen it so it picks them up:

export ASANA_CLIENT_ID="your_client_id"
export ASANA_CLIENT_SECRET="your_client_secret"

On Windows, set them as user environment variables instead (for example with setx ASANA_CLIENT_ID "your_client_id"), then restart Cursor.

Step 3: add the server to mcp.json

Cursor reads MCP servers↗ (opens in a new tab) from ~/.cursor/mcp.json for every project and .cursor/mcp.json for one project. For a remote server that needs a fixed OAuth client, Cursor supports an auth object with CLIENT_ID and CLIENT_SECRET, and ${env:NAME} reads a value from the environment. This is the entry Asana’s client setup guide↗ (opens in a new tab) gives for Cursor:

{
  "mcpServers": {
    "asana": {
      "url": "https://mcp.asana.com/v2/mcp",
      "auth": {
        "CLIENT_ID": "${env:ASANA_CLIENT_ID}",
        "CLIENT_SECRET": "${env:ASANA_CLIENT_SECRET}"
      }
    }
  }
}

The key, asana, is the server’s name inside Cursor and reappears in approval rules below. Because the file holds only variable names, a project copy can be committed; each teammate then needs their own Asana app and variables. If you find an older guide pointing at https://mcp.asana.com/sse, that was the beta V1 server, which Asana has deprecated. Use the V2 address.

Or install Asana’s plugin

The Asana plugin on the Cursor Marketplace does step 3 for you. Its repository↗ (opens in a new tab) shows what it installs: the same mcp.json entry, skills that walk the agent through setup and troubleshooting, and an always-on rule asking the agent to confirm destructive actions such as deleting tasks. You still create the Asana app and set the two variables first. Bear in mind that the rule is an instruction to the model, not a permission; the approval settings below are what actually stop a call.

Step 4: connect and sign in

1. Open Customize in Cursor’s sidebar (in older versions, Cursor Settings, then Tools & MCP) and find asana.
2. Select Connect. Your browser opens on Asana.
3. Sign in, check which app and workspace the request names, and select Allow.
4. The browser hands you back to Cursor and the server shows as connected, with its tools listed.

What to try first

Start in Agent chat with reads, so you can see how it interprets your workspace before it changes anything:

• “Who am I signed in as in Asana, and which workspace is this?” This confirms the account and the workspace.
• “List my Asana tasks due this week, with their projects.”
• “Find the Asana project for the billing service and summarise its latest status update.”
• “Which open tasks in that project mention the payment retry bug?”

Then one write you can check by eye, ideally one that uses what Cursor is good at: “Turn the TODO comments in src/billing into Asana tasks in the Billing project, one task per TODO, with the file and line in the description.” Or, after a fix: “Mark the retry-bug task complete and comment with the commit hash.” Asana’s tools reference↗ (opens in a new tab) notes that its interactive preview tools, which show a confirmation card before creating anything, currently work in Claude and ChatGPT. In Cursor the agent uses the plain write tools, so Cursor’s approval prompt is your preview.

Permissions: keep writes on approval

Asana MCP access is user-based: everything done through it appears as you, and it cannot reach anything you cannot. It also has no scopes, so you cannot connect “read-only” on the Asana side; a connection can use every tool your account allows, including delete_task, which deletes permanently. The controls that narrow it are in Cursor.

Cursor asks before each MCP tool call by default and lets you expand the request to see its arguments. To let reads run without asking, list them in an MCP allowlist. Cursor’s permissions reference↗ (opens in a new tab) describes mcpAllowlist in permissions.json, per user in ~/.cursor/permissions.json or per project in .cursor/permissions.json, with each entry written as server:tool:

{
  "mcpAllowlist": [
    "asana:get_me",
    "asana:get_my_tasks",
    "asana:get_task",
    "asana:get_tasks",
    "asana:get_project",
    "asana:get_projects",
    "asana:search_objects"
  ]
}

Everything else, create_tasks, update_tasks, add_comment, create_project and delete_task, stays on approval. A list in the file replaces the one in Cursor’s settings, so keep all your MCP entries in one place. Never add asana:*, and avoid the Run Everything mode while Asana is connected: create_tasks and update_tasks accept up to 50 tasks in one call, which is a lot to undo.

When it does not connect

• Nothing happens on Connect, or Asana says the client is unknown: the variables are probably empty. Check them in a new terminal, then quit and reopen Cursor.
• A redirect mismatch: the registered URL must match to the character. Compare it with the address in the error.
• “This app is not available to your Asana workspace or organization”: fix the app’s distribution settings in the developer console.
• Your organisation blocks it: Asana says pre-registration lets organisations control which apps reach their data through app management, so ask your Asana admin.
• Anything else: open the Output panel, choose MCP Logs, and read the connection and authentication errors there.

Two behaviours are normal rather than broken. Asana’s access tokens expire after an hour and the client renews them with a refresh token, and full-text search_tasks works only on Premium Asana plans, so on others the agent falls back to filtering with get_tasks.

If you want a narrower seat for the agent

Asana through MCP gives Cursor’s agent all of your Asana rights in that workspace. fenbs connects to Cursor with one URL in mcp.json and a browser sign-in, with no app to register, and the approval screen lets you tick read, write and comment, so the agent can hold less than you do. Every change it makes is recorded under its own name in the board’s history. See connect Cursor to fenbs and fenbs vs Asana.