Which integrations are available for this server?

Provides tools for managing Trello boards, lists, and cards, including listing boards, reading board contents, creating and moving cards, adding comments, archiving cards, and more via the Trello API.

How do I use Trello MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. 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.

Trello MCP Server

by lzvxck

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Trello MCP Server

A Model Context Protocol (MCP) server that connects Trello with AI assistants like Claude Desktop, GitHub Copilot Chat, and other MCP-compatible clients.

Features

📋 List all your Trello boards
🔍 Read board contents (lists and cards)
➕ Create new cards
🔄 Move cards between lists
💬 Add comments to cards
🗃️ Archive cards
🔗 Access boards as MCP resources
🐳 Docker support for easy deployment

Related MCP server: trello-mcp

Prerequisites

Node.js 20+ installed (for local development)
Docker (for containerized deployment)
A Trello account
Trello API credentials (API Key and Token)

Installation

Option 1: Local Installation

Clone this repository:

git clone https://github.com/lioarce01/trello-mcp-server.git
cd trello-mcp-server

Install dependencies:

npm install

Build the TypeScript code:

npm run build

Option 2: Docker Installation

Clone this repository:

git clone https://github.com/lioarce01/trello-mcp-server.git
cd trello-mcp-server

Build the Docker image:

docker build -t trello-mcp-server .

Getting Trello API Credentials

Get your API Key:
- Go to https://trello.com/app-key
- Copy your API Key
Get your Token:
- On the same page, click on "Token" link
- Authorize the application and copy your Token

Configuration

For Claude Desktop

Local Installation

Add the server configuration to your Claude Desktop config file:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json

{
  "mcp": {
    "servers": {
      "trello-mcp": {
        "command": "node",
        "args": ["absolute/path/to/the/project/dist/index.js"],
        "env": {
          "TRELLO_API_KEY": "your_api_key",
          "TRELLO_TOKEN": "your_token",
          "TRELLO_BASE_URL": "https://api.trello.com/1"
        }
      }
    }
  }
}

Docker Configuration

For Docker deployment, add this configuration:

{
  "mcp": {
    "servers": {
      "trello-mcp": {
        "command": "docker",
        "args": [
          "run",
          "--rm",
          "-i",
          "-e",
          "TRELLO_API_KEY=your_api_key",
          "-e",
          "TRELLO_TOKEN=your_token",
          "-e",
          "TRELLO_BASE_URL=https://api.trello.com/1",
          "trello-mcp-server"
        ]
      }
    }
  }
}

For VS Code with GitHub Copilot Chat

Local Installation

Add to your VS Code settings.json:

{
  "mcp": {
    "servers": {
      "trello-mcp": {
        "command": "node",
        "args": ["absolute/path/to/the/project/dist/index.js"],
        "env": {
          "TRELLO_API_KEY": "your_api_key",
          "TRELLO_TOKEN": "your_token",
          "TRELLO_BASE_URL": "https://api.trello.com/1"
        }
      }
    }
  }
}

Docker Configuration

{
  "mcp": {
    "servers": {
      "trello-mcp": {
        "command": "docker",
        "args": [
          "run",
          "--rm",
          "-i",
          "-e",
          "TRELLO_API_KEY=your_api_key",
          "-e",
          "TRELLO_TOKEN=your_token",
          "-e",
          "TRELLO_BASE_URL=https://api.trello.com/1",
          "trello-mcp-server"
        ]
      }
    }
  }
}

Important:

Replace absolute/path/to/the/project/dist/index.js with the actual absolute path to your compiled server file (local installation)
Replace YOUR_TRELLO_API_KEY and YOUR_TRELLO_TOKEN with your actual Trello credentials

Docker Usage

Using Docker Run

# Build the image
docker build -t trello-mcp-server .

# Run with API key and token as arguments
docker run --rm -i --env-file .env trello-mcp-server

Local Testing

To test if your server works correctly:

Build the project:

npm run build

Run with credentials:

node dist/index.js

Docker Testing

Build and run with Docker:

docker build -t trello-mcp-server .
docker run --rm -i --env-file .env trello-mcp-server

You should see:

MCP server connected and ready.

Note: The server will wait for MCP client connections. To exit, press Ctrl+C.

Once configured, you can interact with your Trello boards through natural language:

List Boards

Show me all my Trello boards

Read Board Contents

What cards are in my "Project Management" board?

Create Cards

Create a new card called "Review documentation" in the "To Do" list

Move Cards

Move the "Bug fix" card to the "In Progress" list

Add Comments

Add a comment to the card saying "This needs urgent attention"

Archive Cards

Archive the completed card "Setup database"

Available Tools

