Enables reading and managing Trello boards, lists, and cards: list boards/lists/cards, fetch full card details (description, checklists with item ids and states, members, labels, attachments, comments), search cards across boards with Trello search syntax, tick or untick checklist items, post comments on cards, and move cards between lists. Card arguments accept an id, short link, or full card URL.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@trello-mcp Read this Trello card and tick off the checklist items I've finished: https://trello.com/c/abc123"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small Model Context Protocol server for Trello. It lets Claude Code (or any MCP client) read the cards a customer writes for you, tick checklist items and leave comments, without leaving the editor.
Built for a real workflow: the product owner on my current project files every round of feedback as a Trello card with a checklist. With this server the assistant reads the card, works through the items and ticks them off as each one lands.
Tool | What it does |
| Open boards for the token's user |
| Lists (columns) on a board |
| Open cards on a board or in one list |
| Full card: description, checklists with item ids and states, members, labels, attachments, comments |
| Trello search across boards ( |
| Tick / untick a checklist item |
| Post a comment on a card |
| Move a card to another list |
Card arguments accept an id, a short link, or the full card URL, so you can paste a link straight from Trello.
Read tools are annotated readOnlyHint: true; the three write tools are not, so clients can ask before running them.
Related MCP server: Trello MCP server
Get an API key and token: https://trello.com/power-ups/admin → your Power-Up → API key → "Token".
Build:
npm install
npm run buildRegister with Claude Code (user scope, so it works in every project):
claude mcp add trello --scope user \
-e TRELLO_API_KEY=your_key -e TRELLO_TOKEN=your_token \
-- node /absolute/path/to/trello-mcp/dist/index.jsOr by hand in ~/.claude.json:
{
"mcpServers": {
"trello": {
"command": "node",
"args": ["/absolute/path/to/trello-mcp/dist/index.js"],
"env": { "TRELLO_API_KEY": "your_key", "TRELLO_TOKEN": "your_token" }
}
}
}npm test # vitest, no network: the Trello client takes an injected fetch
npm run typecheck
npm run dev # runs the server over stdio with tsxThe code is split so the interesting parts are testable without a server:
src/trello.ts — typed client over the REST API, URL/short-link parsing, error mapping
src/format.ts — renders cards as compact markdown for the model (ids stay visible for follow-up calls)
src/tools.ts — tool definitions with zod input schemas and handlers
src/index.ts — MCP wiring over stdio
Everything runs as the token's user: comments and ticks show up under your name in Trello.
stdout is the MCP channel; the server writes diagnostics to stderr only.
Trello rate limits: 300 requests per 10 s per key, 100 per 10 s per token. Normal use is far below that.
Post a comment on a card as the token's user.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Comment text, markdown allowed | |
| cardId | Yes | Card id, short link, or the full card URL (https://trello.com/c/...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the write/non-destructive nature is covered. The description usefully adds that the comment is attributed to the token's user, but says nothing about required board/card permissions, whether the comment can be edited or deleted later, or failure behavior on inaccessible cards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the essential action and actor front-loaded and no filler. It is efficient, though its brevity is partly the reason usage guidance is absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, non-destructive write tool with a fully covered schema and no output schema, the description covers the core action and authorship context. Minor gaps around permission prerequisites and error behavior keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented there (text allows markdown, cardId accepts a short link or full URL), so the description adds nothing beyond it. Per the baseline rule for high coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (post) and resource (a comment on a card), and clarifies the authorship model ('as the token's user'), which no sibling tool covers. It does not explicitly contrast itself with siblings like trello_get_card or trello_set_checklist_item, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use statement, no prerequisites, and no mention of alternatives or when this is the wrong tool (e.g., versus adding a checklist item). The intent is inferable from the verb, but nothing in the text explicitly guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full card: description, checklists with item ids and states, members, labels, attachments and comments.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | Card id, short link, or the full card URL (https://trello.com/c/...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful return-content context by listing the included sections (checklists, members, labels, attachments, comments), which is valuable because no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence front-loads 'Full card' and lists the relevant returned sections without filler. It is appropriately sized for a one-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full parameter documentation and read-only annotations, the description gives enough return-field context to set expectations. The main omission is sibling selection guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the sole cardId parameter already documents accepted forms including card id, short link, and full URL. The description adds no parameter semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and name state 'Get card,' and the description enumerates the full card payload, making the resource and returned scope clear. It stops short of explicitly distinguishing this from siblings like trello_search_cards or trello_list_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not say when to call this tool versus trello_list_cards or trello_search_cards. 'Full card' hints at detailed retrieval, but selection guidance is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the open boards the current user can see, with ids for the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing two real behavioral constraints: results are limited to open (not archived/closed) boards, and results are permission-scoped to what the current user can see.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and scope, then tacks on the output-value note. There is no filler, no restatement of the tool name, and every clause carries information an agent can use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and annotations covering the safety profile, the description is nearly complete. It hints at the return shape ('ids') but does not mention pagination, result limits, or whether closed boards are reachable anywhere, which would matter for an agent planning around large accounts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 per the rubric and there is nothing for the description to compensate for. No parameter syntax exists that could be misused.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('List the open boards') and narrows scope with two qualifiers: only open boards, and only those the current user can see. The resource alone cleanly separates it from siblings like trello_list_lists, trello_list_cards, and trello_search_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause 'with ids for the other tools' implies this is the id-source entry point for downstream operations, which is useful implied usage. However, it never explicitly states when to use this instead of alternatives such as trello_search_cards, and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open cards on a board or in one list. Pass listId to narrow to a column, otherwise boardId for the whole board.
| Name | Required | Description | Default |
|---|---|---|---|
| listId | No | List id; takes precedence over boardId | |
| boardId | No | Board id, short link, or URL |
List the open lists (columns) of a board.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | Board id, short link, or board URL (https://trello.com/b/...) |
Move a card to another list on the same board. List ids come from trello_list_lists.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | Card id, short link, or the full card URL (https://trello.com/c/...) | |
| listId | Yes | Target list id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is covered. The description adds one useful constraint the annotations do not carry — that the destination must be on the same board — but says nothing about side effects such as the card's resulting position or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the core action and the board constraint front-loaded before the id-source hint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation with no output schema and no nested objects, the description plus annotations cover what an agent needs to invoke it correctly. The only mild gap is not stating the card's resulting position in the target list, which is minor at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with cardId documenting id/short-link/URL forms and listId documented as the target list. The description only adds the provenance of listId ('from trello_list_lists'), which is marginal on top of a fully documented schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Move'), resource ('card'), destination ('another list'), and a scoping constraint ('on the same board'). No sibling in the list moves cards, so the operation is unambiguous without consulting any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It routes the agent to trello_list_lists for the required listId and implicitly excludes cross-board moves via 'on the same board'. It stops short of an explicit when-not statement (e.g., how to move between boards), but the operative context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cards across all boards. Supports Trello search operators, e.g. 'board:Project is:open @me label:bug'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 20 | |
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context by stating that search spans all boards and supports Trello search operators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is two sentences, front-loaded with the main action and scope. Every sentence adds useful information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with complete schema coverage and safety annotations, the description provides enough scope, syntax guidance, and example usage. No output schema explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter documentation is already strong. The description adds meaningful semantics for the query parameter by explaining Trello operator syntax and giving an example beyond the schema's generic 'Search query' label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Search cards across all boards.' It also distinguishes this from the sibling list operations by emphasizing board-wide search and Trello operator support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when this tool applies: searching cards across all boards with query operators. It provides a concrete example query, though it does not explicitly say when to prefer trello_list_cards instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a checklist item complete or incomplete. Item ids come from trello_get_card.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| cardId | Yes | Card id, short link, or the full card URL (https://trello.com/c/...) | |
| checkItemId | Yes | Checklist item id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write. The description adds the id-provenance routing detail, but says nothing about auth requirements, whether the change is reversible, or what a successful mutation returns — reasonable extra context but not rich disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, the action stated first and the id-provenance prerequisite second. No filler, no restatement of the tool name, nothing wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation with annotations and no output schema, the description covers the action and the key parameter provenance. It omits what a caller should expect back after ticking an item (e.g. updated checklist state) and any permission/error context, leaving noticeable holes for a write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (in the middle band), and the schema already explains cardId formats and constrains state via enum. The description adds real value by clarifying where checkItemId comes from (trello_get_card) and paraphrasing state. That is meaningful but not compensating for the remaining undocumented surface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Mark a checklist item complete or incomplete'), so the action is unambiguous. It also names the sibling that supplies the required identifier ('Item ids come from trello_get_card'), giving partial sibling orientation, but it does not contrast itself with any alternative tool the way a 5 would.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The prerequisite for checkItemId (obtain it via trello_get_card) is implied, and 'complete or incomplete' frames the two cases. However, there is no explicit when-to-use/when-not guidance, no note about required permissions, and no alternative tool named for other checklist operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0trello_add_commenttrello_get_cardtrello_list_boardstrello_list_cardstrello_list_liststrello_move_cardtrello_search_cardstrello_set_checklist_itemAI-native Kanban board — connect Claude to claim, work and move your tasks over MCP.
Remote MCP for Kanban AI boards—manage projects, tasks, and comments from AI tools.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
