模型上下文协议 (MCP) 服务器，提供与 Trello API 交互的工具。基于通用 MCP 服务器模板构建。
Trello 集成：完全访问 Trello 板、列表、卡片等
全面的 API 覆盖：支持所有主要的 Trello 操作
模块化架构：通过定义明确的结构明确地分离关注点
类型安全：完全支持 TypeScript，并为 Trello 对象提供正确的类型
错误处理：整个代码库的强大错误管理
Related MCP server: Trello MCP Server
trello-mcp-server/
├── src/
│ ├── services/ # Service classes for Trello API interactions
│ │ ├── base-service.ts # Abstract base service with common functionality
│ │ ├── trello-service.ts # Core Trello API service
│ │ ├── board-service.ts # Service for Trello boards
│ │ ├── list-service.ts # Service for Trello lists
│ │ ├── card-service.ts # Service for Trello cards
│ │ ├── member-service.ts # Service for Trello members
│ │ ├── label-service.ts # Service for Trello labels
│ │ ├── checklist-service.ts # Service for Trello checklists
│ │ └── service-factory.ts # Factory for creating service instances
│ ├── tools/ # MCP tool definitions and handlers
│ │ ├── board-tools.ts # Board tool definitions
│ │ ├── board-tool-handlers.ts # Board tool handlers
│ │ ├── list-tools.ts # List tool definitions
│ │ ├── list-tool-handlers.ts # List tool handlers
│ │ ├── card-tools.ts # Card tool definitions
│ │ ├── card-tool-handlers.ts # Card tool handlers
│ │ ├── member-tools.ts # Member tool definitions
│ │ ├── member-tool-handlers.ts # Member tool handlers
│ │ ├── label-tools.ts # Label tool definitions
│ │ ├── label-tool-handlers.ts # Label tool handlers
│ │ ├── checklist-tools.ts # Checklist tool definitions
│ │ ├── checklist-tool-handlers.ts # Checklist tool handlers
│ │ ├── trello-tools.ts # Combined tool definitions
│ │ └── trello-tool-handlers.ts # Combined tool handlers
│ ├── types/ # TypeScript type definitions
│ │ └── trello-types.ts # Trello type definitions
│ ├── config.ts # Configuration management
│ └── index.ts # Main entry point
├── .env.example # Example environment variables
├── package.json # Project dependencies and scripts
├── tsconfig.json # TypeScript configuration
└── README.md # Project documentationNode.js 18 或更高版本
npm 或 yarn
Trello API 密钥和令牌
克隆此存储库：
git clone https://github.com/yourusername/trello-mcp-server.git
cd trello-mcp-server安装依赖项：
npm install根据.env.example创建.env文件：
cp .env.example .env使用您的 Trello API 密钥和令牌编辑.env文件：
TRELLO_API_KEY=your_trello_api_key
TRELLO_TOKEN=your_trello_token您可以从Trello 开发者门户获取这些。
构建项目：
npm run build运行服务器：
npm start该服务器提供与所有主要 Trello 资源交互的工具：
get_boards - 获取已验证用户的所有板块
get_board - 通过 ID 获取特定板
create_board创建新的板
update_board - 更新现有板
delete_board - 删除一个板
get_board_lists - 获取板上的所有列表
get_board_members - 获取董事会的所有成员
get_board_labels - 获取板上的所有标签
close_board - 关闭（存档）一个板块
reopen_board - 重新打开已关闭的面板
get_list - 通过 ID 获取特定列表
create_list - 在板上创建新列表
update_list - 更新现有列表
archive_list - 存档列表
unarchive_list - 取消归档列表
move_list_to_board - 将列表移动到另一个板
get_cards_in_list - 获取列表中的所有卡片
archive_all_cards - 存档列表中的所有卡片
move_all_cards - 将列表中的所有卡片移动到另一个列表
update_list_position - 更新板上列表的位置
update_list_name - 更新列表的名称
subscribe_to_list - 订阅列表
get_card - 根据 ID 获取特定卡
create_card - 创建一张新卡
update_card - 更新现有卡
delete_card - 删除卡片
archive_card - 存档卡片
unarchive_card - 取消存档卡片
move_card_to_list - 将卡片移动到不同的列表
add_comment - 向卡片添加评论
get_comments - 获取卡片上的评论
add_attachment - 将附件添加到卡片
get_attachments - 获取卡片上的附件
delete_attachment - 从卡片中删除附件
add_member - 将会员添加到卡片
remove_member - 从卡片中删除会员
add_label - 为卡片添加标签
remove_label - 从卡片中删除标签
set_due_date - 设置卡片到期日期
set_due_complete - 将卡片的到期日标记为完成或未完成
get_me - 获取已验证的成员（当前用户）
get_member - 通过 ID 或用户名获取特定成员
get_member_boards - 获取成员所属的板块
get_member_cards - 获取分配给会员的卡
get_boards_invited - 获取成员受邀加入的论坛
get_member_organizations - 获取成员所属的组织
get_notifications - 获取已验证会员的通知
update_me - 更新已认证会员的信息
get_avatar - 获取已认证会员的头像
search_members - 按姓名搜索成员
get_board_members - 获取董事会成员
get_organization_members - 获取组织成员
get_card_members - 获取分配给卡片的成员
get_label - 通过 ID 获取特定标签
create_label - 在板上创建新标签
update_label - 更新现有标签
delete_label - 删除标签
get_board_labels - 获取板上的所有标签
update_label_name - 更新标签名称
update_label_color - 更新标签的颜色
create_label_on_card - 直接在卡片上创建新标签
get_card_labels - 获取卡片上的所有标签
add_label_to_card - 向卡片添加标签
remove_label_from_card - 从卡片中删除标签
get_checklist - 通过 ID 获取特定清单
create_checklist - 在卡片上创建新的清单
update_checklist - 更新现有清单
delete_checklist - 删除清单
get_checkitems - 获取清单上的所有检查项
create_checkitem - 在清单上创建一个新的检查项
get_checkitem - 获取清单上的特定检查项
update_checkitem - 更新清单上的检查项
delete_checkitem - 从清单中删除检查项
update_checklist_name - 更新清单的名称
update_checklist_position - 更新卡片上清单的位置
get_checklist_board - 获取清单所在的板
get_checklist_card - 获取清单所在的卡片
update_checkitem_state_on_card - 更新卡片上的检查项状态
服务器使用src/config.ts中的集中式配置系统。可以通过以下方式提供配置：
环境变量
命令行参数（使用--env KEY=VALUE ）
代码中的默认值
所需的环境变量：
TRELLO_API_KEY - 您的 Trello API 密钥
TRELLO_TOKEN - 您的 Trello API 令牌
该服务器包括全面的错误处理：
具有速率限制支持的服务级错误处理
使用适当的错误消息进行工具级错误处理
MCP 协议错误处理
Trello API 错误处理
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | ID of the card to comment on | |
| text | Yes | Comment text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| comments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | ID of the card to add the label to | |
| labelId | Yes | ID of the label to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | ID of the card to archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cardIds | Yes | IDs of the cards to archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No | ||
| listId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | ID of the board to create the label in | |
| name | Yes | Name of the label | |
| color | Yes | Color of the label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| labels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | ID of the Trello board to get lists from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| listId | Yes | ID of the list to get tickets from | |
| limit | No | Maximum number of cards to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | ID of the card to move | |
| listId | Yes | ID of the destination list | |
| position | No | Position in the list (e.g. "top", "bottom") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v1.0.0get-boards1 field changedInput schema / additionalPropertiesRemoved value: -falseadd-commentadd-commentsadd-labeladd-labelsarchive-cardarchive-cardscreate-cardcreate-cardscreate-labelcreate-labelsget-boardsget-listsget-tickets-by-listmove-cardmove-cardsScored across 15 tools
Multiple tools have unclear boundaries due to singular/plural pairs that create ambiguity (e.g., add-comment vs add-comments, create-card vs create-cards). An agent cannot reliably determine when to use the singular vs plural version since descriptions are missing, making tool selection confusing. However, core actions like archive-card, move-card, and get-boards are distinct in purpose.
All tool names follow a consistent verb-noun pattern with hyphen-separated lowercase words (e.g., add-comment, get-boards, move-card). There are no deviations in style or convention, making the naming predictable and readable throughout the set.
With 15 tools, the count is reasonable for a Trello server that needs to manage boards, lists, cards, labels, and comments. It is slightly on the higher side but well-scoped for the domain, covering key operations without being excessive.
The tool set covers core CRUD operations for cards, labels, and comments, but there are notable gaps. For example, there are no tools for updating or deleting cards/labels/comments, and operations for managing board settings or user permissions are missing. This limits full lifecycle coverage in the Trello domain.
Read teams, spaces, lists and tasks; create, update and comment on tasks and track time.
Read and update Markboard kanban boards: cards, checklists, labels, comments and files.
Create and drive KanbanThing kanban boards. No account, no API key, board link required.
Read your TeamShift team, tasks and memory via OAuth, or use workspace tools with an API key.
