Trelloボードを操作するためのツールを提供するModel Context Protocol（MCP）サーバー。このサーバーは、レート制限、型安全性、エラー処理を自動的に処理しながら、Trello APIとのシームレスな統合を実現します。
Trelloボードとの完全な統合：カード、リスト、ボードアクティビティを操作
組み込みのレート制限: Trello の API 制限 (API キーあたり 300 リクエスト/10 秒、トークンあたり 100 リクエスト/10 秒) を尊重
型安全な実装:包括的な型定義を備えたTypeScriptで記述
入力検証: すべてのAPI入力に対する堅牢な検証
エラー処理: 情報メッセージによる適切なエラー処理
Related MCP server: MCP Trello
npm install @modelcontextprotocol/mcp-server-trello次の構成でサーバーを MCP 設定ファイルに追加します。
{
"mcpServers": {
"trello": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-trello"],
"env": {
"TRELLO_API_KEY": "your-api-key",
"TRELLO_TOKEN": "your-token",
"TRELLO_BOARD_ID": "your-board-id"
}
}
}
}TRELLO_API_KEY : Trello API キー ( https://trello.com/app-keyから取得)
TRELLO_TOKEN : Trelloトークン（APIキーを使用して生成）
TRELLO_BOARD_ID : 対話するTrelloボードのID（ボードURLで見つかります）
特定のリストからすべてのカードを取得します。
{
name: 'get_cards_by_list_id',
arguments: {
listId: string // ID of the Trello list
}
}設定されたボードからすべてのリストを取得します。
{
name: 'get_lists',
arguments: {}
}ボード上の最近のアクティビティを取得します。
{
name: 'get_recent_activity',
arguments: {
limit?: number // Optional: Number of activities to fetch (default: 10)
}
}指定されたリストに新しいカードを追加します。
{
name: 'add_card_to_list',
arguments: {
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
}
}既存のカード詳細を更新します。
{
name: 'update_card_details',
arguments: {
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
}
}カードをアーカイブに送信します。
{
name: 'archive_card',
arguments: {
cardId: string // ID of the card to archive
}
}ボードに新しいリストを追加します。
{
name: 'add_list_to_board',
arguments: {
name: string // Name of the new list
}
}リストをアーカイブに送信します。
{
name: 'archive_list',
arguments: {
listId: string // ID of the list to archive
}
}現在のユーザーに割り当てられているすべてのカードを取得します。
{
name: 'get_my_cards',
arguments: {}
}サーバーは、Trello の API 制限に準拠するために、レート制限用のトークン バケット アルゴリズムを実装します。
APIキーごとに10秒あたり300リクエスト
トークンごとに10秒あたり100リクエスト
レート制限は自動的に処理され、制限に達した場合、リクエストはキューに入れられます。
サーバーは、さまざまなシナリオに対して詳細なエラー メッセージを提供します。
無効な入力パラメータ
レート制限を超えました
API認証エラー
ネットワークの問題
無効なボード/リスト/カードID
Node.js 16以上
npmまたはyarn
リポジトリをクローンする
git clone https://github.com/modelcontextprotocol/server-trello.git
cd server-trello依存関係をインストールする
npm installプロジェクトを構築する
npm run buildnpm test貢献を歓迎します！行動規範とプルリクエストの送信手順の詳細については、貢献ガイドをお読みください。
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。
Trello REST APIを使用します
Add a new card to a specified list
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | |
| listId | Yes | ID of the list to add the card to | |
| name | Yes | Name of the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds a card but lacks details on permissions required, whether the operation is idempotent, error handling, or what happens on success (e.g., returns a card ID). This is a significant gap for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste—it directly states the tool's purpose without fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, return values, or error conditions, which are critical for an agent to use this tool effectively in context with its siblings.
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 5 parameters thoroughly. The description adds no parameter-specific information beyond what the schema provides, such as explaining relationships between fields or usage tips. Baseline 3 is appropriate when the schema does the heavy lifting.
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 a new card') and target resource ('to a specified list'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'update_card_details' or 'archive_card' beyond the basic verb, missing explicit distinction in scope or purpose.
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. It doesn't mention prerequisites (e.g., needing a list ID), exclusions, or comparisons to siblings like 'update_card_details' for modifying existing cards or 'get_cards_by_list_id' for retrieval, leaving usage context implied at best.
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 board
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't cover permissions needed, whether the list is editable after creation, error conditions, or what happens if a duplicate name is used, leaving significant gaps 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?
The description is a single, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for a simple tool, earning full marks for 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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral context, error handling, or return values, making it inadequate for safe and effective use by an AI agent.
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 the 'name' parameter fully. The description adds no additional meaning beyond implying a list is created, aligning with the baseline score when schema does the heavy lifting.
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 ('add') and resource ('new list to the board'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_card_to_list' or 'archive_list', which also modify board components, so it misses full sibling distinction.
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. It doesn't mention prerequisites (e.g., needing an existing board), exclusions, or comparisons to siblings like 'get_lists' for listing or 'archive_list' for removal.
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
| 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Send a card to the archive' implies a destructive/mutative operation, but it doesn't specify whether this is reversible, what permissions are required, whether it affects related data, or what happens after archiving. The description lacks critical behavioral context 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?
The description is perfectly concise at just four words, front-loading the essential action without any wasted words. Every element ('Send', 'a card', 'to the archive') earns its place by conveying core functionality.
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 no annotations and no output schema, the description is insufficiently complete. It doesn't address what 'archive' means operationally, whether the action is permanent or reversible, what the expected outcome is, or how this fits within the broader card management workflow with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'cardId' clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage but doesn't enhance understanding.
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') and target resource ('a card to the archive'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'archive_list' or explain what distinguishes archiving from deletion or other card 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., card must exist), when archiving is appropriate versus deleting or moving cards, or how this relates to sibling tools like 'update_card_details' or 'get_my_cards'.
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
| Name | Required | Description | Default |
|---|---|---|---|
| listId | Yes | ID of the list to archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether archiving is reversible, requires specific permissions, affects related data, or has side effects, leaving significant gaps 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?
The description is a single, direct sentence with zero wasted words, efficiently conveying the core action. It is appropriately sized for a simple tool and front-loaded with essential information.
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 no annotations and no output schema, the description is insufficient. It lacks details on behavior, outcomes, error conditions, or integration with sibling tools, failing to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'listId' clearly documented in the schema. The description adds no additional parameter context beyond implying 'listId' is needed, meeting the baseline for high schema coverage without extra value.
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') and target resource ('a list to the archive'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'archive_card' or specify what 'archive' means in this context, preventing a perfect score.
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 like 'archive_card' or other list-related operations. The description lacks context about prerequisites, consequences, or typical use cases, offering minimal practical direction.
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
| Name | Required | Description | Default |
|---|---|---|---|
| listId | Yes | ID of the Trello list |
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 the tool fetches cards but doesn't describe what 'fetch' entails—e.g., whether it returns all cards, supports pagination, requires authentication, or has rate limits. For a read operation with zero annotation coverage, this leaves critical behavioral traits unspecified.
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 zero wasted words. It front-loads the core purpose ('Fetch cards') and specifies the scope ('from a specific Trello list'), making it efficient and easy to parse. Every word earns its place 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 simple read tool with one parameter and no output schema, the description is minimally adequate but incomplete. It lacks behavioral details (e.g., response format, error handling) and usage context, which are important given no annotations. However, the purpose is clear, and the parameter is well-documented in the schema, making it functional but with gaps.
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 description coverage is 100%, with the single parameter 'listId' documented as 'ID of the Trello list'. The description adds no additional meaning beyond this, such as format examples or where to obtain the ID. Given high schema coverage, the baseline score of 3 is appropriate, as the schema adequately covers parameter semantics.
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 ('Fetch') and target resource ('cards from a specific Trello list'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_my_cards' or 'get_recent_activity' that also retrieve cards or activity data, leaving some ambiguity about when to choose this specific tool.
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. It doesn't mention prerequisites, context for selecting this over siblings like 'get_my_cards' (which might fetch cards across lists), or any constraints on usage. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all lists from the specified board
| 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 the full burden of behavioral disclosure. It states the tool retrieves data, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error conditions, or what happens if no lists exist. This leaves significant gaps for a tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., list format, fields included) or address behavioral aspects like pagination or error handling. For a data retrieval tool with no structured support, this leaves too many unknowns for effective use.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't add parameter details beyond what the schema provides, earning a baseline score of 4 for zero-parameter tools as per the rules.
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') and resource ('all lists from the specified board'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_cards_by_list_id' or 'get_my_cards', which also retrieve data but target different resources.
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. It doesn't mention prerequisites (e.g., needing a board context), exclusions, or comparisons to sibling tools like 'get_recent_activity' for different data types. Usage is implied by the action but not explicitly stated.
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 |
|---|---|---|---|
| limit | No | Number of activities to fetch (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'fetch' implies a read operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'recent activity' entails (e.g., time range, types of activities). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 and no output schema, the description is incomplete for a tool that fetches data. It lacks details on return format, error cases, or behavioral traits, which are crucial for an agent to use the tool effectively in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'limit' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as constraints or examples, so it meets the baseline for high schema coverage without extra value.
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 ('fetch') and resource ('recent activity on the Trello board'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'get_cards_by_list_id' or 'get_my_cards', which also retrieve data but focus on different resources, so it misses full sibling differentiation.
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. The description doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone, which is insufficient for optimal selection.
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
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes | ID of the card to update | |
| 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 | |
| name | No | New name for the card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update an existing card's details,' which implies a mutation operation, but fails to mention critical aspects like required permissions, whether updates are reversible, potential side effects (e.g., notifications), or rate limits. This leaves significant gaps for an agent to understand the tool's behavior safely.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 complexity of a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., permissions, side effects), usage context, and what the tool returns, leaving the agent with insufficient guidance for safe and effective invocation.
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 description coverage is 100%, with each parameter clearly documented in the input schema (e.g., 'cardId' as ID, 'dueDate' in ISO 8601 format). The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('Update') and resource ('an existing card's details'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'archive_card' or 'add_card_to_list' beyond the general 'update' action, which is why it doesn't reach a perfect score.
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. For example, it doesn't mention prerequisites (e.g., needing the card ID), when not to use it (e.g., for archiving vs. updating), or how it relates to siblings like 'archive_card' or 'get_cards_by_list_id' for retrieval before updating.
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.0add_card_to_listadd_list_to_boardarchive_cardarchive_listget_cards_by_list_idget_listsget_my_cardsget_recent_activityupdate_card_detailsScored across 9 tools
Each tool has a clearly distinct purpose with no ambiguity: adding cards/lists, archiving cards/lists, fetching cards by list/board/user, getting activity, and updating cards. The descriptions reinforce this by specifying unique actions on different Trello entities.
The naming is mostly consistent with a verb_noun pattern (e.g., add_card_to_list, archive_card, get_cards_by_list_id), but there are minor deviations like 'get_my_cards' (which could be 'get_cards_by_user' for full consistency) and 'get_recent_activity' (which doesn't follow the verb_noun structure as tightly).
With 9 tools, this is well-scoped for a Trello server, covering core operations like CRUD for cards and lists, archiving, and activity tracking. Each tool earns its place without feeling excessive or insufficient for managing Trello boards.
The toolset provides strong coverage for Trello's domain, including create (add_card_to_list, add_list_to_board), read (get_cards_by_list_id, get_lists, get_my_cards, get_recent_activity), update (update_card_details), and delete/archive (archive_card, archive_list). A minor gap is the lack of a tool to update list details, but agents can work around this.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
One gateway, every app: Gmail, GitHub, Notion and more. Connect once, call any tool. Managed auth.
Kanban tasks and project notes for AI clients, with OAuth and per-project read or write grants.