Loading ToolBench
Trello MCP Server with HTTP support for managing Trello boards, lists, and cards
The server defines 11 tools with consistent naming (verb_noun pattern) and readable descriptions. However, several critical quality gaps reduce the score: (1) Parameter descriptions are often minimal or missing context about constraints and valid values. For example, 'boardId' is described as 'ID of the board to read', no guidance on format or how to obtain one. (2) No output schemas are documented anywhere, the code returns JSON but LLMs cannot plan downstream calls without knowing the shape of responses. (3) Error handling exists but is generic ('Error: {message}') with no recovery guidance. (4) Some descriptions lack clarity about when to use tools vs alternatives (e.g., what distinguishes 'archive_card' from 'delete_board'?). (5) The 'update_list_name' and 'update_card_name' parameter descriptions contain typos ('New name of the card' for a list). Tool names are clear and follow action-verb conventions. Schemas are properly typed in metadata but lack descriptions of output fields. This is a C+ server: solid naming and structure, but insufficient parameter documentation and zero output schema guidance.
Add a comment to a card
Archive a card
Archive a list
Create a new card in a specific list
Create a new list in a specific board
Delete a board
List all open Trello boards
No documented output schemas. The code returns JSON structures (e.g., boards with id/name, cards with id/url/name) but LLMs cannot see the shape of responses to plan downstream tool calls. Every tool response is wrapped in a generic {content: [{type: 'text', text: JSON.stringify(...)}]}, the LLM must parse unstructured JSON from a text field, which wastes tokens and invites parsing errors.
Parameter descriptions lack constraint and format guidance. 'boardId' is described only as 'ID of the board to read', no mention of format, length, valid characters, or how to obtain one. Same for listId, cardId, listId. LLMs will guess at the format and may pass invalid values. Pattern:constrained-input requires enums or format specifications.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Move a card to a different list
Read lists and cards from a specific board
Update a card name
Update a list name
Destructive tools (delete_board, archive_card, archive_list) lack confirmation or dry-run guidance in descriptions. No mention of whether archiving is reversible or if deletion is permanent. LLMs cannot distinguish consequences and may accidentally destroy user data.
Error messages are generic and non-actionable. All handlers catch errors and return 'Error: {message}' with isError: true. No recovery guidance (e.g., 'Board not found. Try list_boards() to see available board IDs'). Per pattern:recovery-guide, errors should tell LLMs what to do next.
Typo in parameter descriptions: update_list_name has 'New name of the card' (should be 'list'). update_card_name description says 'New name of the card' which is correct but inconsistent with the pattern used elsewhere. These reduce clarity.
Ambiguous tool distinctions. 'archive_card' and 'delete_board' both remove resources, but descriptions don't clarify why to use one vs the other. Per naming rules, similar tools must have obviously distinct names/descriptions. 'archive_' vs 'delete_' helps, but descriptions should state that archiving is reversible and deletion is permanent.
No pagination support. read_board returns all open lists and cards for a board, if a board has hundreds of lists or thousands of cards, the response will be massive and blow token budgets. Per pattern:paginated-result, tools returning lists should support limit/offset and return counts.
Optional parameters not clearly marked. create_card has 'desc' as optional (default empty string) but the description does not say '(optional)'. LLMs may not realize they can omit it. Use consistent language like 'Description of the card (optional)' or mark in schema.