Tool	Description	Parameters
`list_boards`	List all open Trello boards	None
`read_board`	Read lists and cards from a specific board	`boardId`
`create_list`	Create a list	`boardId`, `name`
`create_card`	Create a new card in a specific list	`listId`, `name`, `desc` (optional)
`move_card`	Move a card to a different list	`cardId`, `listId`
`add_comment`	Add a comment to a card	`cardId`, `text`
`archive_card`	Archive a card	`cardId`
`archive_list`	Archive a list	`listId`
`delete_board`	Delete a board	`boardId`
`update_list_name`	Update a list name	`listId`, `name`
`update_card_name`	Update a card name	`cardId`, `name`

Available Resources

The server exposes your Trello boards as MCP resources that can be read by AI assistants:

Resource URI: board:{boardId}
Content: JSON containing all lists and cards for the board

Development

Building

Local Development

npm run build

Docker Development

# Build Docker image
docker build -t trello-mcp-server .

Running in Development

Local Development

To run the server directly (for testing):

# With npm
npm run build
node dist/index.js

# With pnpm
pnpm run build
node dist/index.js

Docker Development

# Run with docker (pass credentials as arguments)
docker run --rm -i --env-file .env trello-mcp-server

Development Scripts

You can also create a development script in your package.json:

{
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js",
    "dev": "tsx ./src/index.ts",
    "docker:build": "docker build -t trello-mcp-server .",
    "docker:run": "docker run --rm -i --env-file .env trello-mcp-server"
  }
}

Troubleshooting

Server Not Connecting

Check credentials: Make sure you're passing API Key and Token as arguments
Verify file path: Ensure the path in your MCP configuration is correct (local installation)
Build first: Always run npm run build or docker build before testing
Test standalone: Try running the server independently first
Restart client: Restart your MCP client (Claude Desktop/VS Code) after config changes

Docker-Specific Issues

Image not found: Make sure you've built the Docker image first with docker build -t trello-mcp-server .
Arguments not passed: Ensure API key and token are passed as arguments after the image name
Permissions: Check that Docker has the necessary permissions to run containers

Invalid Credentials Error

Double-check your Trello API Key and Token
Ensure the token has the necessary permissions
Try regenerating your token if it's expired
Verify credentials are properly passed as arguments

Tools Not Working

Verify the board/card/list IDs are correct
Check that you have write permissions to the Trello board
Look at the console logs for detailed error messages

Security Notes

Never commit your API credentials to version control
Store credentials securely and rotate them regularly
Use .env files and add them to .gitignore
The server only requires the permissions you grant via the Trello token
Consider using environment variables for credentials in production
Docker containers run with non-root user for security

License

This project is licensed under the MIT License - see the LICENSE file for details.

Made with ❤️ for the MCP community

Available Tools

11 tools

add_commentB

Add a comment to a card

ParametersJSON Schema

Name	Required	Description	Default
`cardId`	Yes	ID of the card to add a comment to
`text`	Yes	Comment text

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description fails to disclose any behavioral traits beyond the action, such as whether it returns a comment ID 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently states the purpose, but it is front-loaded and concise, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters and no output schema, the description is minimal and lacks details about return values or behavior, leaving gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (both parameters documented), so baseline is 3. The description adds no additional meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Add a comment to a card' with a specific verb and resource, distinguishing it from sibling tools like create_card or update_card_name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description only states what it does, without providing context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

archive_cardB

Archive a card

ParametersJSON Schema

Name	Required	Description	Default
`cardId`	Yes	ID of the card to archive

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It does not disclose side effects (e.g., card visibility changes, reversibility) or any behavior beyond the bare action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence with no wasted words. It is appropriately sized for the simple operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is adequate but lacks context on behavioral impacts (e.g., permanence, permissions) that would help an agent understand full implications.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning to the parameter beyond what the schema already states ('ID of the card to archive').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Archive a card' uses a specific verb and resource, clearly distinguishing it from sibling tools like archive_list (different resource) and other card operations (create_card, move_card).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., deleting or hiding a card). No prerequisites or conditions for archiving are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

archive_listC

Archive a list

ParametersJSON Schema

Name	Required	Description	Default
`listId`	Yes	ID of the list to archive

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description lacks details on behavioral traits such as reversibility, side effects on cards, or permission requirements. Without annotations, the burden is on the description to disclose these, but it does not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at three words, which is efficient for a simple action. However, it could benefit from slightly more structure or context without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations, output schema, and complexity, the description is insufficient. It fails to cover important contextual details like effect on list contents, reversibility, or any prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description of the parameter in the schema is adequate. The tool description adds no extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action 'Archive' and the resource 'list', which is clear and specific. It distinguishes from sibling tools like 'archive_card' by the resource type, though it 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., delete_board). There are no exclusions, prerequisites, or context for the archiving action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_cardC

