Trello MCP or CLI: How Should an AI Assistant Reach Your Board?

For an assistant you talk to, use Trello’s MCP server: Atlassian hosts it, it signs in through your browser, it is limited to one workspace and the permissions you tick, and it cannot permanently delete anything. For a job that runs the same steps every time, call the Trello REST API from a script with an API key and a token you generated with a narrow scope and an expiry. A CLI is the third option, and it suits coding agents that already work in a shell, but Atlassian does not publish one for Trello, so any Trello CLI you install is a third-party or community tool running on the same REST API and the same key and token. The real choice is about who holds the credential, how wide it is, and what the agent can reach through it.

The same question for other boards is in Linear MCP vs CLI vs API and Jira MCP vs the Jira API. Setting up the Trello server itself is covered in Trello MCP with Claude Code and Trello MCP with ChatGPT; this post does not repeat those steps.

The three routes at a glance

• MCP server: one hosted address, https://mcp.trello.com/v1, run by Atlassian. The assistant sees a short list of tools and chooses one mid-conversation. Sign-in is OAuth in the browser, and there is no other way in.
• CLI: a program on your machine that the agent runs as a shell command. It stores a Trello API key and token and calls the REST API for you, printing the answer for the agent to read.
• REST API: https://api.trello.com/1/..., called by code someone wrote and reviewed. It takes an API key plus a user token and exposes everything Trello exposes to developers, including comments, attachments and custom fields.

Route 1: the MCP server

Atlassian’s Trello MCP documentation↗ (opens in a new tab) is clear on the three things that shape this route. It uses OAuth 2.0 and does not support API token authentication for MCP connections. Each connection covers one workspace, chosen on the consent screen, with read, write and search as separate permissions. And destructive deletes are not supported: the assistant can archive cards and lists, which you can restore, but it cannot delete them.

That makes it the safest of the three by construction. You never handle a secret, the token stays with the client, the workspace boundary is enforced on Atlassian’s side, and on Trello Enterprise an admin can block the server or switch off read or write access from Atlassian Administration. The price is reach. The server does what its tools do and no more, and it acts with your Trello account, so its changes look like yours.

The tools are grouped by object, such as trelloReadCard and trelloWriteCard, with an action parameter choosing the operation. Atlassian’s repository for the server↗ (opens in a new tab) lists comments, attachments, custom fields, activity history and more than one workspace per connection as planned rather than available, so check it before you promise a colleague that the assistant can read card comments.

Route 2: a command-line tool

Atlassian has its own command-line tool, acli, but the acli command reference↗ (opens in a new tab) covers Jira, organisation administration and Rovo Dev, and lists no Trello commands. What exists for Trello is third-party: a commercial Trello CLI sold by a Marketplace vendor, and several open-source ones, some written with agents in mind and printing JSON. None is an Atlassian product, so check who maintains one, how recently it changed, and where it keeps your token before you install it.

Structurally they all work the same way. The CLI holds a Trello API key and a user token, the agent runs a command through its shell tool, the CLI calls the REST API and prints the result, and the agent reads it. Four things follow:

• The agent needs a shell. That fits Claude Code, Codex CLI and Cursor’s agent, which run commands with your approval, and rules out chat apps with no terminal.
• The credential is whatever token you gave the CLI. If you generated it from the Power-Up admin page, it can read and write your whole Trello account, not one workspace.
• Nothing narrows it further. The MCP server’s no-delete rule does not apply: if the API allows a delete and the token has write scope, the CLI can delete.
• Context is spent only on what the agent runs. It learns the commands from --help or a note in your rules file, and each call costs the command and its output.

The last point is the usual case for a CLI. The first three are the case against using one casually. If you do use one, give it a token made for it, as described next, rather than the one you use for everything else.

Route 3: the REST API with a key and token

Every Trello API call needs two values. According to Trello’s API introduction↗ (opens in a new tab), you first create a Power-Up, generate an API key on its Trello Auth tab, and then generate a token, which together with the key can read and write your entire Trello account. The key identifies the application and is not secret; the token acts as you and is.

You do not have to accept a full-account token. Trello’s authorization guide↗ (opens in a new tab) describes an authorize URL where you choose the scope, any of read, write and account, and the expiry: 1hour, 1day, 30days or never. It also recommends sending the pair in an Authorization header rather than in the query string, where it ends up in logs and shell history.

# 1. Open in a browser, approve, copy the token shown
https://trello.com/1/authorize?expiration=30days&scope=read&response_type=token&key=YOUR_API_KEY

# 2. List your boards with the key and token in a header
curl -H "Authorization: OAuth oauth_consumer_key=\"$TRELLO_KEY\", oauth_token=\"$TRELLO_TOKEN\"" \
  "https://api.trello.com/1/members/me/boards?fields=name"

Tokens you have granted are listed on your Trello account page under Applications, with their scope and expiry, and a Revoke button next to each; the API also has a /1/tokens delete action. A revoked token gets a 401 with “invalid token”. A named, scoped, expiring token per job is what makes that list readable a year from now.

Rate limits

The API’s limits are published. Trello’s rate limits page↗ (opens in a new tab) allows 300 requests per 10 seconds for each API key and 100 requests per 10 seconds for each token. Going over returns 429 with API_TOKEN_LIMIT_EXCEEDED or API_KEY_LIMIT_EXCEEDED, and headers such as x-rate-limit-api-token-remaining say how close you are. A CLI runs on a key and token, so it shares that budget with any script using the same token.

Atlassian’s MCP documentation does not publish separate limits for the server. In practice the limit an assistant meets first is its own context: reading every card on a busy board fills the conversation long before a script would hit 100 requests in 10 seconds. Ask for one list, or for counts, rather than for everything.

Which to use for which job

• Planning, triage and “what is due this week” from a chat window: the MCP server, with write left unticked until you trust it.
• A coding agent filing a card when it finds a bug and moving it when it ships: the MCP server if your client handles it well, or a CLI you trust with a token scoped to read,write that expires in 30 days.
• Anything the MCP tools do not reach yet, such as comments, attachments or custom fields: the REST API, from a script or a CLI.
• A nightly report, a bulk archive of hundreds of cards, or a sync with another system: the API from a reviewed script, with its own token and a retry that respects 429.
• A machine with no browser: the API or a CLI. Trello’s MCP server has no token route, so a person has to complete the OAuth sign-in once, as Trello MCP with Claude Code shows for a remote machine.

Whichever route you pick, start narrow. A read-only MCP connection or a scope=read token shows you what the agent does with your board before it can change anything. The wider habits are in MCP security best practices.

The same question on fenbs

fenbs has one door for assistants, and it is MCP, so the choice above collapses into two ways of signing in to the same server. A person connects an assistant with a browser sign-in and never sees the token. A script, a CI job or a client with no browser uses a token issued by hand under Settings, “Connect an AI assistant”, with a name, the scopes you tick and an optional expiry, sent as an Authorization: Bearer header. A client that speaks only stdio runs the fenbs-mcp bridge (npx -y fenbs-mcp) with that token in the FENBS_TOKEN environment variable. Either token holds your role on the board and no more, revoking it stops it at once, and every change it makes is recorded in History under the assistant’s name rather than yours alone.