Trello Desktop MCP

by kocakli

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: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between get_board_details and trello_get_user_boards/list_boards, as well as trello_get_board_cards and trello_get_list_cards, which could cause confusion. However, descriptions help clarify their specific focuses, such as detailed board info versus user-accessible boards.
Naming Consistency2/5
Naming is inconsistent with mixed conventions: some tools use verb_noun (e.g., create_card, get_board_details), while others use trello_verb_noun (e.g., trello_add_comment, trello_create_list). This lack of a uniform pattern makes the set harder to navigate and predict.
Tool Count4/5
With 19 tools, the count is slightly high but reasonable for a Trello integration covering boards, cards, lists, members, and actions. It provides comprehensive functionality without being overwhelmingly bloated, though it could be streamlined.
Completeness5/5
The tool set offers complete CRUD/lifecycle coverage for Trello's domain, including creating, reading, updating, and moving cards, managing boards and lists, handling comments, attachments, checklists, and search. No obvious gaps are present, enabling full agent workflows.
Average 3.2/5 across 19 of 19 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'creates' without disclosing behavioral traits like required permissions, whether it's idempotent, error handling, or response format. It mentions authentication parameters are auto-provided but doesn't clarify if user intervention is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste: the first states purpose and resource, the second gives usage context. It's front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., what happens on success/failure), doesn't explain return values, and offers minimal usage guidance, leaving gaps for an AI agent.
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 no parameter-specific semantics beyond what the schema provides (e.g., no extra details on idList sourcing or pos usage), but it doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new card') and resource ('in a Trello list'), with examples of use cases ('tasks, ideas, or items to your workflow'). It distinguishes from read-only siblings like get_card but doesn't explicitly differentiate from other creation tools like trello_create_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Use this to add tasks, ideas, or items to your workflow' but offers no explicit when-to-use vs. alternatives (e.g., update_card for modifications, trello_create_list for creating lists instead of cards), prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a read operation ('Get'), it doesn't address important behavioral aspects: authentication requirements (though schema covers apiKey/token), rate limits, error conditions, what happens when includeDetails is false vs true, or the format/structure of returned information. The description is too minimal for a tool with no 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?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place - 'detailed information' sets expectations, and the list of included data types ('content, status, members, and attachments') provides useful scope without verbosity. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' actually includes beyond the listed examples, doesn't describe the response format, and provides no behavioral context about authentication, errors, or limitations. Given the complexity of retrieving card data with optional details, more comprehensive guidance is needed.
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 schema already fully documents all 4 parameters. The description mentions 'including its content, status, members, and attachments' which loosely relates to the includeDetails parameter, but doesn't add meaningful semantic context beyond what the schema provides. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific Trello card, including its content, status, members, and attachments.' It specifies the verb ('Get'), resource ('Trello card'), and scope of information returned. However, it doesn't explicitly differentiate from sibling tools like 'trello_get_card_actions' or 'trello_get_card_attachments' that retrieve more specific subsets of card data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this comprehensive card retrieval is preferable over more specific sibling tools like 'trello_get_card_actions' (for activity history) or 'trello_get_card_attachments' (just for files). There's also no mention of prerequisites like needing the card ID first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' labels, implying a read-only operation, but doesn't cover critical aspects like authentication needs (though parameters hint at API credentials), rate limits, error handling, or output format (e.g., whether it returns a list of label objects with names/colors). This leaves significant gaps for a tool with no output schema.
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 a single, efficient sentence that front-loads the core purpose ('Get all labels available on a specific Trello board') and adds value with the clarifying phrase 'for categorizing cards.' There is no wasted verbiage or redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks behavioral details (e.g., authentication, output format), usage guidelines, and fails to compensate for the absence of annotations. While concise, it doesn't provide enough context for an agent to confidently invoke the tool without external knowledge.
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 schema fully documents the three parameters (apiKey, token, boardId). The description adds no parameter-specific information beyond implying 'boardId' targets 'a specific Trello board.' This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't enhance understanding of parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all labels') and resource ('on a specific Trello board'), with the purpose of 'categorizing cards' adding useful context. It distinguishes from siblings like 'get_board_details' or 'get_card' by focusing specifically on labels, though it doesn't explicitly contrast with other label-related tools (none exist in the sibling list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for retrieving labels for categorization, it doesn't mention prerequisites (e.g., needing board access), exclusions, or comparisons to other tools like 'trello_search' that might also find labels. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves members but doesn't describe what 'members' includes (e.g., roles, permissions, user details), whether it's paginated, rate limits, authentication needs (implied by parameters but not explained), or error conditions. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 a single, efficient sentence that front-loads the core purpose ('Get all members who have access to a specific Trello board'). There is no wasted text, repetition, or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what the output contains (e.g., member details, structure), potential limitations, or error handling. While the schema covers inputs well, the overall context for an agent to use this tool effectively is insufficient.
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%, with clear documentation for all three parameters (apiKey, token, boardId). The description adds no parameter-specific information beyond implying 'boardId' is needed, which is already covered by the schema. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all members') and resource ('who have access to a specific Trello board'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'trello_get_member' (singular) and 'get_board_details', though it doesn't explicitly contrast with them. The description is specific but could be more precise about distinguishing from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing board access), compare it to similar tools like 'trello_get_member' or 'get_board_details', or indicate scenarios where this is the appropriate choice. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get all checklists and their items,' implying a read-only operation, but does not cover aspects like authentication needs (though hinted in schema), rate limits, error handling, or response format. This leaves significant gaps for a tool with no 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, response format, error cases, or usage context. For a tool with 5 parameters and complex operations like API calls, this minimal description does not provide enough context for effective use.
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 schema already documents all parameters thoroughly. The description does not add any meaning beyond the schema, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all checklists and their items for a specific Trello card,' making the purpose evident. However, it does not explicitly differentiate from siblings like 'get_card' or 'trello_get_card_attachments,' which might also retrieve card-related data, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_card' for general card info or other sibling tools. It implies usage by specifying 'for a specific Trello card' but offers no explicit context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets details' which implies a read-only operation, but doesn't mention authentication requirements (though parameters suggest it), rate limits, error conditions, or what happens with invalid member IDs. The description is minimal and lacks important behavioral context for a tool with authentication parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It could be slightly more structured by separating the 'what' from the 'includes', but it's appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (including authentication parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks guidance on usage context, behavioral details, and output format. For a tool with authentication requirements and multiple configuration options, more completeness would be expected.
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 schema already documents all 6 parameters thoroughly. The description mentions 'including their boards and profile information' which aligns with the 'boards' and 'fields' parameters, but doesn't add meaningful semantic context beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details about a specific Trello member/user'), including what information is retrieved ('boards and profile information'). It distinguishes from sibling tools like 'trello_get_board_members' (which gets members of a board) and 'trello_get_user_boards' (which gets boards for a user), but doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'trello_get_user_boards' or 'trello_get_board_members'. It mentions retrieving member details including boards, but doesn't specify scenarios where this is preferred over other tools or any prerequisites beyond the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool adds comments but doesn't disclose behavioral traits like authentication requirements (implied by apiKey/token parameters), rate limits, whether comments are editable/deletable, response format, or error handling. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently state the tool's purpose and usage examples. It's front-loaded with the core action and avoids unnecessary elaboration. Every sentence contributes value, though it could be slightly more structured with bullet points for examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 4 parameters, the description is incomplete. It covers basic purpose but lacks behavioral context (e.g., auth, side effects), response details, and error handling. For a tool that modifies data, this leaves the agent under-informed about critical operational aspects.
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 schema fully documents all 4 parameters. The description adds no parameter-specific information beyond implying 'text' is for comment content. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a comment') and target resource ('to a Trello card'), with specific examples of comment types ('notes, updates, or discussions'). It distinguishes from siblings like 'create_card' or 'update_card' by focusing on comments rather than card creation or modification. However, it doesn't explicitly differentiate from other comment-related tools (none listed in siblings).
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 provides implied usage context ('to add notes, updates, or discussions to cards') but lacks explicit guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or comparisons to sibling tools like 'trello_get_card_actions' (which might retrieve comments) are mentioned. The guidance is functional but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify authentication requirements (though schema shows apiKey/token), rate limits, pagination behavior, error conditions, or what happens when no attachments exist. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes clarifying parenthetical examples ('files, links'). Every word earns its place in this compact formulation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with good schema coverage but no output schema, the description is minimally adequate. It states what the tool does but lacks important context about return format, error handling, and differentiation from sibling tools. The absence of annotations and output schema means the description should do more to compensate.
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%, providing solid documentation for all parameters. The description adds no parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting, though the description could have explained the 'fields' parameter's purpose more clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('attachments for a specific Trello card'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'trello_get_card_actions' or 'trello_get_card_checklists' which also retrieve card-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_card' (which might include attachments) and 'trello_get_card_actions/checklists' (similar retrieval patterns), there's no indication of when this specific attachment-focused tool is preferred or necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what information is retrieved ('detailed information... including lists and cards') but doesn't disclose important behavioral aspects: authentication requirements (though the schema covers this), rate limits, whether this is a read-only operation, what happens when boardId is invalid, or response format details. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence states the core purpose, and the second provides usage context. Both sentences earn their place, though the second could be more specific. The structure is front-loaded with the main functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 100% schema coverage but no annotations and no output schema, the description provides adequate but incomplete context. It covers the tool's purpose and general use case but lacks details about authentication behavior, error conditions, rate limits, and response format. For a tool that retrieves potentially complex board data, more context about what 'detailed information' includes would be helpful, especially without an output schema.
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 schema already fully documents all parameters. The description adds minimal value beyond the schema - it mentions 'including its lists and cards' which relates to the 'includeDetails' parameter, but doesn't provide additional semantic context about when to use includeDetails=true versus false. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific Trello board, including its lists and cards.' It specifies the verb ('Get'), resource ('Trello board'), and scope ('lists and cards'). However, it doesn't explicitly differentiate from sibling tools like 'trello_get_board_cards' or 'trello_get_board_labels', which reduces clarity about when to use this comprehensive tool versus more specific ones.
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 provides some implied usage guidance with 'Useful for understanding board structure and content,' suggesting this is for comprehensive overviews. However, it doesn't explicitly state when to use this tool versus alternatives like 'trello_get_board_cards' (which might be better for just cards) or 'list_boards' (which lists multiple boards). No explicit when-not-to-use guidance or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool retrieves, not behavioral traits. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what format the data returns. The description adds minimal behavioral context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, focused sentences with zero waste. The first states the core function, the second provides usage context. However, it could be slightly more front-loaded by mentioning the filter parameter's purpose upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 4 parameters (3 required) and no output schema, the description is minimally adequate. It explains what the tool does but lacks information about return format, pagination, error handling, or relationship to sibling tools. The 100% schema coverage helps, but the description itself doesn't provide complete context for agent usage.
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%, providing complete parameter documentation. The description doesn't add any parameter semantics beyond what's in the schema - it mentions 'specific Trello board' which corresponds to boardId, but the schema already fully documents all parameters including boardId, filter options, and credential parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all lists in a specific Trello board'), and explains that lists represent workflow columns. However, it doesn't explicitly differentiate from sibling tools like 'trello_get_list_cards' or 'trello_get_board_cards', which also retrieve board-related data.
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 context by stating 'Use this to see the workflow columns', suggesting it's for viewing board structure rather than card content. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'trello_get_list_cards' or 'get_board_details', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the filtering capability, it doesn't describe important behavioral aspects like pagination behavior, rate limits, authentication requirements (beyond what's in the schema), error conditions, or what 'accessible to the user' means in practice (personal vs shared boards).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences that efficiently communicate the core functionality. The first sentence states the primary purpose, and the second adds important context about filtering. There's no wasted verbiage or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema, the description provides adequate but minimal context. It covers the basic purpose and filtering capability, but lacks details about return format, pagination, or how results are structured. Given the 3 parameters and absence of annotations/output schema, more behavioral context would be helpful.
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?
With 100% schema description coverage, the schema already documents all parameters thoroughly. The description mentions filtering by status which aligns with the 'filter' parameter, but adds no additional semantic context beyond what the schema provides. The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all Trello boards') and resource ('accessible to the user'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'trello_get_user_boards' or 'trello_search', which appear to offer similar board-related functionality.
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 provides some usage context ('to see all boards you have access to, or filter by status'), but doesn't explicitly state when to use this tool versus alternatives like 'trello_get_user_boards' or 'trello_search'. The guidance is implied rather than explicit about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'optional filtering and detailed information' but doesn't specify authentication requirements (though parameters suggest it), rate limits, pagination behavior, error conditions, or what happens when no cards exist. For a read operation with 6 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get all cards from a Trello board') followed by key capabilities. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and hints at some parameters, but doesn't address authentication needs, response format, error handling, or detailed behavioral context that would be helpful for an agent invoking this 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%, providing complete parameter documentation. The description adds marginal value by mentioning 'optional filtering' (hinting at the filter parameter) and 'detailed information like attachments and members' (referencing those parameters), but doesn't provide additional semantic context beyond what's already in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all cards') and resource ('from a Trello board'), with additional context about optional filtering and detailed information. It distinguishes from siblings like 'get_card' (single card) and 'trello_get_list_cards' (cards from a list), though it doesn't explicitly name these alternatives.
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 for retrieving cards from a board with optional details, but doesn't explicitly state when to use this versus alternatives like 'trello_get_list_cards' or 'get_card'. It mentions filtering capabilities which suggests context for when to apply filters, but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves 'activity history and comments' and is 'useful for tracking changes and discussions,' but doesn't disclose critical behavioral traits such as whether this is a read-only operation (implied by 'Get' but not explicit), authentication requirements (though parameters cover this), rate limits, pagination behavior, or what the return format looks like. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with two sentences: the first states the purpose, and the second adds context on usefulness. There's no wasted language, and it's front-loaded with the core functionality. However, it could be slightly more efficient by integrating the usefulness into the purpose statement, but it's still highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and hints at usage but lacks details on behavioral traits, return values, or error handling. With no output schema, the description should ideally explain what the tool returns (e.g., a list of actions with timestamps, comments, etc.), but it doesn't. This leaves gaps in completeness for effective agent use.
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%, meaning the input schema already documents all parameters thoroughly (e.g., 'cardId' with pattern, 'filter' with enum and default, 'limit' with range and default). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter interactions, provide examples, or clarify usage beyond the schema's details. Baseline is 3 when schema coverage is high, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get activity history and comments for a specific Trello card.' It specifies the verb ('Get') and resource ('activity history and comments for a specific Trello card'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_card' or 'trello_add_comment', which could provide overlapping or related functionality.
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 provides some implied usage guidance by stating it's 'Useful for tracking changes and discussions,' which suggests contexts where this tool is appropriate. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_card' (which might return basic card info without actions) or 'trello_add_comment' (for adding comments). No exclusions or clear alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'universal search' but doesn't disclose key traits like pagination behavior, rate limits, authentication requirements (implied by parameters), or what happens with large result sets. For an 8-parameter search tool, this is inadequate.
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 highly concise and front-loaded: two sentences with zero waste. The first sentence defines the tool's scope and action, and the second provides usage guidance, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, search functionality) and lack of annotations and output schema, the description is insufficient. It doesn't explain result formats, error handling, or performance characteristics, leaving gaps for an AI agent to invoke it correctly in varied contexts.
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 schema fully documents all 8 parameters. The description adds no parameter-specific semantics beyond implying the 'query' parameter is for 'keywords or phrases.' This meets the baseline of 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Universal search across all Trello content (boards, cards, members).' It specifies the action (search) and resources (boards, cards, members), though it doesn't explicitly differentiate from sibling tools like 'list_boards' or 'trello_get_user_boards' beyond implying broader search scope.
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 provides implied usage context with 'Use this to find specific items by keywords or phrases,' suggesting it's for keyword-based discovery. However, it doesn't explicitly state when to use this versus alternatives like 'list_boards' (for unfiltered listing) or 'trello_get_board_cards' (for board-specific retrieval), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention authentication requirements (though parameters suggest it), rate limits, pagination behavior, error conditions, or what the response looks like. For a read operation with 5 parameters and no annotations, this leaves significant gaps in understanding how the tool behaves.
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 perfectly concise - two sentences that directly state the tool's purpose and provide a helpful analogy. Every word earns its place, and the information is front-loaded with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 5 parameters, 100% schema coverage, but no annotations and no output schema, the description is minimally adequate. It states the purpose clearly but doesn't provide enough behavioral context about what to expect from the response, error handling, or operational constraints that would be needed for robust agent usage.
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 schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all cards in a specific Trello list'), and provides a helpful analogy ('tasks/items in a workflow column'). However, it doesn't explicitly differentiate from sibling tools like 'trello_get_board_cards' or 'get_card', which also retrieve cards but with different scopes.
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 context ('to see all tasks/items in a workflow column') but doesn't explicitly state when to use this tool versus alternatives like 'trello_get_board_cards' (for all cards on a board) or 'get_card' (for a single card). It mentions getting listId from 'get_lists', which is helpful but not comprehensive guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving 'all boards accessible to the current user' but doesn't specify whether this includes pagination, rate limits, authentication requirements beyond the parameters, or what the response format looks like. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
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 extremely concise with just two sentences, both of which add value. The first sentence states the core purpose, and the second provides helpful contextual framing. There's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 3 parameters and no output schema, the description provides basic purpose and context but lacks details about response format, pagination, error handling, or authentication behavior. The 100% schema coverage helps with parameters, but overall completeness is only adequate given the tool's moderate 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?
The description doesn't mention any parameters, but the input schema has 100% description coverage, thoroughly documenting all three parameters including the 'filter' enum with clear options. The baseline score of 3 is appropriate since the schema does the heavy lifting, though the description adds no additional parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all boards') and resource ('accessible to the current user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling 'list_boards' tool, which appears to serve a similar function, so it doesn't reach the highest score.
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 provides some implied context ('starting point for exploring your Trello workspace'), suggesting this is a foundational tool for initial discovery. However, it lacks explicit guidance on when to use this versus alternatives like 'list_boards' or 'trello_search', and doesn't mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a mutation operation ('Update properties'), it doesn't address important behavioral aspects like required permissions, whether changes are reversible, rate limits, error conditions, or what happens when only some parameters are provided. The description mentions changing 'status' (implied via closed/dueComplete parameters) but doesn't clarify behavioral implications.
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 efficiently structured in two sentences: the first states the core purpose, the second provides usage guidance with specific examples. Every word serves a purpose with zero wasted text, and the most important information ('Update properties of an existing Trello card') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 10 parameters, no annotations, and no output schema, the description is minimally adequate. It identifies the tool's purpose and provides some usage examples, but doesn't address behavioral aspects, error handling, or response format. The high schema coverage helps, but more behavioral context would be beneficial given this is a write operation.
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 schema already documents all 10 parameters thoroughly. The description adds marginal value by listing examples of updatable properties ('name, description, due date, or status'), but doesn't provide additional semantic context beyond what's in the parameter descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('existing Trello card'), and provides specific examples of what can be changed ('name, description, due date, or status'). It distinguishes this from create_card by specifying 'existing' card, but doesn't explicitly differentiate from move_card which also updates card properties.
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 context by stating 'Use this to change card details' and listing specific properties, but doesn't provide explicit guidance on when to choose this tool versus alternatives like move_card (which appears to specialize in card movement) or when not to use it. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It lacks details on permissions needed, rate limits, error conditions, or what happens to card data during the move, which are important for a mutation tool.
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 with zero waste: the first states the core action, the second provides usage context. It is front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is minimal but adequate. It covers purpose and basic usage but lacks behavioral details like error handling or return values, leaving gaps in completeness.
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 schema fully documents all parameters. The description adds no additional parameter semantics beyond implying 'idList' relates to workflow status, meeting the baseline 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 specific action ('Move a card') and resource ('to a different list'), with an explicit example distinguishing it from siblings like 'update_card' or 'create_card' by focusing on workflow status changes.
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 provides clear context for when to use this tool ('to change a card's workflow status'), but does not explicitly mention when not to use it or name alternatives like 'update_card' for other modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states this is a creation operation, it doesn't disclose important behavioral traits like authentication requirements (though parameters suggest them), permission needs, whether creation is idempotent, error conditions, or what happens on success. The description provides minimal behavioral context beyond the basic action.
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 perfectly concise with two sentences that each earn their place. The first states the core purpose, the second provides usage context with concrete examples. No wasted words, well-structured, and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is adequate but has clear gaps. It explains what the tool does and provides usage examples, but doesn't address behavioral aspects like authentication, permissions, error handling, or what the tool returns. The 100% schema coverage helps, but for a mutation tool, more behavioral context would be beneficial.
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 schema already documents all parameters thoroughly. The description adds minimal parameter semantics - it only mentions the 'name' parameter through examples ('"To Do", "In Progress", or "Done"'), but doesn't provide additional context beyond what's in the schema descriptions. This meets the baseline 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 specific action ('Create a new list'), resource ('in a Trello board'), and provides concrete examples of typical use cases ('workflow columns like "To Do", "In Progress", or "Done"'). It distinguishes this tool from sibling tools that create cards, get board details, or perform other Trello operations.
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 about when to use this tool ('to add workflow columns'), which implicitly distinguishes it from tools like create_card (for creating cards within lists) or get_lists (for reading lists). However, it doesn't explicitly state when NOT to use it or mention specific alternatives by name.
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-Desktop-MCP MCP server](https://glama.ai/mcp/servers/kocakli/Trello-Desktop-MCP/badges/card.svg)](https://glama.ai/mcp/servers/kocakli/Trello-Desktop-MCP)

Score Badge

Copy to your README.md:

[![Trello-Desktop-MCP MCP server](https://glama.ai/mcp/servers/kocakli/Trello-Desktop-MCP/badges/score.svg)](https://glama.ai/mcp/servers/kocakli/Trello-Desktop-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/kocakli/Trello-Desktop-MCP'

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