Create a new card in a specific list

ParametersJSON Schema

Name	Required	Description
`listId`	Yes	ID of the list to create the card in
`name`	Yes	Name of the card
`desc`	No	Description of the card (optional)

TDQS

C2.9/5.0

Behavior1/5

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 'create a new card' without mentioning side effects, permissions, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short, single sentence that is front-loaded with the key action. Could be slightly more structured but is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and three parameters (two required), the description is too minimal. It fails to explain what is returned or any constraints beyond schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage for parameter descriptions. The description adds no additional meaning beyond what the schema provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the action (create) and resource (card) and context (in a specific list). It clearly distinguishes from sibling tools like archive_card or move_card.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., add_comment or create_list). No context for prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_listB

Create a new list in a specific board

ParametersJSON Schema

Name	Required	Description	Default
`boardId`	Yes	ID of the board to create the list in
`name`	Yes	Name of the list

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only states the basic action. Lacks disclosure of side effects, error behavior, or specific constraints (e.g., position, uniqueness).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no unnecessary words. Efficient but could benefit from slightly more structure (e.g., bullet points for parameters).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Minimal description for a simple creation tool. Lacks info on return values, failure modes, or integration with other tools. Incomplete for an agent to assess suitability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions, so description adds no extra meaning beyond the schema. Baseline 3 as schema coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action (Create), the resource (list), and the context (in a specific board). It distinguishes from sibling tools like archive_list or delete_board.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No preconditions or context about when creation is appropriate (e.g., board existence, permissions).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_boardC

Delete a board

ParametersJSON Schema

Name	Required	Description	Default
`boardId`	Yes	ID of the board to delete

TDQS

C2.4/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility for disclosing behavior. It only states 'Delete a board' with no information about irreversibility, cascading effects, required permissions, or safety considerations. This is a critical gap for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. While it is under-informative, the conciseness itself is good.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a deletion operation with no output schema and no annotations, the description should disclose behavioral implications such as irreversibility or side effects. It fails to do so, leaving the agent without essential context for safe usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage for the single parameter 'boardId' with a clear description. The tool description adds no additional parameter information, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete a board' is clear and specific to the action, but it essentially restates the tool name without adding any additional context or differentiation from sibling tools. It is not misleading, but it lacks depth.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like archive_card or archive_list. There is no mention of prerequisites or exclusions, leaving the agent to infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_boardsA

List all open Trello boards

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the tool lists open boards, but it does not reveal whether this is read-only, if there are any rate limits, pagination behavior, or what the return structure looks like. This is insufficient for an agent to understand the tool's full behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that contains no unnecessary words. It is maximally concise and well-structured for its purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description is minimally complete. However, it does not mention any context like authentication requirements, board privacy scoping, or output format details, which could affect an agent's correct invocation. For a simple tool, this is acceptable but not exemplary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters and 100% coverage, so the baseline is 4. The description adds no parameter information because none is needed; it simply states the filter 'open', which is inherent to the tool's operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' and clearly identifies the resource 'all open Trello boards'. It effectively distinguishes from sibling tools that perform actions like adding comments, archiving cards, or creating lists, which are all different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for listing boards, but it provides no explicit guidance on when to use it versus alternatives, nor does it mention when not to use it. While siblings are different, the lack of clarification on 'open' boards or any prerequisites drops the score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

move_cardB

Move a card to a different list

ParametersJSON Schema

Name	Required	Description	Default
`cardId`	Yes	ID of the card to move
`listId`	Yes	ID of the target list

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description should disclose behavioral details. It only says 'move to a different list' but does not state if the move is always allowed, what happens to card metadata, or if there are 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the core action without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no output schema, the description is minimally complete. However, it could hint at the result (e.g., returns the moved card) or mention that the move is between lists, which is already implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters have descriptions). The description adds no additional semantic meaning beyond what is already in the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'move' on the resource 'card' to a target 'different list'. It distinguishes from sibling tools like archive_card or create_card.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. For example, it does not mention prerequisites like the card must belong to a list, or when to use update_card_name instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_boardB

Read lists and cards from a specific board

ParametersJSON Schema

Name	Required	Description	Default
`boardId`	Yes	ID of the board to read

TDQS

B3.3/5.0

Behavior2/5

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 read operation without disclosing behavior such as error handling, idempotency, or data scope beyond the basic description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that gets directly to the point with no unnecessary words. It is appropriately brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one parameter and no output schema, the description covers the basic purpose but lacks details about return format, potential filters, or limitations. It is minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% as the single parameter 'boardId' is described. The description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'Read lists and cards from a specific board', providing a specific verb and resource. It distinguishes from siblings like list_boards (which lists boards) and create_card or update_card.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like list_boards or when not to use it. There is no context about prerequisites or scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_card_nameC

