Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona herramientas para interactuar con la API de Trello. Desarrollado sobre la plantilla genérica de servidor MCP.
Integración con Trello : acceso completo a tableros, listas, tarjetas y más de Trello
Cobertura completa de API : soporte para todas las operaciones principales de Trello
Arquitectura modular : clara separación de preocupaciones con una estructura bien definida
Seguridad de tipos : compatibilidad total con TypeScript con tipos adecuados para objetos de Trello
Manejo de errores : gestión robusta de errores en todo el código base
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 o superior
npm o hilo
Clave API y token de Trello
Clonar este repositorio:
git clone https://github.com/yourusername/trello-mcp-server.git
cd trello-mcp-serverInstalar dependencias:
npm installCree un archivo .env basado en .env.example :
cp .env.example .envEdite el archivo .env con su clave API y token de Trello:
TRELLO_API_KEY=your_trello_api_key
TRELLO_TOKEN=your_trello_tokenPuede obtenerlos desde el Portal para desarrolladores de Trello .
Construir el proyecto:
npm run buildEjecutar el servidor:
npm startEl servidor proporciona herramientas para interactuar con todos los recursos principales de Trello:
get_boards - Obtener todos los tableros para el usuario autenticado
get_board - Obtener un tablero específico por ID
create_board - Crea un nuevo tablero
update_board - Actualizar un tablero existente
delete_board - Eliminar un tablero
get_board_lists - Obtener todas las listas de un tablero
get_board_members - Obtener todos los miembros de un tablero
get_board_labels - Obtener todas las etiquetas de un tablero
close_board - Cerrar (archivar) un tablero
reopen_board - Reabrir un tablero cerrado
get_list - Obtener una lista específica por ID
create_list - Crea una nueva lista en un tablero
update_list - Actualizar una lista existente
archive_list - Archivar una lista
unarchive_list - Desarchivar una lista
move_list_to_board - Mover una lista a un tablero diferente
get_cards_in_list - Obtener todas las tarjetas en una lista
archive_all_cards - Archivar todas las tarjetas en una lista
move_all_cards - Mover todas las tarjetas de una lista a otra lista
update_list_position - Actualizar la posición de una lista en un tablero
update_list_name - Actualizar el nombre de una lista
subscribe_to_list - Suscribirse a una lista
get_card - Obtener una tarjeta específica por ID
create_card - Crea una nueva tarjeta
update_card - Actualizar una tarjeta existente
delete_card - Eliminar una tarjeta
archive_card - Archivar una tarjeta
unarchive_card - Desarchivar una tarjeta
move_card_to_list - Mover una tarjeta a una lista diferente
add_comment - Agregar un comentario a una tarjeta
get_comments - Obtener comentarios en una tarjeta
add_attachment - Agregar un archivo adjunto a una tarjeta
get_attachments - Obtener archivos adjuntos en una tarjeta
delete_attachment - Eliminar un archivo adjunto de una tarjeta
add_member - Agregar un miembro a una tarjeta
remove_member - Eliminar un miembro de una tarjeta
add_label - Agregar una etiqueta a una tarjeta
remove_label - Quitar una etiqueta de una tarjeta
set_due_date - Establece la fecha de vencimiento de una tarjeta
set_due_complete - Marcar la fecha de vencimiento de una tarjeta como completa o incompleta
get_me - Obtener el miembro autenticado (usuario actual)
get_member - Obtener un miembro específico por ID o nombre de usuario
get_member_boards - Obtener los tableros a los que pertenece un miembro
get_member_cards - Obtener las tarjetas asignadas a un miembro
get_boards_invited - Obtener los tableros a los que un miembro ha sido invitado
get_member_organizations - Obtener las organizaciones a las que pertenece un miembro
get_notifications - Recibir notificaciones para el miembro autenticado
update_me - Actualizar la información del miembro autenticado
get_avatar - Obtener el avatar del miembro autenticado
search_members - Buscar miembros por nombre
get_board_members - Obtener miembros de un tablero
get_organization_members - Obtener miembros de una organización
get_card_members - Obtener los miembros asignados a una tarjeta
get_label - Obtener una etiqueta específica por ID
create_label - Crea una nueva etiqueta en un tablero
update_label - Actualizar una etiqueta existente
delete_label - Eliminar una etiqueta
get_board_labels - Obtener todas las etiquetas de un tablero
update_label_name - Actualizar el nombre de una etiqueta
update_label_color - Actualizar el color de una etiqueta
create_label_on_card - Crea una nueva etiqueta directamente en una tarjeta
get_card_labels - Obtener todas las etiquetas de una tarjeta
add_label_to_card - Agregar una etiqueta a una tarjeta
remove_label_from_card - Quitar una etiqueta de una tarjeta
get_checklist - Obtener una lista de verificación específica por ID
create_checklist - Crea una nueva lista de verificación en una tarjeta
update_checklist - Actualizar una lista de verificación existente
delete_checklist - Eliminar una lista de verificación
get_checkitems - Obtener todos los elementos de verificación en una lista de verificación
create_checkitem - Crea un nuevo elemento de verificación en una lista de verificación
get_checkitem - Obtener un elemento de verificación específico en una lista de verificación
update_checkitem - Actualizar un elemento de verificación en una lista de verificación
delete_checkitem - Eliminar un elemento de verificación de una lista de verificación
update_checklist_name - Actualizar el nombre de una lista de verificación
update_checklist_position - Actualizar la posición de una lista de verificación en una tarjeta
get_checklist_board - Obtener el tablero en el que se encuentra una lista de verificación
get_checklist_card - Obtener la tarjeta en la que se encuentra una lista de verificación
update_checkitem_state_on_card - Actualizar el estado de un elemento de verificación en una tarjeta
El servidor utiliza un sistema de configuración centralizado en src/config.ts . La configuración se puede realizar mediante:
Variables de entorno
Argumentos de la línea de comandos (con --env KEY=VALUE )
Valores predeterminados en el código
Variables de entorno requeridas:
TRELLO_API_KEY - Tu clave API de Trello
TRELLO_TOKEN - Su token de API de Trello
El servidor incluye un manejo integral de errores:
Manejo de errores a nivel de servicio con soporte de limitación de velocidad
Manejo de errores a nivel de herramienta con mensajes de error adecuados
Manejo de errores del protocolo MCP
Manejo de errores de la API de Trello
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
| 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.
