trello-mcp

by rilolabs

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action-resource pair: card CRUD (create/get/update/move/archive/unarchive), comments, labels, boards, lists, and search. Even similar tools like get_cards vs get_card vs search_cards have clear differences in scope and return shape.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern: get_*, create_card, update_card, move_card, archive_card, unarchive_card, add_comment, add_label, remove_label, list_boards. There are no mixed styles or vague verbs like 'process' or 'do_thing'.
Tool Count5/5
15 tools is at the upper end of the ideal range but well justified by the breadth of Trello operations covered: boards, lists, cards, labels, comments, search, and activity. Each tool serves a distinct purpose with no redundancy.
Completeness4/5
The card lifecycle is fully covered (create, read, update, archive/unarchive instead of permanent delete), plus labels, comments, search, and board activity. Minor gaps exist: no board or list creation/update/delete, but the server is clearly card-centric and archiving is intentionally used as a safe deletion alternative.
Average 4.4/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint false) and non-destructive (destructiveHint false). The description adds that the action is performed as the authenticated user and that comments are preserved in card history, which is useful behavioral context. It does not cover potential failures or side effects, so a 3 is appropriate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and every sentence adds value: one states the action and Markdown support, the other provides usage context and persistence. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 2 required parameters and no output schema. The description covers what it does, as whom, and when it is appropriate to use, plus the key aspect of persistence. It does not mention the return value, but given the simplicity and the presence of annotations, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (card_id and text), including a note that Markdown is supported. The description's mention of 'text is Markdown' merely restates the schema's existing description, so no additional semantics are added. With 100% coverage, the baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Post a comment on a card', which is a specific verb and resource, and clarifies it is done as the authenticated Trello user. This clearly distinguishes it from sibling tools like add_label or archive_card, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Comments are the right place for context and decisions' and notes they are preserved in card history, giving clear contextual guidance on when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false, destructiveHint=false), so the description adds meaningful behavioral detail: cards are placed at list bottom, the created card is returned with id and url, and label_ids must be ids rather than names ('names will not work'). This goes beyond the annotation safety profile without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff. It front-loads the primary purpose, then provides targeted parameter clarifications, and ends with the return value. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter create tool with no output schema, the description covers the essential aspects: purpose, placement, parameter provenance and format requirements, and the return value. It does not explicitly state that name is required, but that is obvious from the schema's required list. It is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates schema information (list_id from get_lists, desc supports Markdown, label_ids are ids) and adds a small clarification for due as 'ISO 8601 date or datetime' with a date-only example. This is helpful but not substantially beyond the schema's existing descriptions, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a card at the bottom of a list.' It clearly states the action (create), the target (a card), and the placement (bottom of a list), distinguishing it from siblings like move_card, update_card, and archive_card. The added detail that the card is placed at the bottom gives precise scope beyond the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Create a card at the bottom of a list' and gives parameter sourcing guidance ('list_id comes from get_lists', 'label_ids are label ids from get_labels'). However, it does not explicitly mention when not to use this tool or name alternatives such as update_card for modifications. Usage context is clear but exclusionary guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutation that is not destructive. The description adds the same-board constraint and position default, which are useful, but it doesn't disclose additional side effects or permission requirements. Given annotation coverage, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences deliver purpose, parameter sourcing, and optionality without extraneous words. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation with only three parameters and no nested objects, the description covers the core mechanics. It doesn't mention return behavior, but that's likely not critical for invocation; still, a bit more context on what happens after the move would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes all parameters at 100%, but the description enhances list_id by pointing to get_lists and clarifies the default value of position. This adds practical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a card to a different list on the same board, using a specific verb and resource. It distinguishes from siblings like archive_card or update_card by focusing on relocation between lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context by noting list_id comes from get_lists and position is optional, but it doesn't explicitly state when to choose this over update_card or other alternatives. No exclusionary guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value by explicitly listing what fields are returned, including 'most recent comments' indicating a limitation on comment history. It does not mention error behavior or rate limits, but for a read-only tool with annotations, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences, front-loaded with purpose, and no redundant fluff. The second sentence provides a helpful pointer for sourcing card_id without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description compensates well by enumerating the returned fields and explaining how to acquire the required parameter. It lacks explicit response structure or error details, but for a read-only tool with good annotations, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already explains card_id sources. The description repeats this same information without adding new syntactic or semantic details. Per the rubric, high schema coverage means baseline 3, and no additional compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a single card with a specific, valuable set of fields (description, labels, due date, members, checklist summaries, comments). It distinguishes from sibling tools like get_cards (plural) and search_cards by emphasizing 'a single card' and the comprehensive read content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need full details of one card. It also tells the user where to obtain card_id (get_cards, search_cards, URL). It lacks explicit exclusions or alternatives, but the sibling names and purpose clarity make usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint: false, destructiveHint: false), the description clarifies that the removal is scoped only to the card and the label persists on the board. This adds important behavioral context not present in the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the action. The extra clarifications are valuable and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter removal tool, the description covers the action, scope, and parameter sourcing. It does not discuss return values, but given no output schema and the mutation nature, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters, and the description repeats the source of label_id without adding new information. Since schema coverage is 100%, the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Detach a label from a card') and clarifies the scope (label remains on board), distinguishing it from sibling tool add_label. It is specific about the resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and notes that the label stays on the board, which helps the agent understand when to use it. However, it does not explicitly mention alternatives like add_label for the opposite operation, so it falls short of explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds meaningful context beyond annotations by specifying that only open (non-archived) lists are returned, in board order, and reveals the exact return fields (id, name, position). This directly supports correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action and immediate scope. The second sentence efficiently links to related tools and return value usage, with zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only list tool, the description is complete: it explains what is returned (id, name, position), how the parameter is obtained (list_boards), and why the output matters (for create_card/move_card). Missing an output schema is mitigated by explicitly naming the return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with board_id described as 'Board id, as returned by list_boards.' The description repeats this same information without adding new semantics. Since the schema already documents the parameter fully, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('open lists on a Trello board'), and key scope details ('non-archived', 'in board order'). It distinguishes itself from sibling tools by focusing specifically on lists and even references list_boards as the source for board_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: board_id is sourced from list_boards, and the returned list IDs are needed by create_card and move_card. While it doesn't explicitly list when not to use the tool, the guidance is concrete and implies the appropriate workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, destructiveHint), the description discloses meaningful behavior: the return format (readable line plus raw action type), ordering (newest first), default days (7), and the scope of activity types. This significantly helps the agent predict output and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, packing purpose, examples, ordering, output format, default, use case, and prerequisite into two sentences. Every clause adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately conveys what the tool returns (line per action, raw action type, newest first). It does not mention pagination or limits, but for a board-activity read tool with simple parameters, the description is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with clear descriptions (including default for days and source for board_id). The description reiterates 'days defaults to 7' and 'board_id comes from list_boards' without adding new semantic meaning, so it earns the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent board activity, listing specific action types (cards created, moved, archived, commented on) and specifies order (newest first) and output format (one readable line plus raw action type). This distinguishes it from sibling tools that fetch current board state or perform mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('good for what changed this week without diffing card state') and a prerequisite (board_id comes from list_boards). It does not explicitly name alternative tools for different needs, but the context strongly implies when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and non-destructive. The description adds valuable context about the search scope (all boards if not scoped) and the response format (up to 25 trimmed card summaries), which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear front-loaded verb and resource, followed by syntax examples, scoping behavior, and output limit. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying the output kind ('trimmed card summaries') and a count limit. It does not enumerate return fields, but given the moderate complexity and robust annotations, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters fully, so baseline is 3. The description adds meaningful semantics: it clarifies that board_id restricts the search and that query supports Trello operators, giving practical context beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Search Trello cards'), the resource, and the unique scope (full-text search across all boards or one specific board). It distinguishes itself from sibling tools like get_cards by emphasizing Trello search syntax and board-wide reach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to pass board_id to scope the search and notes the default behavior covering every board the token can see. It doesn't explicitly name alternatives or exclusions, but the search-specific phrasing makes its use case clear relative to list/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive, but the description adds valuable behavioral context: only passed fields are changed, omitted fields are untouched, and due can be null to clear. This goes beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the action and followed by precise details. Every sentence adds distinct value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter update tool with no output schema, the description combined with annotations provides sufficient guidance. It explains partial updates, due clearing, and points to alternatives. Could theoretically mention response/error conditions, but not required at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear descriptions. The description reinforces the due parameter format and null-clearing behavior, but adds little beyond the schema's own parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a card's title, description, or due date, using a specific verb and resource. It also explicitly distinguishes from sibling tools by naming move_card and archive_card for other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance: use for updating fields, use move_card to move between lists, use archive_card to archive. Also clarifies partial-update semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds key behavioral context: adding a label the card already has is a no-op error, which is not captured in annotations. It also clarifies the label must be an existing board label, not a new one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core action. Every sentence provides actionable information without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers purpose, parameter sourcing, and an important edge case. Combined with annotations, it gives an agent everything needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters fully (100% coverage). The description reinforces the label_id constraint ('label names are not accepted') and adds the consequence of a duplicate, which gives extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach an existing board label to a card') with a specific verb and object. It distinguishes from sibling tools like remove_label and create_card by specifying 'existing' label and referencing get_labels for the label_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on parameter sourcing ('label_id comes from get_labels — label names are not accepted') and warns about a common pitfall ('check get_card first if unsure'). It does not explicitly name alternatives like remove_label, but the context makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive (destructiveHint false) and writable (readOnlyHint false), but the description adds critical context: the action is reversible, preserving comments/checklists/history, and explains the server's policy of omitting delete. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: definition, behavioral detail, and usage rationale. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description fully covers what the agent needs to know: what it does, why it exists, and that it is reversible. The pointer to unarchive_card completes the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter 'card_id' with a clear description, including source hints ('from get_cards or search_cards'). The tool description itself does not add further parameter details, which is acceptable given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('archive') and resource ('card'), and clearly explains the effect: the card leaves the board view but retains comments, checklists, and history. It also distinguishes itself from the sibling tool 'unarchive_card' and notes that no delete tool exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use archiving—it is always the correct move because deletion is permanent and unrecoverable. It also highlights the alternative 'unarchive_card' for reversal, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds behavioral details beyond this: default values for include_archived and limit, case-insensitive label matching, and the trimmed return shape (id, name, list, labels, due, url, shortened description). It also points to get_card for full content. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause adds essential information: filters, source IDs, defaults, return shape, and an alternative tool. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description adequately explains the return format by listing the trimmed fields and directs users to get_card for full details with comments and checklists. Defaults and filter behavior are specified, making the tool's behavior predictable. The one omission—pagination behavior beyond the limit parameter—is acceptable for a summary list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it repeats that board_id comes from list_boards and list_id from get_lists, which are already in the schema, and adds only a minor hint that label is a name 'as shown by get_labels'. This is not enough to exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Get cards on a board' with optional filters. It distinguishes from the sibling tool get_card by noting that this returns trimmed results and that get_card provides full card details. It also differentiates from list-related tools by mentioning that board_id, list_id, and label come from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: use this for boards and optionally narrow by list or label. It names an alternative (get_card) for full card details, and it explains prerequisites by stating that board_id comes from list_boards, list_id from get_lists, and label from get_labels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral details such as output fields (id, name, colour) and the dependency on list_boards, which goes beyond the annotations. It doesn't mention pagination, but for a simple read-only list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each providing distinct value: purpose, usage guidance, and parameter source. No superfluous words, and it is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and clear annotations, the description fully covers the tool's role in the broader workflow. It tells the user what the tool returns, when to use it, and where the input comes from, making it complete for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter board_id. The description adds extra meaning by explaining that board_id comes from list_boards, reinforcing the data flow. This exceeds the baseline for fully covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists labels on a board with id, name, and colour. It distinguishes itself from siblings by explaining its role in preparing label IDs for create_card and add_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: use this tool before create_card or add_label to convert a human label name into a label id. It also notes that board_id comes from list_boards, providing a clear workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds important behavioral details: it includes archived boards and scopes visibility to the configured token. It also states the exact return fields (id, name, url, closed). This goes beyond annotations without contradicting them, though it does not mention pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both dense with information. The first sentence states action and scope; the second lists return fields and links to sibling tools. Every word earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only list tool with no parameters and no output schema. The description fully covers the scope, return value shape, and relationship to other tools. Nothing important is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description compensates by clarifying what the result set includes (all token-accessible boards, including archived) and what fields are returned, which adds useful semantics even though no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'Trello boards', and precisely scopes it as 'every Trello board the configured token can see, including archived (closed) ones'. It differentiates from sibling tools by focusing on boards and noting that returned IDs feed other tools like get_lists and get_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to 'Start here' and explains how the board IDs feed downstream tools (get_lists, get_cards, get_labels, get_board_activity). This provides clear guidance on when to use this tool as the entry point for many board-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive operation. The description adds the state-change detail ('restore to its list') and points to how archived cards are located, adding useful context beyond the annotations. It does not discuss authorization or edge cases, but these are less critical given the simple scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no filler. Every word contributes to understanding purpose, usage, or parameter sourcing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, non-destructive mutation tool with complete schema coverage and helpful annotations, the description is sufficiently complete. It covers what the tool does, when to use it, and how to find the input, all in a compact form.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes card_id as 'Archived card to restore,' providing full coverage. The description adds value by explaining how to obtain that card_id via get_cards or search_cards, which helps the agent populate the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and resource ('an archived card'), clearly distinguishing the action from siblings like archive_card. It also clarifies the outcome ('to its list'), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use the tool (to restore an archived card) and how to find the required input using get_cards with include_archived: true or search_cards. This provides concrete guidance and differentiates it from archiving and searching tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![trello-mcp MCP server](https://glama.ai/mcp/servers/rilolabs/trello-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rilolabs/trello-mcp)

Score Badge

Copy to your README.md:

[![trello-mcp MCP server](https://glama.ai/mcp/servers/rilolabs/trello-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rilolabs/trello-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rilolabs/trello-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server