I’ve organized my to-dos and projects in Trello for more than ten years, since before Atlassian acquired it. As AI became part of my workflow, I wanted it to work with the tasks already on my boards.
I started this project before the official Trello MCP server was available. The open-source options I encountered had bugs and maintenance gaps. I built trello-mcp to connect those boards to AI clients. Owning the adapter gave me control over the code and responsibility for maintaining it.
The same boards, through different clients
I use the server with ChatGPT, Claude, and Hermes. MCP, the Model Context Protocol, lets compatible AI clients discover and call tools supplied by another program. One server handles the Trello-specific operations for those clients:
The server uses its configured credentials to call Trello’s API, then returns data for the client’s answer. The implementation builds on that public API and the MCP TypeScript SDK. The project is released under the MIT license.
Trello remains the source of truth: the assistant works with the same tasks I can open and edit myself, using the server’s configured Trello account and token. Input validation cannot tell it which board I mean or what a list name signifies. It has to inspect the board and ask when the meaning is unclear.
A summary that stays close to the cards
Consider a fictional board called Home projects, where Done is the list for completed work:
Summarize unfinished work on Home projects, grouped by list. Treat cards in Done as completed. Include blockers noted in card descriptions. Do not change anything.
The instruction to make no changes does not disable the server’s write tools.
The assistant finds the board with list_boards, checks it with board_get, then fetches its lists and cards with board_lists and board_cards. Ambiguous names require clarification. Requesting the card fields name,desc,idList,url gives it titles, descriptions, list IDs, and source links; matching list IDs to names lets it group the work.
That scope excludes blockers recorded only in comments. The answer should state which cards it considered and flag possible incompleteness if it hits the requested card limit.
The Hang patio string lights card is finished but unarchived. Filtering for open cards would still include it: open means unarchived, not unfinished. The assistant needs the board’s completion convention to exclude it.
The summary could cover all three unfinished cards:
In progress
Dial in the pizza dough — Recorded: First batch tested; a longer rise is planned for the next batch. Suggested follow-up: Compare the next batch with the first.
Waiting
Build a backyard pizza oven — Recorded: Fire bricks ordered; delivery pending. Suggested follow-up: Check when the bricks will arrive before planning the build.
Host a backyard movie night — Recorded: Projector borrowed; waiting for a dry evening. Suggested follow-up: Check the forecast before choosing a date.
Scope: Three unfinished cards included; one card in Done excluded.
The delivery check is advice: the bricks could have arrived since the card was updated. The assistant can report what Trello records, with a link to check it, but cannot establish what happened elsewhere. That distinction keeps the summary useful without turning a suggestion into a fact. The workflow guide covers larger sequences.
From a summary to a change
To change a card, the client should locate the intended board, list, and card, inspect the current state, propose an exact edit, obtain the user’s approval, apply it, and read back the result to verify the intended change.
Approval is the client’s responsibility; the server does not enforce it. Valid requests can still fail, and multi-step writes can partially succeed without automatic rollback. After an interruption, inspect Trello before deciding what to retry.
Archiving the completed patio-light card would keep it recoverable; permanent deletion would not. A cleanup request should specify which is intended. The architecture guide explains these limits.
The cost of owning the connection
I deliberately run the server locally on my laptop for my ChatGPT and Claude workflows, and in Docker for Hermes. I chose this split to test both setups through my own use. The local process exchanges messages over standard input/output (stdio), with a client or intermediary; network connections use HTTP.
These setups carry different operating costs. A local process needs software and Trello credentials on that machine. A network service must also be secured and kept available. Its optional shared access token only proves that the caller knows the secret; it neither identifies individual users nor restricts individual tools. Accepted calls use the server’s Trello credentials and permissions.
Self-hosting controls where the adapter runs. Returned board content still reaches the AI client and may reach its provider. That matters when choosing which boards to expose.
Running the server also means maintaining it as Trello and clients change. Trello now has an official hosted MCP server, which is worth considering before taking on that work. For a quick edit, opening Trello directly may be enough.
The setup documentation and compatibility record cover specific connections. A successful connection or tool-discovery check does not prove that a live Trello workflow was tested. My personal use is separate from that record.
Reliable does not mean simple
The project was mostly vibe coded: AI wrote much of the implementation under my direction. I have found the server reliable and have not encountered bugs in my own use. I still think it is more complicated than necessary and could have taken less time to build.
Working software does not establish that every layer is necessary. Input validation and credential handling have clear jobs. Each additional layer deserves the same scrutiny: which requirement does it serve, and what would stop working without it? Tests can check behavior without answering that design question.