Trello API と連携するためのツールを提供するモデルコンテキストプロトコル (MCP) サーバー。汎用 MCP サーバーテンプレートに基づいて構築されています。
Trello 統合: Trello ボード、リスト、カードなどへの完全なアクセス
包括的なAPIカバレッジ：すべての主要なTrello操作をサポート
モジュラーアーキテクチャ：明確に定義された構造による関心事の明確な分離
型安全性: Trello オブジェクトの適切な型付けによる完全な TypeScript サポート
エラー処理: コードベース全体にわたる堅牢なエラー管理
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 .envTrello 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.
