Asanable has an MCP server built into it, so Claude — claude.ai, Claude Desktop, Claude Code — can answer questions about the boards: “what’s open on the AI board?”, “find the ticket about blank invoices”, “summarise the discussion on AI-42”. It is modelled on Asana’s own Claude connector.
The rule the whole system is built on: every write in Asanable is attributable to a person. An assistant that retitled a card anonymously would put a change in the history with nobody’s name against it, on a board where “who unassigned this?” is a question people actually ask.
The consent flow below is how that rule is satisfied here: it identifies every request as a real member, so what Claude writes is an ordinary action written as you — it appears with your name, fires the same automations, and notifies like anything you did yourself. Claude can post a comment, create a card or a subtask, move a card between columns, edit any field of a card, and read, create and edit the roadmaps. It can never archive or delete anything.
If what you want is a program that writes back — reacts to a card and posts its conclusion as a comment — that exists, and it is deliberately a different door: agents and the REST API. Comments from there are attributed to a named machine account rather than to a person, which is how the attribution rule is satisfied without anybody’s name being borrowed.
Which boards exist — keys, names, descriptions and column names. Start here.
search_cards
Full-text search across every board, typo-tolerant.
list_cards
Every live card on one board, in board order; optionally one column of it.
get_card
One card in full by reference (AI-42): description, dates, labels, assignee, creator, the base fields and custom fields as option names, attachment filenames.
get_attachments
One card’s files, each with a signed download URL that expires in minutes.
get_comments
One card’s comment thread, oldest first, with who said what.
add_comment
Posts a comment on a card — as the member who authorised the connection.
create_card
Creates a card on a board — as the member who authorised the connection — including its base and custom fields at birth.
create_subtask
Creates a subtask under a card — as the member who authorised the connection.
move_card
Moves a card to another column — as the member who authorised the connection, with the same automations and notifications as a move by hand.
update_card
Edits any field of a card — title, description, assignee, due date, done, the base and custom fields — as the member who authorised the connection.
list_roadmaps
Every live roadmap — one per squad board — with its board key and live item count.
get_roadmap
One squad’s roadmap in full: the ranked priority list, the "to be prioritized" lot, the done archive, each item’s six delivery steps and the custom columns.
create_roadmap_item
Adds an item to a roadmap — as the member who authorised the connection.
update_roadmap_item
Edits any field of a roadmap item — name, dates, steps, custom columns, done — as the member who authorised the connection.
Every card in every answer carries its own URL, so Claude links straight to the card rather than describing where to find it.
This is the whole setup. Nothing has to be configured in Asanable first, and there is no key to request from anyone.
In claude.ai, open Settings → Connectors and press Add custom connector. (An organisation admin can add it once for everyone from the admin settings instead.)
Name it Asanable and paste this URL:
https://asanable.accountable.eu/api/mcp
Leave the OAuth Client ID, the client secret and every advanced setting empty — the connector registers itself.
Claude sends you to Asanable’s consent page. Sign in with your work Google account if you are not already signed in, and press Allow.
Ask Claude something: “Using Asanable, what is on the AI board right now?”
If step 3 refuses you, the problem is not the connector: Asanable is invitation-only, and an account you have not been invited to cannot consent to anything. Ask a colleague for an invitation and try again.
The Allow in step 3 is OAuth 2.1 with PKCE, and the token it issues identifies you. So Claude sees exactly the boards you see, every answer is scoped to your access, and a colleague connecting the same workspace goes through their own consent and gets their own tokens. There is no workspace-wide connection and no service account.
To cut a connection off, remove the connector in claude.ai. Server-side, access tokens expire within the hour and refresh tokens within thirty days, and an admin can revoke every connection at once.
For command-line clients, where the browser consent flow is more ceremony than protection, the same endpoint has a second door that takes a secret in the path instead. An Asanable admin mints that secret and configures it; the resulting URL is a password, because anyone holding it can read every board. That door cannot write anything — it names a workspace, not a person, and every write needs an author.
Ask an admin — the exact procedure lives with them, in docs/mcp.md in the repository, and is not something this page can hand out. The consent flow above works regardless of whether the second door is switched on.
MCP Streamable HTTP, stateless, plain JSON responses. There is no SSE stream — the server never pushes — and no session id. POST /api/mcp with a bearer token; everything else politely answers 405. Discovery is at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource, which is how the connector finds the consent page without being told.
What the tools return is what any signed-in member sees: card titles, descriptions, comments and the display names of the people involved. Nothing about the workspace’s accounts, and no attachment bytes through this server — get_attachments hands out signed download links that expire in minutes, the same way the app itself serves a file.
Already a member? The same setup lives inside the app, under your avatar menu. Webhooks are the other direction — Asanable telling you when a card changed.
