Asana MCP vs Asana API - what’s best for Agentic Tool Calling

TL;DR

• Asana's V2 MCP server (GA February 4, 2026) exposes a curated tool set for search, task and project read and write, comments, status updates, and confirmation-gated previews. The REST API exposes the full Work Graph: webhooks, audit log, SCIM, batch requests, time tracking, resource allocations, and organization exports. The gap is real and it is structural, not a backlog item.
• MCP auth is OAuth only, with mandatory pre-registration of a client ID and secret. Dynamic Client Registration is not supported, access tokens expire after one hour, and tokens issued for an MCP app do not work against the REST API. Your credential model changes the moment you pick a path.
• The REST API supports four auth methods: personal access tokens (PATs), Service Accounts (Enterprise tier, super-admin only), OAuth, and OpenID Connect. PATs and Service Accounts are long-lived static bearer tokens; that is what makes headless execution possible and what makes them a liability if they leak.
• The MCP server cannot run headless. Every connecting user completes a browser-based OAuth consent flow, and the session is workspace-scoped. Background agents with no user present cannot complete that flow.
• Neither path stores, refreshes, or revokes per-user credentials for you. In a multi-tenant B2B agent that is N tokens to manage at scale. Scalekit's Asana connector resolves the per-user credential on every tool call, so the MCP vs API decision does not change your auth infrastructure.

Your agent needs to read and write Asana. Asana now ships two distinct paths: the V2 MCP server, which reached general availability on February 4, 2026, and the REST API your integrations have called for years. They cover overlapping but not identical territory. They put you on different auth paths. They make different operational demands in production. Here is the decision framework.

What's Asana MCP Server

Asana's V2 MCP Server is hosted and maintained by Asana, reachable over Streamable HTTP at https://mcp.asana.com/v2/mcp. It reached general availability on February 4, 2026, replacing the V1 beta server (https://mcp.asana.com/sse), which used Server-Sent Events and was shut down on May 11, 2026. If you are reading code or guides that still point at the /sse endpoint, they are referencing a server that no longer exists.

Authorization is OAuth only. You pre-register an MCP app in the Asana developer console to obtain a client ID and secret; Dynamic Client Registration is not supported. Tools are exposed for LLM consumption, and the authoritative, current tool list is whatever tools/list returns from the server.

What's Asana API

The Asana REST API is a versioned REST interface at https://app.asana.com/api/1.0, exposing the full Work Graph: tasks, projects, sections, portfolios, goals, custom fields, time tracking, webhooks, audit log events, SCIM, and organization exports.

Authentication runs on four methods: PATs (long-lived, attributed to the generating user), Service Accounts (Enterprise tier, created only by super admins, with full access to all org data), OAuth for multi-user apps, and OpenID Connect for sign-in. There are no LLM-specific affordances; pagination, error handling, and rate limits are yours to manage.

Resource:

• Asana's official MCP Tools Reference.
• Asana API reference & authentication docs

What your agent can actually do with Asana MCP vs API

The MCP server covers the interactive surface well: search, task and project read and write, comments, status updates, and preview tools that render a confirmation UI before committing a change. The REST API owns everything operational and administrative.

Where the gap bites

The MCP server is built for a user sitting in front of an AI client. Anything event-driven or administrative lives only in the REST API. If your agent has to react when a task changes, it needs webhooks, and the MCP server has no event subscription surface.

If it has to read audit log events for compliance, run SCIM provisioning, batch hundreds of mutations into one request, or export an organization's graph, those are REST-only. These are architectural features of the platform API, not MCP tools that ship next month.

The tool set is intentionally fluid

Asana does not publish a frozen tool count for the MCP server. The documentation directs you to the tools/list command for the canonical set and notes explicitly that tools may be added, updated, or deprecated. For a deterministic pipeline, that fluidity is something to plan around, not assume away.

The auth path each one puts you on

MCP: OAuth, per user, one-hour tokens

• The MCP server enforces OAuth with pre-registration.
• Each user who connects completes a browser-based consent flow, and the resulting access token expires after one hour, refreshed through the standard refresh-token grant.
• There is no API key option and no Service Account option on this path.
• The token is workspace-scoped: a user selects one workspace at authorization time, and every tool call in that session is bound to it.
• Working across multiple workspaces means multiple sessions.

REST API: four methods, two of them non-interactive

• PATs are long-lived and attributed to the user who generated them; actions show up in Asana as that person, which is why teams often provision a dedicated bot user for automation.
• Service Accounts are an Enterprise-tier credential, created only by super admins, with complete access to all org data including private content; they are the right fit for org-wide background jobs and are required for the Audit Log, SCIM, and organization export endpoints.

OAuth covers multi-user apps, and OIDC covers sign-in.

The wrinkle MCP introduces: token separation

One constraint catches teams off guard. Tokens issued for an MCP app work only against the MCP server, and standard API tokens work only against the REST API. This is deliberate, following MCP security guidance to contain blast radius, but it means a hybrid agent that uses MCP for interactive work and REST for webhooks needs two registered apps and two credential lifecycles per user, not one.

The identity model that follows you either way

MCP access is user-based: every action appears as the user who authorized it, bounded by that user's existing Asana permissions. The MCP token grants nothing beyond what the user already has.

That is the correct security posture, and it is also the reason a multi-user B2B agent ends up with one credential per user on the MCP path. The REST API's PAT and OAuth paths land in the same place; only the Service Account path centralizes into a single org-level credential, at the cost of acting as an admin rather than as the user.

What you own in production

On the MCP path

• Asana manages the server, the tool schemas, and the transport. You own per-user token storage, the one-hour refresh cycle, and revocation when a user disconnects.
• Enterprise and Legacy Enterprise customers can allow or block individual MCP clients through app management, which is governance you inherit rather than build, and a dependency to plan for if your agent needs to connect without admin approval.

