API coverage
Source Snapshot
Section titled “Source Snapshot”- Official source: Trello REST API reference.
- Checked on: 2026-08-11.
- REST route prefix:
https://api.trello.com/1. Atlassian’s Trello REST reference is organized by API group rather than a named semver-style API version, so this matrix tracks the checked date and route prefix instead of a separate API version.
The checked official index contains 18 REST API groups. This audit compares those groups with all 77 tools currently registered through allTools and with the open API-roadmap issues linked below. Coverage is workflow-based: a tool may use an endpoint owned by an adjacent REST group while still contributing to the user workflow summarized in a row.
Trello’s REST API uses the term Organizations for what the Trello product commonly presents as workspaces. The MCP tools use user-facing workspace wording, but rows below explicitly call out the underlying Organizations API group where relevant.
For API groups marked partially supported, the detailed coverage section breaks the group down by endpoint family so contributors can see which subset is currently covered without treating this project as a complete Trello REST proxy.
v1.0 Scope
Section titled “v1.0 Scope”v1.0 provides broad Trello workflow coverage, not a one-to-one Trello REST proxy. Its core scope is credential diagnostics; board, workspace, member, list, and card discovery; bounded search and activity reads; board creation; common list and card creation and updates; card movement and archiving; labels; attachments; card-oriented checklists; custom field values; card membership; and comments.
v1.0 intentionally does not promise Enterprise administration, application compliance, emoji lookup, Power-Up/plugin administration, OAuth or token lifecycle management, broad board/workspace/account administration, every field-specific alias, or event receiver infrastructure. Deferred and post-v1.0 work remains explicit below and is linked to a live issue when the roadmap already tracks it.
Status Legend
Section titled “Status Legend”| Status | Meaning |
|---|---|
| ✅ Supported | The current MCP surface covers the main normal workflow for this group or endpoint family. |
| 🟡 Partially supported | The project covers useful workflows in this group or endpoint family, but intentionally omits some routes or broad admin surfaces. |
| ⏳ Deferred | No current MCP tools cover this group or endpoint family, but it fits the project if a concrete workflow is prioritized. |
| 🚫 Not planned | The group or endpoint family is outside the current personal/self-hosted scope unless a specific high-value workflow emerges. |
Coverage Matrix
Section titled “Coverage Matrix”| Trello REST API group | Status | Current MCP tool coverage | Intentionally unsupported or deferred endpoints | Rationale and follow-up |
|---|---|---|---|---|
| Actions | 🟡 Partially supported | card_actions, board_actions, list_actions, and workspace_actions list bounded resource activity histories. card_comment_add, card_comment_update, and card_comment_delete create, edit, and delete comment actions. | Direct action lookup and field reads, action-related resource reads, reactions, and the duplicate comment-text update alias are not exposed. | Activity lists use their resource groups, while comment update and deletion use Action routes. The supported workflow is activity audit plus card comments, not generic Action administration. |
| Applications | 🚫 Not planned | None. | Application compliance data from GET /applications/{key}/compliance is not exposed. | Compliance administration for a Trello application is outside this self-hosted workflow server’s scope. |
| Batch | ⏳ Deferred | None. | Batch request helpers are not exposed yet. | Batch support is useful for read-heavy workflows but should be designed around safe response validation and error mapping. Follow-up: #32. |
| Boards | 🟡 Partially supported | list_boards, board_create, board_get, board_field_get, board_actions, board_lists, board_cards, board_custom_fields, board_labels, board_members, and board_memberships. | General board/admin updates, preference mutation, viewed-state marking, deletion, board-scoped checklist enumeration, invitations, member/admin mutation, stars, Power-Up availability/enabled-state reads and deprecated enable/disable routes, tags, email/calendar keys, and exports are not exposed. | Discovery, focused reads, creation, and related-resource lookups cover normal planning workflows. Membership and safe administration work is tracked in #38. |
| Cards | 🟡 Partially supported | card_get, card_create, card_update, card_due_date_set, card_position_set, card_cover_set, card_delete, card_move, card_archive, card_board, card_list, card_labels, list_cards, board_cards, and the attachment, checklist, label, member, comment, action, and card custom field tools. | Dedicated mutations for start dates, due reminders, subscription state, and location/address fields; votes; card stickers; card pluginData; notification marking; and exhaustive aliases are not exposed. Generic card reads may still return requested fields that Trello includes. | Core card workflows are covered, including attachment-based covers. Remaining visual/sticker work is tracked in #34; bulk convenience helpers are tracked separately below. |
| Checklists | 🟡 Partially supported | card_checklists, card_checklist_create, card_checklist_update, card_checklist_delete, card_checklist_item_create, card_checklist_items, card_checklist_item_update, card_checklist_item_set_checked, card_checklist_item_move, and card_checklist_item_delete. | Direct checklist lookup and field reads, board/card relationship reads, individual check-item lookup aliases, and some equivalent route aliases are not exposed. | The public workflow is card-oriented, but it deliberately combines Card and standalone Checklist routes. An MCP bulk-item convenience helper—not a missing Trello bulk endpoint—is tracked in #137. |
| CustomFields | 🟡 Partially supported | board_custom_fields, custom_field_get, custom_field_options, card_custom_field_items, card_custom_field_set, and card_custom_field_clear. | Definition creation, update, and deletion plus option creation, single-option lookup, and deletion are not exposed. | Definition and option discovery plus card value reads and writes cover the current workflow. Card value routes belong to the Cards group; schema administration needs narrower requirements before it becomes public MCP scope. |
| Emoji | 🚫 Not planned | None. | Emoji listing from GET /emoji is not exposed. | Emoji lookup is low fit for a self-hosted Trello workflow server and can be handled by clients if needed. |
| Enterprises | 🚫 Not planned | None. | Enterprise admin, audit, membership, organization, transfer, and licensing endpoints are not exposed. | Enterprise administration is outside the current personal/self-hosted scope and would require a different permission and safety model. |
| Labels | ✅ Supported | board_labels, card_labels, label_get, label_create, label_update, label_delete, card_label_add, card_label_remove, and card_label_create_and_add. | No separate label field-update alias tool is exposed. | Core label discovery, CRUD, and card assignment workflows are covered by focused tools. |
| Lists | 🟡 Partially supported | board_lists, list_get, list_create, list_update, list_archive, list_move_to_board, list_actions, and list_cards. | Native archive-all and move-all card operations, parent-board reads, subscription updates, and exhaustive aliases are not exposed. | Normal list management is covered. Native mass-card operations are tracked in #140; an MCP list-scoped bulk-create convenience helper is tracked in #139. |
| Members | 🟡 Partially supported | auth_whoami, member_get, member_boards, member_cards, member_workspaces, board_members, board_memberships, card_members, card_member_add, card_member_remove, and search_members. | Member actions and invitations, account mutation, assets and saved searches, member-scoped notifications, token listing, and broad account administration are not exposed. | Discovery, profile reads, visible-resource lookup, and card assignment are covered. Membership/admin work is tracked in #38; notification workflows are tracked in #39. |
| Notifications | ⏳ Deferred | None. | Notification lookup and field reads, related-resource reads, read/unread mutations, and member-scoped notification listing are not exposed. | Listing is a Members route while the remaining operations belong to Notifications. Future triage support is tracked in #39. |
| Organizations | 🟡 Partially supported | Exposed as workspace tools: list_workspaces, workspace_get, workspace_boards, workspace_members, and workspace_actions. search also returns organization/workspace results. | Workspace creation/update/deletion, membership records, admin/member mutation, invitations, exports, preference mutation, tags, dedicated paid-account/admin endpoints, and organization pluginData are not exposed. | Trello’s Organizations API maps to user-facing workspaces. Discovery, metadata, boards, members, and activity are covered; membership and safe administration work is tracked in #38. |
| Plugins | 🚫 Not planned | None. | Plugin metadata/update, listing management, and member privacy-compliance endpoints are not exposed. | Power-Up/plugin-owner administration is outside the current scope. Board Power-Up enablement and card/organization pluginData are also omitted, but those routes belong to their resource groups rather than Plugins. |
| Search | ✅ Supported | search covers cards, boards, members, and organizations/workspaces with scoped fields and limits. search_members covers member lookup with optional board or workspace scope. | None currently planned. | The Trello search endpoint family is represented by focused search tools with bounded output defaults. |
| Tokens | 🟡 Partially supported | auth_token_info reads safe metadata for the configured token. auth_whoami is a companion member-identity diagnostic, not a Tokens route. | The token-member relationship, token-owned webhook listing and CRUD, and token deletion/revocation are not exposed. OAuth issuance is also outside the server and this REST group. | The server consumes one user-provided API key and token. Safe diagnostics are useful; credential lifecycle management is not part of the scope. |
| Webhooks | ⏳ Deferred | None. | Webhook create/get/update/delete and field reads, token-scoped webhook listing, receiver behavior, validation, and cleanup helpers are not exposed. | The Webhooks group has no standalone list route; listing is owned by Tokens. REST management is tracked in #42, with receiver and validation design in #43. |
Detailed Coverage By Group
Section titled “Detailed Coverage By Group”The tables below use the same status legend as the top-level matrix. They are intentionally grouped by useful endpoint families rather than listing every Trello REST route.
Actions
Section titled “Actions”| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| Resource activity history | 🟡 Partially supported | card_actions, board_actions, list_actions, workspace_actions | Direct action lookup by id and generic action field reads are not exposed. | Current tools are scoped to the resources users normally audit from MCP clients. |
| Card comments | ✅ Supported | card_comment_add, card_comment_update, card_comment_delete | The duplicate PUT /actions/{id} comment-update alias is not exposed. | Comments are Action resources: creation uses a Card route, while editing and deletion use Action routes that Trello limits to comments. |
| Action reactions and related-resource reads | ⏳ Deferred | None. | Reactions and action-related board/card/list/member reads are not exposed. | Add only when a concrete review or collaboration workflow needs them. |
Boards
Section titled “Boards”| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| Board discovery and metadata reads | ✅ Supported | list_boards, board_get, board_field_get | Exhaustive field alias tools are not exposed. | Focused field selection covers normal discovery and inspection. |
| Board metadata updates | ⏳ Deferred | None. | PUT /boards/{id} updates such as name, description, subscribed, and closed state are not exposed. | Add only when board administration workflows need explicit mutation safety. |
| Board creation | 🟡 Partially supported | board_create | Template-copy helpers, rich preference setup, and follow-up admin mutation are not exposed. | Creation defaults to private boards and supports optional workspace placement. |
| Board related resources | 🟡 Partially supported | board_lists, board_cards, board_custom_fields, board_labels, board_members, board_memberships, board_actions | Invitations, member/admin mutation, stars, Power-Up availability/enabled-state reads and deprecated enable/disable routes, tags, email/calendar keys, exports, and preference mutation are not exposed. | The covered surface supports planning, lookup, and audit workflows. Membership and safe administration work is tracked in #38. |
| Board-scoped checklists | ⏳ Deferred | None. | GET /boards/{id}/checklists is not exposed. | Checklist workflows are card-oriented; add board-level checklist enumeration only when a board audit workflow needs it. |
| Board viewed-state mutation | ⏳ Deferred | None. | POST /boards/{id}/markedAsViewed is not exposed. | This is a notification/read-state helper and should wait for a concrete triage workflow. |
| Board deletion | ⏳ Deferred | None. | Board delete helpers are not exposed. | Destructive board operations need explicit safety design before adding tools. |
| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| Card CRUD and core metadata | 🟡 Partially supported | card_get, card_create, card_update, card_delete | Dedicated mutations for start date, due reminder, subscribed state, and address/location fields plus exhaustive aliases are not exposed. | Core title, description, due date, completion, archive state, creation, reading, and explicit deletion are covered. card_get can request broader fields that Trello returns even when no focused mutation tool exists. |
| Movement, archive state, position, due date, and attachment cover | ✅ Supported | card_move, card_archive, card_position_set, card_due_date_set, card_cover_set | Solid-color and Unsplash cover modes plus exhaustive lower-level aliases are not exposed. | Cover support sets or clears an existing attachment cover and can set its size and text brightness. |
| Card relationships | ✅ Supported | card_board, card_list, card_labels, card_members | Broad relationship aliases are not exposed. | These tools support context gathering before edits or summaries. |
| Attachments | ✅ Supported | card_attachments, card_attachment_get, card_attachment_add_url, card_attachment_upload, card_attachment_delete | None for the official attachment operations. | Listing, individual lookup, URL creation, guarded server-local upload, and deletion are covered. Selecting an attachment as a cover is handled separately through card update. |
| Checklists and checklist items | 🟡 Partially supported | card_checklists, card_checklist_create, card_checklist_update, card_checklist_delete, card_checklist_item_create, card_checklist_items, card_checklist_item_update, card_checklist_item_set_checked, card_checklist_item_move, card_checklist_item_delete | Direct checklist and individual item lookup aliases plus checklist board/card relationships are not exposed. | The workflow is card-oriented but combines Card and standalone Checklist routes. An MCP bulk-item helper is tracked in #137. |
| Comments and activity | 🟡 Partially supported | card_comment_add, card_comment_update, card_comment_delete, card_actions | Generic action lookup, related-resource reads, reactions, and the duplicate comment-text update alias are not exposed. | Covers the common card review and audit path. |
| Labels, members, and custom field items | 🟡 Partially supported | card_label_add, card_label_remove, card_label_create_and_add, card_member_add, card_member_remove, card_custom_field_items, card_custom_field_set, card_custom_field_clear | Full label/admin, member/admin, and custom field definition management are handled outside the card tool family or not exposed. | Card-scoped assignment and value workflows are covered. |
Votes, card stickers, pluginData, and notification state | ⏳ Deferred | None. | Votes, card sticker placement, card pluginData, and card notification marking are not exposed. | Remaining visual and sticker workflows are tracked in #34; custom sticker image management belongs to the Members group. |
| MCP bulk card creation convenience | ⏳ Deferred | None. | There is no list_cards_bulk_create tool. | This is an MCP convenience loop over repeated card creation, not a missing Trello Batch or Cards endpoint. Follow-up: #139. |
Checklists
Section titled “Checklists”| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| Card-owned checklist lifecycle | ✅ Supported | card_checklists, card_checklist_create, card_checklist_update, card_checklist_delete | Equivalent field-specific aliases are not exposed. | Listing, creation, and deletion use Card routes; rename and position updates use the standalone Checklist route. |
| Checklist item create/read/update/move/delete | ✅ Supported | card_checklist_item_create, card_checklist_items, card_checklist_item_update, card_checklist_item_set_checked, card_checklist_item_move, card_checklist_item_delete | Direct lookup of one check item through the standalone alias is not exposed. | Creation and listing use Checklist routes, while focused mutations use Card check-item routes. |
| Checklist lookup, fields, and relationships | ⏳ Deferred | None. | Direct checklist lookup, field reads, and checklist board/card relationship reads are not exposed. | Add only if the current card-oriented collection reads are insufficient for a concrete workflow. |
| MCP bulk-item creation convenience | ⏳ Deferred | None. | There is no card_checklist_items_bulk_create tool. | Trello publishes no checklist bulk-create endpoint; #137 tracks a post-v1.0 MCP convenience helper over repeated writes. |
CustomFields
Section titled “CustomFields”| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| Definition and option reads | 🟡 Partially supported | board_custom_fields, custom_field_get, custom_field_options | Direct single-option lookup is not exposed. | Users can discover board definitions and list dropdown options before writing card values. |
| Card custom field values | ✅ Supported | card_custom_field_items, card_custom_field_set, card_custom_field_clear | The official multi-field update for one card is not exposed. | Cards owns these REST routes; the tools set or clear one validated card value at a time. |
| Definition and option management | ⏳ Deferred | None. | Definition creation/update/deletion and option creation/deletion are not exposed. | The official group has no option-update route. Schema and option mutation can affect a whole board and needs narrower requirements. |
| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| List reads and card listing | ✅ Supported | board_lists, list_get, list_cards, list_actions | Exhaustive field alias endpoints are not exposed. | Covers common list lookup, summarization, and audit workflows. |
| List relationship reads | ⏳ Deferred | None. | The parent-board relationship read GET /lists/{id}/board is not exposed as a list_board tool. | Add when list-only context needs parent-board expansion without a separate board lookup. |
| List create/update/archive/move | ✅ Supported | list_create, list_update, list_archive, list_move_to_board | Subscription helpers are not exposed. | Normal list management is covered with focused tools. |
| Native mass-card operations | ⏳ Deferred | None. | Archive-all-cards and move-all-cards are not exposed. | These broad mutations need explicit safety behavior. Follow-up: #140. |
| MCP bulk card creation convenience | ⏳ Deferred | None. | There is no list_cards_bulk_create tool. | This is a convenience loop over repeated card creation, not an omitted Trello list endpoint. Follow-up: #139. |
Members
Section titled “Members”| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| Member discovery and profile reads | ✅ Supported | auth_whoami, member_get, search_members | Account-management endpoints are not exposed. | Covers identifying the configured user and resolving collaborators. |
| Visible member resources | 🟡 Partially supported | member_boards, member_cards, member_workspaces, board_members, board_memberships | Invited board/workspace reads and broad membership/admin reads are not exposed. | Results are constrained by the configured token’s visibility. Membership and safe administration work is tracked in #38. |
| Member action history | ⏳ Deferred | None. | GET /members/{id}/actions is not exposed as a member_actions tool. | Current activity audit tools are scoped to cards, boards, lists, and workspaces. |
| Card membership assignment | ✅ Supported | card_members, card_member_add, card_member_remove | Workspace or board member/admin mutation is not exposed. | Assignment is card-scoped rather than account-administrative. |
| Member notifications | ⏳ Deferred | None. | Member-scoped notification listing and read-state workflows are not exposed. | Notification triage is tracked in #39. |
| Account assets and settings | 🚫 Not planned | None. | Avatars, custom board backgrounds, board stars, custom emoji, custom sticker images, saved searches, token listing, and broad account settings are not exposed. | These account-administration and personalization surfaces are outside the current workflow scope. |
Organizations
Section titled “Organizations”| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| Workspace discovery and metadata | ✅ Supported | list_workspaces, workspace_get | Workspace creation/update/deletion and preference mutation are not exposed. | User-facing tools call these workspaces while Trello’s API calls them Organizations. Metadata reads can include preferences; collection reads can optionally request paid-account details. |
| Workspace boards, members, and activity | 🟡 Partially supported | workspace_boards, workspace_members, workspace_actions, search | Membership record reads, admin/member mutation, invitations, exports, tags, dedicated paid-account/admin endpoints, and organization pluginData are not exposed. | Current coverage is discovery, lookup, and audit. Membership and safe administration work is tracked in #38. |
Tokens
Section titled “Tokens”| Endpoint family | Status | MCP tools | Unsupported or deferred details | Notes |
|---|---|---|---|---|
| Credential diagnostics | 🟡 Partially supported | auth_token_info, with auth_whoami as a companion Members diagnostic | The token-member relationship read GET /tokens/{token}/member is not exposed. | auth_token_info reads the configured Tokens resource without exposing the token; auth_whoami identifies the member through /members/me. |
| Token lifecycle and owned webhooks | 🚫 Not planned | None. | Token deletion/revocation and token-owned webhook listing and CRUD are not exposed. OAuth issuance is also outside the server and the Tokens REST group. | The server consumes one configured API key and token rather than managing credentials. |
Non-goals
Section titled “Non-goals”- v1.0 provides broad workflow coverage; it does not aim to be a complete or one-to-one Trello REST API proxy.
- It does not manage Trello API keys, OAuth grants, or token lifecycle beyond safe diagnostics for the configured token.
- It does not target Enterprise administration, application compliance, Power-Up/plugin administration, or broad workspace/account administration.
- It avoids large destructive or bulk mutations until they have explicit issue scope, safety behavior, and tests.
Maintenance Notes
Section titled “Maintenance Notes”- When public MCP tools are added, removed, renamed, or their key inputs change, run
corepack pnpm docs:toolsand update this matrix when the API group coverage changes. - When rechecking the official Trello REST reference, update the source snapshot date and route prefix if Atlassian changes the published route shape or introduces a new named REST API version.
- Keep workspace terminology user-facing, but reference Trello’s Organizations API group where a link or endpoint family uses that official name.
- Prefer “partially supported” when a group has useful workflow coverage but the project does not cover the full Trello endpoint family.