Update a card name

ParametersJSON Schema

Name	Required	Description	Default
`cardId`	Yes	ID of the card to be updated
`name`	Yes	New name of the card

TDQS

C2.6/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Update', implying mutation, but fails to mention permissions, side effects, or whether the operation is reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (4 words) but lacks necessary detail. It earns its place but is underinformative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so description should explain return values or error conditions, but it does not. The tool is simple but incomplete in context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters have descriptions. The description adds no extra meaning beyond what the schema provides, meeting baseline but not exceeding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool updates a card name, but does not differentiate it from sibling tools like update_list_name or move_card. It is specific to the resource and action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as archive_card or add_comment. The description lacks context for selective use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_list_nameC

Update a list name

ParametersJSON Schema

Name	Required	Description	Default
`listId`	Yes	ID of the list to be updated
`name`	Yes	New name of the card

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It only states the action without mentioning side effects, permissions, or idempotency. The description is insufficient for an agent to understand the full impact of calling the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence) but lacks necessary information. It fails to structure details like return value or usage context, making it under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description should provide more context about the operation, such as outcomes or error conditions. The current description is too minimal for an agent to use reliably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds no value beyond the schema. Furthermore, the parameter description for 'name' incorrectly says 'New name of the card' instead of 'list', which could mislead the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update a list name' clearly states the verb and resource, making it understandable. However, it does not differentiate from the sibling tool 'update_card_name', and there is a potential confusion due to the parameter name description mentioning 'card' instead of 'list'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'update_card_name'. There are no prerequisites or contextual hints for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv1.0.0May 30, 2026
- First observedadd_comment
- First observedarchive_card
- First observedarchive_list
- First observedcreate_card
- First observedcreate_list
- First observeddelete_board
- First observedlist_boards
- First observedmove_card
- First observedread_board
- First observedupdate_card_name
- First observedupdate_list_name

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-05-30 19:30 across 11 tools

Disambiguation5/5

Each tool targets a distinct action on a specific Trello entity (board, list, card, comment). There is no overlap; for example, read_board reads a board's contents while list_boards lists all boards, and move_card vs archive_card are clearly different.

Naming Consistency5/5

All tool names consistently use snake_case with a verb_noun pattern (e.g., create_card, archive_list, update_card_name). The verbs (add, archive, create, delete, list, move, read, update) are descriptive and uniformly applied across the tool set.

Tool Count5/5

With 11 tools, the set covers the core operations for managing Trello boards, lists, and cards. The count is well-balanced—not too few to be incomplete and not too many to be overwhelming—suitable for a focused Trello MCP server.

Completeness3/5

The server provides essential operations for boards (list, read, delete), lists (create, archive, rename), and cards (create, archive, move, rename, comment). However, it lacks board creation and card deletion, which are common lifecycle operations, leaving notable gaps for a full Trello workflow.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,851
Kanban AI
io.github.orholam
Remote MCP for Kanban AI boards—manage projects, tasks, and comments from AI tools.
Project Management Workplace & Productivity
21
Stellary Project Management MCP ServerOAuth
io.github.Anymfah
Connect AI assistants to Stellary projects, boards, documents, and governed agent workflows.
Project Management Agent Orchestration
2
TriloOAuth
chat.trilo
Connect AI tools to Trilo workspaces — manage tasks, messages, pages, calendars, meetings, and more.
Workplace & Productivity App Automation Project Management
2

Related MCP Servers

Trello MCP Server
Project Management App Automation Workplace & Productivity
gh-hirokuma
A
license
A
quality
D
maintenance
Enables interaction with Trello through the Trello API, allowing users to manage boards, lists, and cards including creating, updating, deleting, and retrieving Trello data through natural language.
Updated 9 months ago (2025-12-11 15:56 UTC)
7
34 npm
MIT
trello-mcp
Project Management Workplace & Productivity
Artemnikov
F
license
A
quality
D
maintenance
Enables AI assistants to manage Trello boards, lists, cards, comments, checklists, labels, and members through natural language.
Updated 4 months ago (2026-05-01 07:39 UTC)
16
-
Trello MCP Server
Project Management Communication
SemblanceLabs
F
license
Not graded
quality
C
maintenance
Enables AI assistants to interact with Trello boards, cards, lists, and more through a standardized interface.
Updated 7 months ago (2026-02-02 16:47 UTC)
-
Trello MCP Server
Project Management Workplace & Productivity
r123singh
F
license
Not graded
quality
D
maintenance
Enables interaction with Trello boards, lists, and cards. Supports creating, updating, moving cards, and adding comments via natural language.
Updated a year ago (2025-05-14 13:21 UTC)
1
-