On the REST API path

• You own the full operational surface: endpoint selection, pagination, error handling, retries, and token lifecycle.
• Rate limits are per authorization token and tier-based: 150 requests per minute on free domains, 1500 on paid, with the search endpoint capped at 60 per minute and duplication and export endpoints limited to 5 concurrent jobs per user.

There are also concurrency caps of 50 in-flight reads and 15 in-flight writes, plus a cost limiter for graph-heavy requests. An agent prepping context before every task action hits these faster than a traditional integration.

Schema drift versus versioning

MCP tool schemas change when Asana updates the hosted server, and you consume that managed contract without controlling the cadence. The REST API is versioned and changes follow a deprecation process. For a deterministic pipeline where an unexpected schema change is an incident, the versioned API is the more predictable dependency.

When to use MCP, when to use the API

Use Asana MCP when

• Your agent is interactive and user-facing: a Claude, ChatGPT, or IDE-embedded assistant where the user is present and OAuth consent is natural
• The core job is search, retrieval, task and project authoring, and status updates expressed in natural language
• You want the confirmation-gated preview tools so a human approves task and project creation before it commits
• You are validating an Asana agent concept quickly and do not want to write REST adapter code

Use the Asana REST API when

• Your agent runs headless: scheduled syncs, background scoring, digest jobs, incident automation with no user present at execution time
• You need capabilities the MCP server does not expose: webhooks, Audit Log, SCIM, batch requests, time tracking, allocations, or organization exports
• You are running high-volume work that requires explicit pagination and rate-limit control across the per-token quotas
• You need an org-level identity through a Service Account, or you are pinning to a versioned schema for a deterministic pipeline

The credential problem that exists on both paths

Both paths hand you a token, not a vault

Whether you chose MCP or REST, every user in a multi-tenant agent has their own Asana credential. Fifty customers means fifty credential lifecycles. The MCP OAuth flow gives you a one-hour access token plus a refresh token per user. The REST OAuth flow gives you an access token per user. In both cases the credential has to live somewhere encrypted, isolated per tenant, and revocable, and your agent has to detect a revoked or expired token and re-prompt rather than fail silently.

The static-token failure mode

• The REST API's PATs and Service Account tokens make headless execution possible precisely because they are long-lived and static. That is also their risk.
• A PAT generated months ago and stored in a config file stays valid after the employee who created it leaves; disabling their SSO account does not touch it.
• A leaked Service Account token exposes all org data, including private content. Long-lived static credentials are convenient until offboarding or a leak turns them into standing access nobody is tracking.

Where Scalekit fits

Scalekit's Asana connector handles the OAuth flow, per-user token storage, and the one-hour refresh cycle on the MCP and REST paths alike. The path you pick changes the token type; it does not change what you need at the credential layer. That is the same regardless of which path you build against.

Building on Asana with Scalekit

What the connector exposes

Scalekit ships an Asana connector that wraps the REST surface as discrete, LLM-ready tools your agent calls through a single ^execute_tool method: task CRUD (^{asana_task_create}, ^{asana_task_update}), search (^{asana_task_search}, ^{asana_projects_search}), comments (^{asana_story_create}), status updates (^{asana_status_update_create}), plus the surface the MCP server omits, including webhooks (^{asana_webhook_create}), time tracking, resource allocations, goals, and custom fields.

There is also an MCP-flavored variant of the connector if you want the MCP transport with Scalekit handling auth. Credentials are held in Scalekit's token vault and never touch your agent runtime or the model context.

Wiring it up

Set up the connection once in the Scalekit dashboard under Agent Auth, then resolve and execute per user. The ^{connectionName} you pass in code must match the connection name configured in the dashboard exactly; a mismatch here is the most common integration error.

If you need an endpoint the prebuilt tools do not cover, the same connection proxies raw REST calls through ^{actions.request({ connectionName, identifier, path, method })}, so you keep one auth layer across both styles.

Virtual MCP for scoped, per-user endpoints

If you want an MCP-compatible framework to connect without writing a tool-calling loop, Scalekit's Virtual MCP gives every agent role a scoped, per-user MCP endpoint. You declare one config that lists which connections and which tools are exposed, then Scalekit mints a per-user URL from it.

The agent sees only the three tools you whitelisted, not the full connector surface, and each user gets their own pre-authenticated URL of the form https://yourcompany.scalekit.com/mcp/v3/servers/<server-id>.

One config definition serves every user; the identity is resolved per run from that user's connected account. There is no MCP server for you to deploy, host, or maintain.

Observability for multi-tenant agents

Every authorization and tool call flows through Scalekit's auth logs, so you can answer the questions a security reviewer asks about a multi-tenant agent: which user authorized this Asana action, which credential executed it, and when access was granted or revoked. For an agent acting across dozens of customers, that per-user audit trail is the difference between a clean SOC 2 conversation and a three-week log investigation.

Which one to build against

• If your agent is interactive and its job is searching, reading, and authoring Asana work for a present user, the V2 MCP server is the faster path, and its preview tools give you human-in-the-loop confirmation for free.
• If your agent runs headless, reacts to changes through webhooks, reads the audit log, provisions through SCIM, or moves high volumes of records, build against the REST API directly.

Most production Asana agents will end up using both: MCP for the interactive assistant, REST for the background pipeline. The credential management problem is identical either way, and that is the part that needs production-grade infrastructure.

Next Steps:

1. Browse the Scalekit Asana connector or explore the connector page.
2. Need a tool the connector does not expose yet? Request it in the Scalekit Slack community or talk to us.