Provides tools for interacting with Trello boards, including managing cards, lists, boards, and workspaces, with support for rate limiting and dynamic board selection.
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 cards in the 'In Progress' list"
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 tools for interacting with Trello boards. This server enables seamless integration with Trello's API while handling rate limiting, type safety, and error handling automatically.
Fixed MCP protocol compatibility by removing all console output that interfered with JSON-RPC communication
Improved pnpx support - now works seamlessly with pnpx @delorenj/mcp-server-trello
Updated installation docs to feature pnpx as the primary installation method
Added mise installation instructions for convenient tool management
Production-ready release with stable API
Added multi-board support - all methods now accept optional boardId parameter (thanks @blackoutnet!)
TRELLO_BOARD_ID environment variable is now optional and serves as default board
Added board and workspace management capabilities:
list_boards - List all boards the user has access to
set_active_board - Set the active board for future operations
list_workspaces - List all workspaces the user has access to
set_active_workspace - Set the active workspace for future operations
list_boards_in_workspace - List all boards in a specific workspace
get_active_board_info - Get information about the currently active board
Added persistent configuration storage to remember active board/workspace
Improved error handling with MCP-specific error types
Full backward compatibility maintained
Added detailed JSDoc comments to rate limiter functions
Improved error handling for image attachment functionality
Updated documentation for attach_image_to_card tool
Added attach_image_to_card tool to attach images to cards from URLs
Added Docker support with multi-stage build
Improved security by moving environment variables to .env
Added Docker Compose configuration
Added .env.template for easier setup
Added move_card tool to move cards between lists
Improved documentation
Initial release with basic Trello board management features
Related MCP server: MCP Server Trello
Full Trello Board Integration: Interact with cards, lists, and board activities
Built-in Rate Limiting: Respects Trello's API limits (300 requests/10s per API key, 100 requests/10s per token)
Type-Safe Implementation: Written in TypeScript with comprehensive type definitions
Input Validation: Robust validation for all API inputs
Error Handling: Graceful error handling with informative messages
Dynamic Board Selection: Switch between boards and workspaces without restarting
The easiest way to use the Trello MCP server is with pnpx, which doesn't require a global install:
{
"mcpServers": {
"trello": {
"command": "pnpx",
"args": ["@delorenj/mcp-server-trello"],
"env": {
"TRELLO_API_KEY": "your-api-key",
"TRELLO_TOKEN": "your-token"
}
}
}
}Or if you're using mise:
{
"mcpServers": {
"trello": {
"command": "mise",
"args": ["x", "--", "pnpx", "@delorenj/mcp-server-trello"],
"env": {
"TRELLO_API_KEY": "your-api-key",
"TRELLO_TOKEN": "your-token"
}
}
}
}To connect a Trello workspace, you'll need to manually retrieve a TRELLO_TOKEN once per workspace. After setting up your Trello Power-Up, visit the following URL:
https://trello.com/1/authorize?expiration=never&name=YOUR_APP_NAME&scope=read,write&response_type=token&key=YOUR_API_KEYReplace:
YOUR_APP_NAME with a name for your application (e.g., "My Trello Integration"). This name is shown to the user on the Trello authorization screen.
YOUR_API_KEY with the API key for your Trello Power-Up
This will generate the token required for integration.
Theexpiration=never parameter creates a token that does not expire. For enhanced security, consider using expiration=30days and renewing the token periodically if your setup allows for it.
The simplest way to get pnpm (and thus pnpx) is through mise:
# Install mise (if you don't have it)
curl https://mise.run | sh
# Install pnpm with mise
mise install pnpmIf you prefer using npm directly:
npm install -g @delorenj/mcp-server-trelloThen use mcp-server-trello as the command in your MCP configuration.
To install Trello Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @modelcontextprotocol/mcp-server-trello --client claudeFor containerized environments:
Clone the repository:
git clone https://github.com/delorenj/mcp-server-trello
cd mcp-server-trelloCopy the environment template and fill in your Trello credentials:
cp .env.template .envBuild and run with Docker Compose:
docker compose up --buildThe server can be configured using environment variables. Create a .env file in the root directory with the following variables:
# Required: Your Trello API credentials
TRELLO_API_KEY=your-api-key
TRELLO_TOKEN=your-token
# Optional (Deprecated): Default board ID (can be changed later using set_active_board)
TRELLO_BOARD_ID=your-board-id
# Optional: Initial workspace ID (can be changed later using set_active_workspace)
TRELLO_WORKSPACE_ID=your-workspace-idYou can get these values from:
API Key: https://trello.com/app-key
Token: Generate using your API key
Board ID (optional, deprecated): Found in the board URL (e.g., https://trello.com/b/BOARD_ID/board-name)
Workspace ID: Found in workspace settings or using list_workspaces tool
Starting with version 0.3.0, the MCP server supports multiple ways to work with boards:
Multi-board support: All methods now accept an optional boardId parameter
Omit TRELLO_BOARD_ID and provide boardId in each API call
Set TRELLO_BOARD_ID as default and optionally override with boardId parameter
Dynamic board selection: Use workspace management tools
The TRELLO_BOARD_ID in your .env file is used as the initial/default board ID
You can change the active board at any time using the set_active_board tool
The selected board persists between server restarts (stored in ~/.trello-mcp/config.json)
Similarly, you can set and persist an active workspace using set_active_workspace
This allows you to work with multiple boards and workspaces without restarting the server.
Start by listing available boards:
{
name: 'list_boards',
arguments: {}
}Set your active board:
{
name: 'set_active_board',
arguments: {
boardId: "abc123" // ID from list_boards response
}
}List workspaces if needed:
{
name: 'list_workspaces',
arguments: {}
}Set active workspace if needed:
{
name: 'set_active_workspace',
arguments: {
workspaceId: "xyz789" // ID from list_workspaces response
}
}Check current active board info:
{
name: 'get_active_board_info',
arguments: {}
}Fetch all cards from a specific list.
{
name: 'get_cards_by_list_id',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
listId: string // ID of the Trello list
}
}Retrieve all lists from a board.
{
name: 'get_lists',
arguments: {
boardId?: string // Optional: ID of the board (uses default if not provided)
}
}Fetch recent activity on a board.
{
name: 'get_recent_activity',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
limit?: number // Optional: Number of activities to fetch (default: 10)
}
}Add a new card to a specified list.
{
name: 'add_card_to_list',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
listId: string, // ID of the list to add the card to
name: string, // Name of the card
description?: string, // Optional: Description of the card
dueDate?: string, // Optional: Due date (ISO 8601 format)
labels?: string[] // Optional: Array of label IDs
}
}Update an existing card's details.
{
name: 'update_card_details',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
cardId: string, // ID of the card to update
name?: string, // Optional: New name for the card
description?: string, // Optional: New description
dueDate?: string, // Optional: New due date (ISO 8601 format)
labels?: string[] // Optional: New array of label IDs
}
}Send a card to the archive.
{
name: 'archive_card',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
cardId: string // ID of the card to archive
}
}Add a new list to a board.
{
name: 'add_list_to_board',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
name: string // Name of the new list
}
}Send a list to the archive.
{
name: 'archive_list',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
listId: string // ID of the list to archive
}
}Fetch all cards assigned to the current user.
{
name: 'get_my_cards',
arguments: {}
}Move a card to a different list.
{
name: 'move_card',
arguments: {
boardId?: string, // Optional: ID of the target board (uses default if not provided)
cardId: string, // ID of the card to move
listId: string // ID of the target list
}
}Attach an image to a card directly from a URL.
{
name: 'attach_image_to_card',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
cardId: string, // ID of the card to attach the image to
imageUrl: string, // URL of the image to attach
name?: string // Optional: Name for the attachment (defaults to "Image Attachment")
}
}List all boards the user has access to.
{
name: 'list_boards',
arguments: {}
}Set the active board for future operations.
{
name: 'set_active_board',
arguments: {
boardId: string // ID of the board to set as active
}
}List all workspaces the user has access to.
{
name: 'list_workspaces',
arguments: {}
}Set the active workspace for future operations.
{
name: 'set_active_workspace',
arguments: {
workspaceId: string // ID of the workspace to set as active
}
}List all boards in a specific workspace.
{
name: 'list_boards_in_workspace',
arguments: {
workspaceId: string // ID of the workspace to list boards from
}
}Get information about the currently active board.
{
name: 'get_active_board_info',
arguments: {}
}Get all members of a specific board.
{
name: 'get_board_members',
arguments: {
boardId?: string // Optional: ID of the board (uses default if not provided)
}
}Assign a member to a specific card.
{
name: 'assign_member_to_card',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
cardId: string, // ID of the card to assign the member to
memberId: string // ID of the member to assign to the card
}
}Remove a member from a specific card.
{
name: 'remove_member_from_card',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
cardId: string, // ID of the card to remove the member from
memberId: string // ID of the member to remove from the card
}
}Get all labels of a specific board.
{
name: 'get_board_labels',
arguments: {
boardId?: string // Optional: ID of the board (uses default if not provided)
}
}Create a new label on a board.
{
name: 'create_label',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
name: string, // Name of the label
color?: string // Optional: Color of the label (e.g., "red", "blue", "green", "yellow", "orange", "purple", "pink", "sky", "lime", "black", "null")
}
}Update an existing label.
{
name: 'update_label',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
labelId: string, // ID of the label to update
name?: string, // Optional: New name for the label
color?: string // Optional: New color for the label
}
}Delete a label from a board.
{
name: 'delete_label',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
labelId: string // ID of the label to delete
}
}Get the history/actions of a specific card.
{
name: 'get_card_history',
arguments: {
boardId?: string, // Optional: ID of the board (uses default if not provided)
cardId: string, // ID of the card to get history for
limit?: number, // Optional: Number of actions to fetch (default: all)
filter?: string // Optional: Filter actions by type (e.g., "all", "updateCard:idList", "addAttachmentToCard", "commentCard", "updateCard:name", "updateCard:desc", "updateCard:due", "addMemberToCard", "removeMemberFromCard", "addLabelToCard", "removeLabelFromCard")
}
}The Trello MCP server pairs beautifully with @flowluap/ideogram-mcp-server for AI-powered visual content creation. Generate images with Ideogram and attach them directly to your Trello cards!
Generate an image with Ideogram:
// Using ideogram-mcp-server
{
name: 'generate_image',
arguments: {
prompt: "A futuristic dashboard design with neon accents",
aspect_ratio: "16:9"
}
}
// Returns: { image_url: "https://..." }Attach the generated image to a Trello card:
// Using trello-mcp-server
{
name: 'attach_image_to_card',
arguments: {
cardId: "your-card-id",
imageUrl: "https://...", // URL from Ideogram
name: "Dashboard Mockup v1"
}
}Add both servers to your Claude Desktop configuration:
{
"mcpServers": {
"trello": {
"command": "pnpx",
"args": ["@delorenj/mcp-server-trello"],
"env": {
"TRELLO_API_KEY": "your-trello-api-key",
"TRELLO_TOKEN": "your-trello-token"
}
},
"ideogram": {
"command": "pnpx",
"args": ["@flowluap/ideogram-mcp-server"],
"env": {
"IDEOGRAM_API_KEY": "your-ideogram-api-key"
}
}
}
}Now you can seamlessly create visual content and organize it in Trello, all within Claude!
The server implements a token bucket algorithm for rate limiting to comply with Trello's API limits:
300 requests per 10 seconds per API key
100 requests per 10 seconds per token
Rate limiting is handled automatically, and requests will be queued if limits are reached.
The server provides detailed error messages for various scenarios:
Invalid input parameters
Rate limit exceeded
API authentication errors
Network issues
Invalid board/list/card IDs
Node.js 16 or higher
npm or yarn
Clone the repository
git clone https://github.com/delorenj/mcp-server-trello
cd mcp-server-trelloInstall dependencies
npm installBuild the project
npm run buildThe evals package loads an mcp client that then runs the index.ts file, so there is no need to rebuild between tests. You can load environment variables by prefixing the npx command. Full documentation can be found here.
OPENAI_API_KEY=your-key npx mcp-eval src/evals/evals.ts src/index.tsContributions are welcome!
This project is licensed under the MIT License - see the LICENSE file for details.
Built with the Model Context Protocol SDK
Uses the Trello REST API
Add a new card to a specified list on a specific board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| listId | Yes | ID of the list to add the card to | |
| name | Yes | Name of the card | |
| description | No | Description of the card | |
| dueDate | No | Due date for the card (ISO 8601 format) | |
| labels | No | Array of label IDs to apply to the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states 'Add' without disclosing side effects, permissions, error behavior, or constraints like duplicate names or default board handling.
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?
One short sentence efficiently communicates the core action without redundancy.
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 6-parameter tool with no output schema, the description omits return values, default behavior for optional boardId, and any outcome 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 coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema, such as the relationship between boardId and listId.
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 uses a specific verb ('Add') and identifies the resource ('a new card to a specified list on a specific board'), clearly distinguishing it from siblings like move_card or archive_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 like add_list_to_board, nor prerequisites (e.g., needing board/list IDs) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new list to the specified board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| name | Yes | Name of the new list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'add a new list' without disclosing behavioral traits such as side effects, return values, or required permissions. Since no annotations are provided, the description carries the full burden, which it fails to meet.
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 efficiently conveys the purpose without any wasted words. It is front-loaded and earns its place.
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 creation tool with only two parameters and no output schema, the description is minimally adequate. However, it lacks context about what happens when boardId is omitted (only schema mentions default) and does not explain the return behavior.
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 does not add additional meaning beyond what the input schema already provides for the parameters.
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 ('Add') and the resource ('list to the specified board'). It distinguishes from sibling tools like 'add_card_to_board' or 'archive_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 on when to use this tool versus alternatives, nor any prerequisites like requiring an active board. The description is purely operational.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a card to the archive on a specific board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| cardId | Yes | ID of the card to archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description lacks details on what archiving entails (e.g., reversibility, visibility changes, required permissions). 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?
Single sentence, no wasted words. Could include a bit more context without becoming verbose.
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 annotations or output schema, the description should provide more behavioral context. It is adequate for a simple action but lacks depth to fully inform usage.
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 both parameters. The description adds no extra meaning beyond the schema, so baseline 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 clearly states the tool archives a card on a specific board, with a specific verb ('Send to archive') and resource ('card'). It distinguishes from siblings like 'archive_list' and 'move_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 such as 'delete_card' or 'archive_list'. No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a list to the archive on a specific board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| listId | Yes | ID of the list to archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It fails to mention side effects (e.g., what happens to cards in the list), required permissions, or reversibility of the archive action.
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. It could be slightly more direct (e.g., 'Archives a list on a board') but is not overly verbose.
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 is simple, but the description lacks details needed for an agent to reliably use it alongside sibling tools like 'archive_card'. No output schema is provided, but the main gap is guidance.
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 baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions (e.g., 'uses default if not provided' for boardId).
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 ('send to archive') and resource ('list') with scope ('on a specific board'). It distinguishes from sibling 'archive_card' by targeting lists instead of cards.
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 over alternatives like 'archive_card' or 'add_list_to_board'. The agent must infer from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign a member to a specific card
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| cardId | Yes | ID of the card to assign the member to | |
| memberId | Yes | ID of the member to assign to the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as failure conditions, success criteria, or side effects (e.g., notifications).
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 redundant information. Efficiently communicates the core action.
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 no output schema and no annotations, the description is too brief. It omits important context such as return values, error handling, and required 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%; each parameter already has a clear description. The tool 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (assign), the resource (member to card), and is specific. It distinguishes from sibling tools like remove_member_from_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 or not use this tool versus alternatives. No prerequisites or context about required preconditions (e.g., member must be on the board) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach an image to a card from a URL on a specific board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board where the card exists (uses default if not provided) | |
| cardId | Yes | ID of the card to attach the image to | |
| imageUrl | Yes | URL of the image to attach | |
| name | No | Optional name for the attachment (defaults to "Image Attachment") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It lacks details such as whether the image is downloaded or linked, what happens on failure, required permissions, or side effects like overwriting existing attachments.
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 efficiently communicates the core action and 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?
With no output schema and moderate complexity, the description covers the basic action but omits important context like return value confirmation, error handling, or constraints (e.g., file size limits). The schema covers parameters, but behavior remains under-specified.
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 4 parameters are documented in the input schema with descriptions, achieving 100% coverage. The tool description does not add further meaning beyond summarizing the parameters, 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 clearly states the action (attach), the resource (image to card), and the source (from a URL on a specific board). It is specific and distinguishes from sibling tools, none of which perform image attachment.
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., updating card details). There is no mention of prerequisites or conditions under which this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new label on a board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| name | Yes | Name of the label | |
| color | No | Color of the label (e.g., "red", "blue", "green", "yellow", "orange", "purple", "pink", "sky", "lime", "black", "null") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the basic create action without disclosing behavioral traits like permissions, 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?
Single sentence, to the point, 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?
For a simple create tool, the description is adequate but could mention constraints like uniqueness of label names per board.
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 describes parameters. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and the resource ('label on a board'). It differentiates from sibling tools like update_label or delete_label.
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 explicit guidance on when to use this tool versus alternatives. The purpose is implied but not contextualized against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a label from a board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| labelId | Yes | ID of the label to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies irreversible deletion but does not explicitly state permanence, side effects (e.g., label removed from all cards), or any required permissions. Given no annotations, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. However, it could be slightly more informative without sacrificing 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?
For a simple deletion tool, it lacks context about prerequisites, consequences, error states, and return behavior. Given the absence of output schema and annotations, more details are warranted.
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?
Input schema descriptions cover both parameters thoroughly (100% coverage). The description adds no additional 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 clearly states the verb 'Delete' and the resource 'label from a board', distinguishing it from sibling tools like create_label, update_label, and get_board_labels.
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, prerequisites (e.g., needing labelId from a prior lookup), or when not to use it. Does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the currently active board
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It fails to disclose behavioral traits such as read-only nature, authentication requirements, or any effects (none). This is a significant gap for a retrieval tool.
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, front-loaded sentence with no wasted words. Perfectly 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?
The description is minimal and does not explain the concept of 'active board' or its dependency on set_active_board. Given no output schema, the agent lacks clarity on what 'information' is included.
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 zero parameters, so the baseline is 4. The description adds no meaning beyond the empty schema, but this is acceptable for a parameterless tool.
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 'currently active board', distinguishing it from siblings like list_boards and set_active_board. However, 'information' is vague and doesn't specify what aspects (e.g., name, members, labels) are returned.
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 like set_active_board or get_board_labels. The description does not mention prerequisites (e.g., an active board must be set) 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 labels of a specific board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'Get all labels', implying read-only operation, but lacks details on permissions, rate limits, or side effects. Adequate for a simple read tool.
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, front-loaded with the action and resource, and contains no unnecessary 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's simplicity (one optional parameter, no output schema), the description is complete enough. It clearly communicates the tool's function without needing additional detail.
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 one parameter (boardId) already described. The description adds no further parameter meaning beyond 'of a specific board', 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 clearly states the verb 'Get', the resource 'labels', and the scope 'of a specific board'. It distinguishes itself from sibling tools like create_label, delete_label, and update_label.
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 does not provide explicit guidance on when to use this tool versus alternatives like get_board_members or get_active_board_info. Usage is implied from the name and description.
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 specific board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like authentication requirements, rate limits, or whether members are returned as user objects or IDs. For a read operation, minimal safety information is given.
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-loads the purpose with no redundant words. Every word is essential.
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 is adequate for a simple retrieval tool with one optional parameter and no output schema, but it lacks details about the return format (e.g., member names, IDs) and error conditions, which could be helpful given sibling tools for member management.
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 boardId parameter with a default behavior note. The tool description adds no additional meaning beyond what the schema provides. With 100% schema coverage, 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 clearly states the verb ('Get') and resource ('all members of a specific board'), distinguishing it from sibling tools like get_active_board_info or get_board_labels. The purpose is immediately understandable.
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 such as get_active_board_info or assign_member_to_card. There is no mention of prerequisites, exclusions, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the history/actions of a specific card
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| cardId | Yes | ID of the card to get history for | |
| limit | No | Optional: Number of actions to fetch (default: all) | |
| filter | No | Optional: Filter actions by type (e.g., "all", "updateCard:idList", "addAttachmentToCard", "commentCard", "updateCard:name", "updateCard:desc", "updateCard:due", "addMemberToCard", "removeMemberFromCard", "addLabelToCard", "removeLabelFromCard") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'Get the history/actions' without disclosing if the operation is read-only, whether it requires specific permissions, or if there are pagination or rate limits. No behavioral details beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient, but it lacks depth. It is not verbose, but it is also not fully informative; it achieves conciseness at the expense of completeness.
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 and no annotations, the description is insufficient. It does not explain what the returned history/actions contain, how limit and filter affect results, or any error conditions. A tool with four parameters and no output schema requires more 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?
The input schema provides detailed descriptions for all four parameters (100% coverage), so the description adds no additional meaning. Baseline score of 3 is appropriate as the schema already explains the parameters.
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 'history/actions of a specific card', which unambiguously defines the tool's purpose. It distinguishes itself from sibling tools like get_recent_activity (board-wide) and get_cards_by_list_id (list of cards).
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 scenarios where get_recent_activity might be preferred, nor any prerequisites or context for using filters or limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch cards from a specific Trello list on a specific board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| listId | Yes | ID of the Trello list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states read-only fetch but does not disclose behavioral traits such as pagination, sorting, error handling, or what happens when boardId is omitted (default board).
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 action and resource, no wasted words. Efficient and clear.
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, description should clarify return format, but it does not. For a simple fetch tool, this is adequate but could be more complete by noting output structure or listing default behavior.
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 clear parameter descriptions. Description does not add additional semantics beyond what the schema already provides, 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?
Description clearly states verb ('Fetch'), resource ('cards from a specific Trello list on a specific board'), and distinguishes from sibling tools like add_card_to_list or archive_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?
Description implies usage when you need cards from a list but lacks explicit when-to-use or when-not-to-use guidance. No alternatives mentioned, though context is implicit from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all lists from the specified board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only operation ('Retrieve') but does not confirm idempotency, error handling, or behavior when boardId is missing. The description is too 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?
One sentence, clear and to the point. Could be slightly more structured (e.g., mentioning that it returns an array of list objects), but overall efficient.
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 no output schema, the description is adequate. It explains what the tool does, though it omits details about the return format and potential errors.
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 (boardId). The description adds no additional meaning beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the resource ('all lists'), and the context ('from the specified board'). It distinguishes from sibling tools like add_list_to_board and archive_list, which are mutation operations.
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 vs alternatives, such as get_cards_by_list_id or get_active_board_info. Lacks context like prerequisites or typical workflow integration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch all cards assigned to the current user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It declares a read operation but does not disclose scope (e.g., active board only), user definition, or return format. Lacks detail on 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?
A single, concise sentence with no wasted words. Front-loaded and efficient.
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 no parameters and no output schema, the description is mostly complete. However, it could add context about board scope or user definition. Still, it adequately conveys the core function.
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 zero parameters; the schema is fully covered. The description does not need to add param details. Baseline score of 4 is appropriate as it is clear no input is required.
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 fetches cards assigned to the current user. The verb 'Fetch' and resource 'cards' are specific, and it distinguishes from sibling tools like 'get_cards_by_list_id' which fetches by 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?
The description implies usage for getting personal cards but lacks explicit when-to-use or when-not-to guidance compared to siblings like 'get_cards_by_list_id' or 'get_active_board_info'. No alternatives 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.
Fetch recent activity on the Trello board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| limit | No | Number of activities to fetch (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'Fetch recent activity'. It does not disclose read-only nature, pagination behavior, types of activities included, or any side effects. The description carries full burden but 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?
Single sentence that is front-loaded and waste-free. Efficiently communicates the core action.
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?
No output schema; description does not clarify return format, default behavior of optional parameters, or what constitutes 'activity'. Incomplete for a list-fetching tool with no annotations.
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 both parameters (boardId, limit). The description adds no additional 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 clearly states the tool fetches recent activity on the Trello board, using a specific verb and resource. It distinguishes from siblings like 'get_card_history' (card-specific) and 'get_lists' (list data), though no explicit differentiation is provided.
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 such as 'get_card_history' or 'get_my_cards'. No mention of prerequisites, board context, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all boards the user has access to
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read-like operation but does not explicitly confirm safety, mention rate limits, permissions, or potential side effects. The behavioral disclosure is 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?
The description is a single sentence, efficiently stating the tool's purpose without extraneous words. However, it could include additional context without sacrificing 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 tool lists boards with no parameters and no output schema, the description fails to inform the agent about the response format, pagination, or how results are structured. In a context with many sibling tools, more guidance would be beneficial.
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 tool has no parameters (0 params, schema coverage 100%). Although the description adds no parameter details, it is not necessary given the absence of parameters. The baseline score for 0 parameters is 4, and the description adequately indicates the tool's purpose.
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 'List all boards the user has access to' clearly identifies the action (list), resource (boards), and scope (all the user has access to). It effectively distinguishes this tool from its sibling 'list_boards_in_workspace', which implies workspace 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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or specific contexts where 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.
List all boards in a specific workspace
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | Yes | ID of the workspace to list boards from |
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 states 'list all boards' but does not mention that the operation is read-only, any authentication requirements, rate limits, or what the response contains. This is a significant gap for a tool with no annotation support.
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 unnecessary words. It front-loads the action and scope effectively.
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 simplicity of the tool (one required param, no output schema), the description is minimally adequate. It could be improved by mentioning what the output looks like (e.g., list of board names/IDs) or whether there is pagination, but it is not critically incomplete.
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 the phrase 'in a specific workspace', which weakly echoes the schema's workspaceId description. It does not add new semantic meaning or constraints 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 verb 'list' and the resource 'boards' scoped to a workspace. While it distinguishes from siblings like 'list_boards' (which likely lists all boards) and 'list_workspaces', it does not explicitly contrast with these alternatives.
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 the user wants boards from a specific workspace (via workspaceId). However, it lacks explicit when-to-use or when-not-to-use guidance and does not mention alternatives like 'list_boards' for cross-workspace needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all workspaces the user has access to
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states it lists workspaces but does not detail any potential side effects, pagination, ordering, or access constraints. For a simple read-only tool, this is adequate but not exemplary.
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 is front-loaded and contains no extraneous information. Every word serves a 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?
Given no parameters, no output schema, and no annotations, the description fully covers what is needed to invoke the tool correctly. It specifies the scope ('the user has access to') which 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?
The input schema is empty with 100% coverage. According to guidelines, when schema_description_coverage is high, baseline is 3. The description does not add any parameter information because there are none, and this is sufficient.
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 uses a specific verb 'List' and resource 'workspaces', and it is clearly distinct from sibling tools which focus on boards, cards, lists, and labels. No ambiguity about what the tool does.
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 clearly states the tool lists all workspaces the user has access to. While no explicit 'when not to use' is given, the simplicity of the tool and lack of similar sibling tools make the usage implicit. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a card to a different list, potentially on a different board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the target Trello board (where the listId resides, uses default if not provided) | |
| cardId | Yes | ID of the card to move | |
| listId | Yes | ID of the target list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It only states the basic function, omitting details like permissions, side effects, or response format. This is insufficient 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?
Single sentence with no extraneous words. The essential information is presented 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?
Given the tool's simplicity, the description covers the core action. However, it lacks context on optional boardId behavior, success/failure indicators, or constraints. Somewhat adequate but not fully 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 description coverage is 100%, so the schema already documents all parameters. The description adds no extra parameter-level information beyond restating the purpose.
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: move a card to a different list, and adds the nuance of potentially cross-board movement. This distinguishes it from siblings like archive_card or update_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 explicit guidance on when to use this tool over alternatives (e.g., update_card_details for non-move changes). Usage context is implied by the name and description but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a member from a specific card
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| cardId | Yes | ID of the card to remove the member from | |
| memberId | Yes | ID of the member to remove from the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action without revealing error handling, idempotency, or consequences (e.g., what happens if the member is not on the card).
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 of 7 words, with no unnecessary information. It is front-loaded and efficient.
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 mutation tool with 3 parameters, no output schema, and no annotations, the description is too minimal. It omits details like default behavior for optional boardId, error conditions, and result indication, making it incomplete.
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 parameters are well-documented structurally. The description adds no additional meaning beyond parameter names, and the optional 'boardId' is not explained. 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 'Remove a member from a specific card' uses a specific verb and resource, clearly indicating what the tool does. It effectively distinguishes itself from the sibling tool 'assign_member_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 is given on when to use this tool versus alternatives, such as checking if the member is already assigned or using the sibling tool for assignment. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active board for future operations
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | ID of the board to set as active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It indicates a state mutation ('set') but does not disclose side effects such as whether the change is persistent, what happens to the previous active board, or any authentication requirements. This is insufficient for an agent to understand the behavior fully.
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 front-loads the core action. It contains no unnecessary words and is easy to parse. Every part earns its place.
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 minimal. It does not explain the importance of setting the active board for subsequent operations, nor does it clarify the tool's role in a workflow. More context would be beneficial.
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 parameter 'boardId' is fully described in the input schema with a clear description. The tool description adds no additional meaning beyond the schema, so it meets the baseline for a schema with 100% 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 tool's verb ('Set') and resource ('active board'), indicating its primary function. It distinguishes itself from siblings like 'get_active_board_info' and 'list_boards' by being the only tool that sets the active board. However, it could be more explicit about the meaning of 'active board' in the broader context.
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 before operations that depend on an active board but does not provide explicit guidance on when to use it, when not to use it, or mention any prerequisites or alternatives. No context is given about required prior actions or the effect on subsequent tool calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active workspace for future operations
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | Yes | ID of the workspace to set as active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses a state change ('set active') but lacks details on side effects, reversibility, or persistence. Minimal behavioral 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?
Single sentence with no superfluous words. Every word serves a purpose, making it highly concise and 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's simplicity (1 param, no output schema, no annotations), the description is mostly complete. It could mention what 'future operations' are affected, but overall it adequately covers the tool's basic behavior.
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 covers 100% of parameters, and the schema already describes workspaceId. The description adds no extra meaning beyond the schema, meeting the baseline but not exceeding it.
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 ('Set') and resource ('active workspace'), and includes scope ('for future operations'). This distinguishes it from siblings like 'list_workspaces' and 'set_active_board', making purpose unambiguous.
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 when to use (before operations needing workspace context) but provides no explicit guidance on when not to use or alternatives. No siblings are mentioned for contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing card's details on a specific board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| cardId | Yes | ID of the card to update | |
| name | No | New name for the card | |
| description | No | New description for the card | |
| dueDate | No | New due date for the card (ISO 8601 format) | |
| labels | No | New array of label IDs for the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description must disclose behavioral traits. It merely implies mutation but does not specify permissions, reversibility, side effects, or whether updates are partial. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (one sentence) but lacks important details. It is not wasteful, but 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?
With 6 parameters, 1 required, no output schema, and no annotations, the description is minimal. It fails to explain behavior like partial updates, error handling, or required 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 each parameter. The description adds no additional meaning beyond what the schema provides, meeting the baseline expectation.
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 ('Update'), the resource ('an existing card's details'), and context ('on a specific board'). It is specific and distinct from sibling tools like 'move_card' or 'update_label'.
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, or when not to use it. Does not mention prerequisites or conditions for updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing label
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | ID of the Trello board (uses default if not provided) | |
| labelId | Yes | ID of the label to update | |
| name | No | New name for the label | |
| color | No | New color for the label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Update' implies mutation but provides no details on side effects, required permissions, or behavior when parameters are omitted.
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 brief (three words). While concise, it sacrifices helpful context that could be provided in a slightly longer form.
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 4 parameters, no output schema, and no annotations. The description is too minimal to adequately guide an agent on usage, return values, or 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?
Schema description coverage is 100%, so the schema already documents all parameters. 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.
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 label, distinguishing it from sibling tools like create_label and delete_label. However, it does not specify which properties can be updated.
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 such as create_label or other update tools. The description lacks context on prerequisites or best practices.
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.4add_card_to_listadd_list_to_boardarchive_cardarchive_listassign_member_to_cardattach_image_to_cardcreate_labeldelete_labelget_active_board_infoget_board_labelsget_board_membersget_card_historyget_cards_by_list_idget_listsget_my_cardsget_recent_activitylist_boardslist_boards_in_workspacelist_workspacesmove_cardremove_member_from_cardset_active_boardset_active_workspaceupdate_card_detailsupdate_labelMost tools have distinct purposes, but some overlap exists, e.g., between get_cards_by_list_id and get_my_cards, or get_card_history and get_recent_activity. Descriptions help differentiate but minor ambiguity remains.
Most tool names follow a verb_noun pattern (e.g., add_card_to_list, archive_list). However, there are minor deviations like get_active_board_info (verb_adjective_noun) and get_cards_by_list_id (preposition). Overall consistent.
With 25 tools, the server covers a broad Trello domain but feels slightly heavy. Most tools are justified, though some could be combined (e.g., get_board_members vs assign/remove). Still reasonable.
Covers key CRUD for boards, lists, cards, labels, and members. Notable gaps: no tool to delete a board, list, or card (only archive), and no unarchive operation. Missing update board/list details.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Manage Kanera workspaces, boards, cards, checklists, comments, notes, automations, and reports.
Manage projects, tasks, time tracking, and team collaboration through natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Infall-Insurance/mcp-server-trello'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
