Trello MCP has expanded from a small set of board and card actions into a broader tool surface that maps the official Trello REST API into explicit MCP tools. This gives AI clients a richer way to inspect and operate Trello while preserving token permissions and board scoping.
What changed in the MCP surface
The original MCP surface focused on common workflows: list boards, read a board, create cards, move cards, add comments, and rename or archive items. Those shortcuts remain available because they are easy for agents and humans to remember.
The new layer adds explicit generated tools for the official Trello REST API. An assistant can discover the catalog, inspect a specific operation, and then call a named tool that maps to the underlying Trello route.
- 256 Trello API operations exposed as MCP tools.
- Discovery tools for searching and describing operations.
- Curated shortcuts preserved for everyday board workflows.
- Dedicated member assignment tools for cards.
Member assignment becomes a first-class workflow
Ownership is one of the most important fields on a Trello card. With member operations exposed, an assistant can list board members, inspect the members already assigned to a card, assign a member, or remove a member when work changes hands.
This is useful for project management, support queues, content production, and engineering workflows where cards should not sit unowned. The assistant can now help find cards without owners and apply the assignment after a human confirms the target member.
Beyond basic card actions
Fuller API coverage unlocks workflows that were awkward with only basic card tools. Agents can work with labels, checklists, custom fields, notifications, webhooks, organizations, members, and other Trello resources when the user's token allows it.
This does not mean every workflow should become automated. It means the MCP server can expose the same operational vocabulary Trello exposes, while the client and user decide which actions belong in a safe workflow.
- Use labels and checklists for richer triage.
- Read members and organizations for reporting context.
- Use webhooks for integration-aware workflows.
- Inspect custom fields when boards use structured metadata.
Guardrails still matter
A larger tool surface needs clearer guardrails. Read operations can work with read tokens, while write operations require read/write tokens. Destructive operations require explicit confirmation, and board-scoped tokens are checked before the server executes an operation.
The practical rollout path is still incremental: start with discovery and read-only inspection, then add targeted write actions such as card creation, member assignment, or comments after the team trusts the workflow.