How We Built an MCP to Access and Manage Trello Cards Safely

The problem was not accessing Trello

Opening a Trello board is simple for a person. They find the right list, read the cards, and make the required change. The problem emerges when this process is repeated dozens of times, depends on one knowledgeable employee, or needs to feed other business workflows.

Important information becomes distributed across boards, lists, and cards. Answering an operational question requires someone to know where to look, understand how the board is organized, and manually copy the data. Creating a card, moving a request, or recording a comment also means interrupting work and navigating to the right place.

An AI agent could reduce that friction, but connecting it directly to the Trello API would introduce new risks:

• credentials could reach the client or the model;
• the agent could query a board outside its scope;
• a card could be created in the wrong list;
• a move could cross boundaries that should remain closed;
• failures and unexpected API responses could expose internal details.

The challenge was therefore not merely making the integration work. It was creating a controlled path between user intent and the operations allowed in Trello.

Why we used MCP

The Model Context Protocol (MCP) provides a standard way to expose tools to AI agents. Instead of granting generic API access, the server publishes a small catalog of actions with names, descriptions, and validated inputs.

For this integration, we created read and write tools to:

• list authorized boards;
• list open and archived lists on a board;
• search and list cards;
• create a card;
• move a card between lists;
• add a comment.

The server exposes no operation for deleting or archiving content. That omission is intentional: an integration should provide only the capabilities required by the workflow it is meant to support.

The agent now works with clear contracts. It does not construct arbitrary URLs or receive credentials to explore the API independently. It selects a tool, submits structured arguments, and receives a result constrained by what the server permits.

The allowlist is the primary boundary

The entire integration starts with an explicit list of authorized board IDs. A board that is absent from this configuration is rejected before a request reaches Trello.

The same rule applies to indirect actions. Before creating a card, the server identifies the board that owns the destination list. Before moving a card, it validates both the card's current board and the destination list's board. Before adding a comment, it verifies the board that owns the card.

This prevents a list or card identifier from becoming a shortcut around authorization. Enforcement happens on the server, close to the actual operation, and does not depend on the model remembering an instruction in its prompt.

There is also a second operational layer: the integration should use a dedicated Trello account invited only to the required boards. The account limits what the API can see, while the allowlist limits what the MCP server accepts.

Credentials stay on the server

The Trello API key and token remain in the server environment. The MCP client authenticates to an HTTPS endpoint with a separate secret and never receives the credentials used to communicate with Trello.

The endpoint validates the authorization header, restricts accepted hosts, and limits requests per address. Errors returned to the agent are normalized so that potentially sensitive messages from the external API are not forwarded.

Logs capture events and request identifiers without including tokens or the secret used to access the MCP server. The goal is to provide enough information for operation and diagnosis without turning observability into another source of exposure.

Reading every card requires more care than it seems

A board may contain active and archived cards and may exceed the size of a single API response. The listing operation therefore uses stable pagination in batches of up to one thousand cards.

Each page uses explicit ordering and the last received card as the cursor for the next page. The server also rejects repeated cards, invalid cursors, malformed responses, and cards that claim to belong to another board.

Archived lists are included because a historical card may point to a list that no longer appears in the regular view. Without this detail, historical reports and queries would be incomplete or contain unknown references.

This reveals an important lesson: integrating an API is not only about receiving an HTTP 200 response. It is about preserving completeness, ordering, and ownership across the entire dataset.

How a request is executed

When someone asks, “move the proposal card to In Progress,” the agent does not receive unrestricted permission to modify Trello. The flow remains controlled:

1. the client authenticates with the MCP server;
2. the agent queries the available boards and lists;
3. it identifies the card and destination list;
4. it calls the move tool with structured IDs;
5. the server validates the card's board and the list's board;
6. only after both checks does it call the Trello API;
7. a sanitized result is returned to the agent.

The same principle applies to card creation and comments: the model interprets intent, while conventional software controls authorization, formatting, and execution.

The problems this architecture solved

Less manual navigation. Recurring queries and changes can be requested in natural language without browsing through several boards and lists.

Less dependence on informal knowledge. Tool discovery and the authorized board catalog reduce reliance on the one person who knows where everything is stored.

Protected credentials. The Trello key and token remain in the server environment and are never sent to the agent.

Predictable scope. The allowlist defines exactly which boards can participate in the integration, including write operations.

Safer writes. Origin and destination are checked before creating, moving, or commenting, reducing changes in the wrong place.

Complete history. Pagination and archived content support more reliable operational queries.

Reusable integration. Any MCP-compatible client can discover and use the same tools through a standardized contract.

Deliberate limits of the first version

The first version was designed for a private operation: one Trello account, one server instance, and sessions stored in memory. This simplifies deployment, but requires a single replica and means sessions must be recreated after a deployment.

It is not a substitute for a multi-tenant platform. A service offered to multiple customers would require per-user OAuth, tenant isolation, shared session storage, more granular permissions, and a persistent audit trail.

Making these limits explicit prevents a solution designed for a private context from being promoted, unchanged, into an architecture it does not yet support.

The main lesson

Connecting an agent to Trello is the easy part. The engineering work lies in defining what it can see, which actions it may perform, and which validations remain mandatory regardless of the model's behavior.

MCP became a clear boundary between natural language and operations. AI received useful tools to access and manage cards, while credentials, authorization, and critical rules remained under deterministic control.

That is the pattern that makes agents genuinely useful in daily work: not unrestricted access, but small, explicit, and verifiable capabilities.