Provides comprehensive integration with Trello's API for managing boards, lists, cards, comments, and attachments, with support for search functionality and real-time CRUD operations across all Trello workspace items.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Trello MCP Server show me all my Trello boards"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides seamless integration between Claude and Trello via Nango authentication. This server enables Claude to interact with your Trello boards, lists, cards, and more through natural language commands.
Complete Trello API Coverage: Manage boards, lists, cards, comments, and attachments
Secure Authentication: Uses Nango for OAuth authentication with Trello
Real-time Operations: Create, read, update, and delete Trello items instantly
Search Functionality: Search across boards, cards, and members
Error Handling: Robust error handling with automatic credential refresh
Related MCP server: trello-mcp-server
trello_get_my_boards - Get all your boards
trello_get_board - Get specific board details
trello_create_board - Create new boards
trello_update_board - Update board information
trello_delete_board - Delete boards
trello_get_board_lists - Get all lists on a board
trello_get_board_cards - Get all cards on a board
trello_get_board_members - Get board members
trello_create_list - Create new lists
trello_update_list - Update list details
trello_archive_list - Archive lists
trello_get_list_cards - Get cards in a specific list
trello_create_card - Create new cards
trello_get_card - Get card details
trello_update_card - Update cards (including moving between lists)
trello_delete_card - Delete cards
trello_add_comment_to_card - Add comments to cards
trello_add_attachment_to_card - Add attachments to cards
trello_search - Search across Trello for boards, cards, members, etc.
Python 3.13+ installed on your system
Nango account with Trello integration configured
Trello API credentials (Client ID)
git clone <your-repo-url>
cd trello-mcpUsing UV (recommended):
uv syncOr using pip:
pip install -e .Create a .env file in the project root:
# Nango Configuration
NANGO_BASE_URL=https://api.nango.dev
NANGO_SECRET_KEY=your_nango_secret_key_here
NANGO_CONNECTION_ID=your_user_connection_id
NANGO_INTEGRATION_ID=trello
# Trello Configuration
TRELLO_CLIENT_ID=your_trello_api_key_here
# Optional: Enable debug mode
DEBUG=falseAdd the following configuration to your Claude Desktop config file:
Location of config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"trello": {
"command": "uvx",
"args": ["git+https://github.com/ampcome-mcps/trello-mcp.git"],
"env": {
"NANGO_BASE_URL": "https://api.nango.dev",
"NANGO_SECRET_KEY": "your_nango_secret_key_here",
"NANGO_CONNECTION_ID": "your_user_connection_id",
"NANGO_INTEGRATION_ID": "trello",
"TRELLO_CLIENT_ID": "your_trello_api_key_here"
}
}
}
}Sign up at Nango.dev
Create a new integration for Trello
Configure OAuth settings
Get your NANGO_SECRET_KEY from the dashboard
Set up a connection and note the NANGO_CONNECTION_ID
Go to Trello Developer Portal
Get your API Key (this becomes your TRELLO_CLIENT_ID)
Test the server directly:
uv run trello-mcpCheck Claude Desktop:
Restart Claude Desktop
Look for the Trello tools in the tool palette
Try asking: "Show me my Trello boards"
Once configured, you can interact with Trello through Claude using natural language:
"Show me all my Trello boards"
"Create a new board called 'Project Planning'"
"What lists are on my 'Work Tasks' board?"
"Add a card called 'Review PR' to the 'To Do' list"
"Move the card 'Bug Fix' from 'In Progress' to 'Done'"
"Add a comment to the card about updating documentation"
"Search for all cards containing 'urgent'"
"Create a new list called 'Blocked' on my current project board"
"Set up a new project board with lists: Backlog, To Do, In Progress, Review, Done"
"Show me all cards assigned to me across all boards"
"Archive the completed sprint list"
"Missing required environment variables" error
Ensure all required variables are set in your .env file
Check that the config in Claude Desktop matches your environment
Authentication failures
Verify your Nango integration is properly configured
Check that your Trello API key is correct
Ensure the Nango connection is active
Server not appearing in Claude
Restart Claude Desktop after configuration changes
Check the file path in the Claude config is correct
Verify the uv command is available in your PATH
Tool execution fails
Check the server logs for detailed error messages
Verify your Trello permissions allow the requested operations
Enable debug logging by setting DEBUG=true in your .env file for detailed operation logs.
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create a feature branch
Make your changes
Test thoroughly
Submit a pull request
This project is licensed under the MIT License - see the LICENSE file for details.
If you encounter any issues:
Check the troubleshooting section above
Review the MCP documentation
Check Nango documentation
Open an issue in this repository
Add an attachment to a card
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | The ID of the card | |
| url | No | URL of the attachment | |
| name | No | Name of the attachment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action but omits critical details such as required permissions, side effects (e.g., does it update the card? Is it reversible?), or API behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is appropriately concise, though it sacrifices informativeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema, the description lacks completeness. It does not explain what constitutes an attachment, whether multiple attachments can be added, or what happens when the tool succeeds or fails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (100% coverage). The description adds no extra meaning, so it meets the baseline but does not improve clarity (e.g., clarifying that url is not required but likely needed for an attachment).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource pair 'Add an attachment to a card', which is specific and unambiguous. However, it does not differentiate from sibling tools like trello_add_comment_to_card, which has a similar structure but different action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., trello_update_card for modifying card fields). The description offers no context on prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a comment to a card
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | The ID of the card | |
| text | Yes | The comment text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits such as reversibility, permissions, rate limits, or side effects. A mutation tool should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is adequate but lacks information about the return value or success indicators, which would help an agent handle the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters. The description adds no additional meaning beyond the schema, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a comment to a card' uses a specific verb ('Add') and resource ('comment to a card'), clearly distinguishing it from other tools like 'trello_add_attachment_to_card'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While the purpose is clear, there is no explicit when-to or when-not-to advice, nor mention of related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive a list
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | The ID of the list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey all behavioral traits. 'Archive a list' is vague; it does not disclose what archiving does (e.g., hides the list, moves to archive section) or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words) but lacks substance. While it is front-loaded, it is too minimal to be informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description should explain what archiving means and perhaps the result. It fails to provide this, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with list_id described as 'The ID of the list'. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Archive' and the resource 'list'. It distinguishes itself from siblings like 'update' or 'delete' by implying a specific action, but does not elaborate on what archiving entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., when to archive a list vs. close or delete it). The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new board
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the board | |
| desc | No | The description of the board | |
| defaultLists | No | Whether to create default lists |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosing behavior. It only states 'Create a new board' and does not mention side effects (e.g., whether default lists are created by default), authorization requirements, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence. However, for such a simple tool, this is acceptable and considered efficient without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema or annotations, the description is insufficient. It does not explain return values, error conditions, or the effect of optional parameters like defaultLists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all three parameters (name, desc, defaultLists) with descriptions. The description adds no additional context or semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new board' clearly states the action and resource, matching the tool name. It is specific enough to convey the primary function but does not differentiate from sibling tools like trello_create_card or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives (e.g., trello_update_board), nor does it mention any prerequisites or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new card
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the card | |
| list_id | Yes | The ID of the list | |
| desc | No | The description of the card | |
| pos | No | The position of the card (top, bottom, or number) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure, but it provides none. It does not mention whether the operation is idempotent, what authentication is required, what happens on failure, or any side effects. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) but at the cost of completeness. While it is front-loaded, it does not earn its place by providing useful context. A good description balances conciseness with informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, and 4 parameters, the description is inadequate. It does not explain the purpose of the card creation in the Trello workflow, return values, or error conditions. The agent would lack necessary context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions, achieving 100% coverage. The tool description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a generic 'Create a new card', which is a verb+resource but lacks specificity. It does not distinguish this tool from other card-related tools like trello_add_attachment_to_card or trello_update_card, nor does it mention the required board/list context. The name already implies the tool's purpose, so the description adds minimal value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing a list ID from a previous call, or when to use create_card vs update_card. The description offers no help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new list on a board
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the list | |
| board_id | Yes | The ID of the board | |
| pos | No | The position of the list (top, bottom, or number) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as required permissions, side effects, or return values. The agent has no information beyond the bare function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), but this brevity sacrifices necessary information. It is under-specified for a tool with three parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three parameters, no output schema, no annotations, many sibling tools), the description is insufficient. It fails to explain required parameters, behavior, or output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are documented in the schema with clear descriptions. The description adds no extra meaning beyond what the schema already provides, so it meets the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new list on a board', which identifies the verb and resource. It is not a tautology and differentiates from sibling tools by specifying 'list' instead of board or card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_archive_list or trello_update_list. It only states the action, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | The ID of the board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits beyond the obvious 'Delete'. It fails to mention that deletion is permanent, requires confirmation, or affects associated resources like cards and lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words), which is efficient but may omit important details. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no output schema, the description should clarify permanence and side effects. It lacks these details, leaving the agent potentially unaware of destructive consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single required parameter 'board_id' described as 'The ID of the board'. The description adds no extra meaning, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a board' clearly states the verb (delete) and resource (board), distinguishing it from siblings like trello_delete_card. However, it could be more specific (e.g., 'Permanently delete a Trello board').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description simply states the action without context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a card
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | The ID of the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Delete', which is already clear from the name. It omits critical details like irreversibility, side effects on attachments/comments, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (3 words), but conciseness should not come at the expense of missing essential information. It fails to earn its place by providing no behavioral or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and behavioral details, the description is insufficient for an agent to fully understand the tool's impact and proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter 'card_id' has a description in the schema. The tool description adds no additional parameter context, achieving the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a card' is a direct tautology of the tool name 'trello_delete_card', adding no new information about the specific resource or action beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like trello_archive_list or trello_update_card, nor any context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | The ID of the board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Get details', implying a read operation. It does not disclose permissions, idempotency, error handling, or response format, leaving the agent uninformed about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise but could perhaps include a bit more detail without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (one parameter, no output schema), the description conveys the core purpose. However, it does not hint at what board details are returned, which would help the agent know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for board_id. The tool description adds no extra parameter context beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific board' clearly specifies the action (get) and resource (board). Among sibling tools that retrieve cards, lists, or members, this uniquely identifies board-level retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like trello_get_board_cards or trello_update_board. It does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all cards on a board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | The ID of the board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It does not disclose whether the operation is read-only, any limitations like pagination or rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but lacks information about the return format, ordering, or potential limitations. It could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter that has a description. The description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 (cards), and the scope (on a board). It effectively distinguishes from sibling tools like get_card (single card) and get_list_cards (cards in a list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_list_cards, get_card). There are no when-to-use or when-not-to-use hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all lists on a board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | The ID of the board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description discloses only the basic read behavior. It does not mention whether archived lists are included, pagination, rate limits, or return format. The agent lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It could be slightly more informative, but it efficiently conveys the core purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too sparse to provide complete context. Sibling tools are many, but no differentiation is offered. The agent may miss important nuances like result ordering or scoping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'board_id' with a clear description ('The ID of the board'), and schema coverage is 100%. The description adds no additional meaning, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all lists on a board' clearly specifies the action (get), resource (lists), and context (on a board). It distinguishes this tool from siblings like trello_get_board_cards or trello_get_list_cards, though it does not elaborate on scope or filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives (e.g., trello_get_list_cards for cards within a list). There are no prerequisites or exclusions mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all members of a board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | The ID of the board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the basic action without disclosing traits like read-only nature, permissions needed, or what constitutes 'members'. The description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part is relevant and necessary for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks details about the return format, pagination, or what 'members' includes. With no output schema, the description should provide more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, with a clear description. The tool description does not add additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (all members of a board). It distinguishes from siblings like trello_get_board or trello_get_board_cards, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of prerequisites, exclusions, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific card
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | The ID of the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose what details are returned, error handling, or any side effects, which is insufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary context, making it under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain the return value but does not, leaving the tool's behavior incomplete for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('a specific card'), but does not differentiate from sibling tools like trello_get_board_cards which also retrieve card details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as when a single card is needed versus a list of cards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all cards in a list
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | The ID of the list |
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 only states 'Get all cards' without detailing pagination, rate limits, error scenarios, or return format. For a read operation, this minimal disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, fitting in a single sentence with no wasted words. It is front-loaded with the action. However, it could be slightly expanded with useful context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should hint at return values or behavioral nuances. It does not, leaving the tool's completeness lacking for an agent that needs to use the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'list_id' described as 'The ID of the list'. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 cards in a list', which is specific and distinguishes it from siblings like trello_get_board_cards (board-level) and trello_get_card (single card). It uses a specific verb-resource construct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives such as trello_get_board_cards or trello_get_card, nor does it mention any prerequisites or context. This leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all boards for the authenticated user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description describes a read-only operation implicitly. No details on rate limits, pagination, or authentication. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Front-loaded with key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or parameters, description is sufficient for a simple list operation. Could mention it returns only boards the user is a member of, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters to describe; schema coverage is 100% vacuously. Description adds nothing beyond the schema, but baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'boards' with scope 'all for authenticated user'. Distinct from sibling tools like trello_get_board (single board) and trello_create_board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for listing all boards, but no explicit when-to-use or when-not-to compared to alternatives like trello_get_board. Context is clear but lacks guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Trello for boards, cards, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query | |
| modelTypes | No | Comma-separated list of model types (boards,cards,members,organizations) | |
| boards_limit | No | Maximum number of boards to return | |
| cards_limit | No | Maximum number of cards to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states the general purpose (search) without detailing search behavior, result format, pagination, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence), but lacks structure and omits useful context; it is brief but not effectively informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should mention what the tool returns; it does not. Also, with four parameters, more contextual guidance on usage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to repeat parameter details but also adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as a search tool ('Search Trello') and distinguishes it from sibling tools that retrieve specific entities (e.g., trello_get_card, trello_get_board). However, the use of 'etc.' is vague and reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use search versus other retrieval tools, no mention of alternatives or context in which this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a board
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | The ID of the board | |
| name | No | The new name of the board | |
| desc | No | The new description of the board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It fails to mention that this is a mutating operation, whether it is idempotent, or what side effects (e.g., overwriting existing fields) occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words, which is under-specified rather than concise. It lacks any structure, such as listing updatable fields or mentioning return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not clarify what the function returns (likely the updated board) or that it modifies an existing board. This is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 extra meaning beyond what the schema already provides for board_id, name, and desc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a board' is a tautology that merely restates the tool name. It does not specify what attributes can be updated (e.g., name, description) or differentiate from sibling tools like trello_update_card or trello_update_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of prerequisites, exclusions, or context such as needing the board ID from trello_get_my_boards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a card
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | The ID of the card | |
| name | No | The new name of the card | |
| desc | No | The new description of the card | |
| idList | No | Move card to different list | |
| pos | No | The new position of the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only indicates a write operation ('update') but offers no details on authentication requirements, error handling, idempotency, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words) but lacks informative content. It is under-specified and fails to provide value, which outweighs the benefit of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, no annotations, and several sibling tools, the description is insufficient. It omits details about return values, usage examples, or any context to help an agent make an informed decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 5 parameters have descriptions), so the baseline is 3. The description adds no extra meaning beyond the schema; it merely restates the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a card' clearly states the verb and resource but is overly generic. It does not specify which aspects of a card can be updated (name, description, list, position), making it insufficient to distinguish from sibling tools like trello_update_board or trello_add_attachment_to_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Sibling tools like trello_add_attachment_to_card also update cards but have specific purposes, yet no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a list
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | The ID of the list | |
| name | No | The new name of the list | |
| pos | No | The new position of the list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral context (e.g., whether the update is destructive, if permissions are needed, or what the response contains). The description fails to disclose any traits beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words) but lacks necessary detail. It does not earn its place as it provides no information beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is far too minimal to be complete. It does not explain the effect of updating a list or any related context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no additional meaning beyond the schema, meeting the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a list' is a tautology of the tool name. It does not specify what aspects of a list can be updated (e.g., name, position), nor does it distinguish from sibling tools like 'trello_archive_list' which also modifies a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like sorting or archiving a list. 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.
Each tool has a distinct action-target combination, e.g., add_attachment vs add_comment, and get_board vs get_card. No two tools appear to do the same thing.
All tools follow a consistent verb_noun pattern with lowercase underscores. The prefix 'trello_' is used uniformly, and verbs like create/get/update/delete/archive/add are applied appropriately.
19 tools cover the core Trello entities (boards, lists, cards) with CRUD operations plus attachments, comments, archiving, search, and members. This is a well-scoped set for a project management tool.
Basic CRUD for boards, lists, and cards is present, along with attachment and comment support. However, notable gaps include no tool to move cards between lists, no delete list (only archive), and no management of labels or due dates.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
AI-native Kanban board — connect Claude to claim, work and move your tasks over MCP.
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ampcome-mcps/trello-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
