Allows interaction with Trello boards, lists, and cards, providing tools for task management (create, read, update, delete), intelligent task analysis (complexity detection, vague task detection, automatic splitting), board-wide analysis with focused reporting, batch operations, natural language due dates, priority management, and status tracking mapped to Trello lists.
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 create a high-priority task for user authentication due next week"
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 integrates Trello with Claude Code, providing advanced project planning and task management capabilities with intelligent task analysis.
Create, read, update, and delete tasks across Trello boards and lists
Automatic board setup with standard lists (To Do, In Progress, Done)
Priority management with visual indicators
Due date handling with natural language support ("tomorrow", "next week")
Status tracking that maps to Trello list positions
Complexity assessment (simple/moderate/complex) based on content analysis
Vague task detection using natural language processing
Automatic task splitting for overly complex tasks
Clarity validation with generated clarifying questions
Board-wide analysis with focused reporting
Batch operations for efficient task management
Natural language due dates (today, tomorrow, next week)
Priority-based task organization
Comprehensive task filtering by status, priority, or due date
Real-time task intelligence during creation
Related MCP server: Trello MCP Server
Clone and setup the project:
git clone <repository-url>
cd trello-mcp-server
npm installConfigure Trello API credentials:
Copy .env.example to .env
Get your Trello API key from: https://trello.com/app-key
Generate an API token by visiting: https://trello.com/1/authorize?expiration=never&scope=read,write&response_type=token&name=Claude%20Code%20MCP&key=YOUR_API_KEY
Update .env with your credentials:
TRELLO_API_KEY=your_api_key_here
TRELLO_API_TOKEN=your_api_token_here
DEFAULT_TRELLO_BOARD_ID=optional_default_board_idBuild the server:
npm run buildCreate .mcp.json in your project root:
{
"mcpServers": {
"trello": {
"command": "node",
"args": ["/path/to/trello-mcp-server/build/index.js"],
"env": {
"TRELLO_API_KEY": "your_api_key",
"TRELLO_API_TOKEN": "your_api_token",
"DEFAULT_TRELLO_BOARD_ID": "your_default_board_id"
}
}
}
}Add to your Claude Code configuration:
claude mcp add-json '{
"command": "node",
"args": ["/path/to/trello-mcp-server/build/index.js"],
"env": {
"TRELLO_API_KEY": "your_api_key",
"TRELLO_API_TOKEN": "your_api_token"
}
}'// List available boards
await trello_list_boards();
// Setup a board with default lists
await trello_setup_board({ boardId: "board_id" });
// Create a task with intelligence
await trello_create_task({
boardId: "board_id",
title: "Implement user authentication",
description: "Create login/logout functionality with JWT tokens",
priority: "high",
dueDate: "next week"
});
// Update task status (automatically moves between lists)
await trello_update_task({
cardId: "card_id",
status: "in_progress"
});// Analyze entire board for improvements
await trello_analyze_board({
boardId: "board_id",
focusArea: "vague" // or "complex", "overdue", "all"
});
// Get clarifying questions for a vague task
await trello_clarify_task({
cardId: "card_id"
});
// Split a complex task into smaller ones
await trello_split_task({
cardId: "card_id",
autoCreate: true // Automatically create the suggested splits
});// Get tasks by status
await trello_get_tasks({
boardId: "board_id",
status: "in_progress"
});
// Get tasks from specific list
await trello_get_tasks({
boardId: "board_id",
listName: "To Do"
});Tool | Description | Key Parameters |
| List all accessible boards | - |
| Get board details with statistics |
|
| Create task with intelligence |
|
| Update task or change status |
|
| Analyze board for improvements |
|
| Split complex tasks |
|
| Generate clarifying questions |
|
| Filter and retrieve tasks |
|
| Setup default task management lists |
|
The system automatically identifies task complexity based on:
Content length and sentence structure
Technical keywords (API, database, authentication, etc.)
Multiple action verbs indicating compound tasks
Implementation complexity indicators
Automatically flags tasks containing:
Unclear language ("somehow", "figure out", "handle", etc.)
Missing acceptance criteria
Ambiguous requirements
Incomplete implementation details
Intelligently suggests task splits based on:
Natural language conjunctions ("and", "or")
Comma-separated requirements
Complex implementation patterns
Standard development phases (planning, implementation, testing)
npm run dev # Watches for changes and rebuildsnpx @modelcontextprotocol/inspector build/index.jsTRELLO_API_KEY - Your Trello API key (required)
TRELLO_API_TOKEN - Your Trello API token (required)
DEFAULT_TRELLO_BOARD_ID - Default board for operations (optional)
TrelloClient: Core API wrapper with full CRUD operations
TaskAnalyzer: Natural language processing for task intelligence
MCP Server: Protocol implementation with comprehensive tool handlers
Claude Code → MCP Client → Trello MCP Server → Trello REST API → Trello BoardsPending → "To Do" list
In Progress → "In Progress" list
Completed → "Done" list
Fork the repository
Create a feature branch
Add tests for new functionality
Submit a pull request
MIT License - see LICENSE file for details.
For issues and feature requests, please open an issue on GitHub or refer to the Trello API documentation for API-related questions.
Analyze all tasks on a board for complexity, clarity, and potential improvements
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The ID of the board to analyze | |
| focusArea | No | Specific area to focus analysis on | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool modifies data, requires authentication, or has performance implications. 'Analyze' suggests read-only but this is not explicitly confirmed.
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 12-word sentence, which is concise but lacks structure and omits critical details such as usage guidelines and output format. It is minimal rather than efficiently 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 explain what the analysis returns (e.g., complexity scores, list of vague tasks). It only mentions analysis dimensions but not the format or structure of results, leaving agents to infer details.
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%; both parameters have clear descriptions in the schema (boardId: 'The ID of the board to analyze', focusArea: enum with default). The tool description adds no extra meaning beyond the schema, so baseline score 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 'Analyze all tasks on a board for complexity, clarity, and potential improvements' clearly states the specific action (analyzing tasks), the resource (board), and the analysis dimensions. It distinguishes from siblings like trello_get_tasks (which lists tasks) and trello_clarify_task (which clarifies a single task).
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 implies usage when an overall board analysis is needed, but provides no explicit guidance on when to use this tool versus alternatives (e.g., trello_get_tasks for raw data). No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a vague task and generate clarifying questions to improve it
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The ID of the card to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It fails to state whether the tool is read-only or modifies the card, and omits prerequisites like card existence.
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 with no wasted words, efficiently conveying the core purpose.
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 one parameter, no output schema, and no annotations, the description is too sparse. It lacks details on behavioral effects, output format, and prerequisites.
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% with cardId documented. The tool description adds no further semantics 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 states the action ('analyze', 'generate clarifying questions') and the target resource ('vague task'), effectively distinguishing it from siblings like trello_split_task or trello_update_task.
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 implies use when a task is vague and needs clarification, but it does not explicitly exclude scenarios or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task (card) in a Trello list with task management features
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The ID of the board | |
| listName | No | Name of the list (To Do, In Progress, Done) or list ID | To Do |
| title | Yes | Title of the task | |
| description | No | Detailed description of the task | |
| priority | No | Priority level of the task | |
| dueDate | No | Due date in ISO format (YYYY-MM-DD) or relative (e.g., "tomorrow", "next week") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only says 'create' which implies mutation, but no details on permissions, side effects, or behavior beyond creation.
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, front-loaded with key function. No wasted words, but could include more context without being too long.
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 100% schema coverage, the description lacks context on return values, error handling, or behavioral specifics. A creation tool should provide more 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 schema already documents parameters. The description adds no additional meaning beyond the schema; 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 clearly states the action ('Create'), the object ('a new task (card)'), and the location ('in a Trello list'). It distinguishes from sibling tools like trello_update_task or trello_get_tasks by focusing on creation.
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, no prerequisites or exclusions mentioned. Phrases like 'task management features' are vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific Trello board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The ID of the board to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states 'Get information', implying a read operation, but does not confirm read-only nature, error handling (e.g., invalid boardId), or any side effects. This is minimal transparency.
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 that front-loads the verb and resource, making it efficient. It earns its place with no extraneous 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?
For a simple retrieval tool with one parameter and no output schema, the description is adequate but fails to indicate the nature of the returned information (e.g., board name, lists, etc.) or any limitations.
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 already describes the sole parameter 'boardId' as 'The ID of the board to retrieve'. The description adds no additional meaning. With 100% schema coverage, baseline 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 clearly states the action ('Get') and resource ('a specific Trello board'), and the inclusion of 'specific' implicitly differentiates it from sibling tool 'trello_list_boards' which lists all boards. However, it does not explicitly contrast with other siblings like 'trello_analyze_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 or any prerequisites. The description lacks context such as 'Use to retrieve board details after obtaining a board ID from trello_list_boards'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all tasks from a board or specific list with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The ID of the board | |
| listName | No | Filter by specific list name (optional) | |
| status | No | Filter by task status | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies a read-only operation ('get all tasks') and mentions filtering options. However, it omits potential behavioral traits like pagination, rate limits, or performance impact for large boards.
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?
A single sentence of 12 words conveys the essential function without unnecessary elaboration. The key verb ('get') and resource ('tasks') are front-loaded, making it easy to parse.
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, the description is adequate but minimal. It does not address return format, error handling, or edge cases, which would be valuable for a retrieval tool of this complexity.
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 100% of parameters with descriptions, so the baseline is 3. The description adds no additional meaning beyond what is already in the schema, simply summarizing the filtering capability.
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 tool retrieves tasks from a board or list with filtering, which is specific and actionable. However, it does not explicitly differentiate from sibling tools like trello_get_board or trello_list_boards, though the distinct purpose is implied.
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, nor does it mention prerequisites or exclusions. The agent must infer usage context from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Trello boards accessible to the user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read-only behavior, which is correct. However, it does not disclose additional traits like pagination, rate limits, or the structure of the returned data. For a simple list tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and conveys the essential purpose efficiently.
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 zero-parameter listing tool, the description is largely complete. It explains the action and scope. It does not describe the output, but given no output schema and the simplicity of the operation, it is sufficient.
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?
There are no parameters, so the schema is fully covered. The description adds value by specifying the scope 'accessible to the user', which is not captured in the empty schema, thus providing useful semantic context.
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 'list' and resource 'all Trello boards accessible to the user', which is specific and distinguishes this tool from siblings like trello_get_board (single board) and trello_setup_board (configuration).
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 guidance is provided. The description does not indicate when to use this tool versus alternatives such as trello_get_board or trello_analyze_board, nor does it mention any prerequisites or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a board with default lists for task management (To Do, In Progress, Done)
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The ID of the board to setup |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only mentions setup without disclosing side effects, permissions, or whether it overwrites existing 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?
Single sentence with no unnecessary words, but it omits critical behavioral details.
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 1 parameter and no output schema, the description fails to explain what 'setup' fully entails or the result state.
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%, and the description adds only the context of default lists but no additional 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 states the tool sets up a board with default lists (To Do, In Progress, Done), distinguishing it from sibling tools like analyze_board or get_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 on when to use this tool versus alternatives, no prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a complex task and suggest how to split it into smaller, manageable tasks
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The ID of the card to analyze and split | |
| autoCreate | No | Whether to automatically create the suggested split tasks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fails to disclose that the tool can optionally create tasks (autoCreate=true). Without annotations, the description should describe side effects; but it only mentions 'suggest', omitting creation 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, concise sentence that effectively communicates the tool's core function without waste.
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 description does not specify what the tool returns (e.g., a list of suggested tasks) and lacks output schema. It also omits prerequisites or postconditions, leaving the agent with incomplete 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%, and the description adds no additional meaning beyond the schema's descriptions for cardId and autoCreate. Baseline score 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 clearly states the tool analyzes a complex task and suggests how to split it, using specific verbs and resources, and distinguishes itself from sibling tools like trello_create_task or trello_clarify_task.
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 implies the tool is used for splitting tasks but does not explicitly state when to use it over alternatives or when not to use it. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task with new information or move it to a different list
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | The ID of the card to update | |
| title | No | New title for the task | |
| description | No | Updated description | |
| status | No | New status (maps to Trello lists) | |
| priority | No | Updated priority level | |
| dueDate | No | Updated due date in ISO format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states what the tool does, not any behavioral traits like mutation, idempotency, or permissions. No side effects or results are disclosed.
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, front-loading the core action. It could be slightly more structured, but it is efficient with no 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 complete schema and no output schema, the description is adequate for basic understanding but lacks details on partial updates, return values, or failure states. It does not fully compensate for the missing annotation 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%, so baseline is 3. The description adds no additional meaning beyond the schema's own parameter descriptions, nor does it explain parameter relationships or formats.
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 tool updates an existing task with new information or moves it to a different list. It uses a specific verb-resource pair and distinguishes from sibling tools like trello_create_task or trello_get_tasks.
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. The description does not mention scenarios, exclusions, or when to prefer other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0trello_analyze_boardtrello_clarify_tasktrello_create_tasktrello_get_boardtrello_get_taskstrello_list_boardstrello_setup_boardtrello_split_tasktrello_update_taskEach tool has a clearly distinct purpose: listing boards, getting board details, retrieving tasks, creating/updating tasks, and analysis/improvement tools. No overlap.
All tools follow consistent snake_case verb_noun pattern (e.g., trello_list_boards, trello_create_task). No deviations.
9 tools is well-scoped for a Trello server, covering board management, task CRUD, and advanced analysis without being excessive.
Covers essential board and task operations plus analysis features. Minor gap: no delete operation for tasks or boards, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native Kanban board — connect Claude to claim, work and move your tasks over MCP.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Plan trips directly into TravelOwl from a conversation with Claude.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MagnusNilsson/trello-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
