Trello API와 상호 작용하기 위한 도구를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 일반 MCP 서버 템플릿을 기반으로 구축되었습니다.
Trello 통합 : Trello 보드, 목록, 카드 등에 대한 완벽한 액세스
포괄적인 API 범위 : 모든 주요 Trello 작업 지원
모듈형 아키텍처 : 명확하게 정의된 구조를 통해 관심사를 명확하게 분리
유형 안전성 : Trello 객체에 대한 적절한 타이핑을 통한 전체 TypeScript 지원
오류 처리 : 코드베이스 전체에 걸친 강력한 오류 관리
Related MCP server: Trello MCP Server
지엑스피1
Node.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_tokenTrello 개발자 포털 에서 해당 정보를 얻을 수 있습니다.
프로젝트를 빌드하세요:
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 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
| 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.
