Trello MCP

Conecta Claude (Desktop/Cowork y Claude Code) a un tablero de Trello.

El tablero se elige mediante board_id en tu configuración; nada sobre un tablero específico está codificado.

~/mcp-servers/trello-mcp/
    trello_mcp.py     the server — no credentials inside, safe to share
    requirements.txt  mcp==1.27.2 (pinned, see below)
    .venv/            dedicated Python 3.12 environment
~/.config/trello-mcp/config.json   credentials (chmod 600, never shared)

Registrado en ambos:

• ~/Library/Application Support/Claude/claude_desktop_config.json (Desktop/Cowork)

• ~/.claude.json (Claude Code)

Ambos apuntan al intérprete del venv absoluto. Eso es relevante — ver más abajo.

Por qué solía desconectarse cada mañana

La configuración antigua iniciaba el servidor con el comando simple python3. Hay cuatro binarios python3 en este Mac y solo uno tiene el paquete mcp:

A cuál apunta python3 depende del PATH del proceso que lanzó la aplicación. Lanzada desde Finder o al iniciar sesión, la aplicación hereda el PATH mínimo de launchd (/usr/bin:/bin:/usr/sbin:/sbin) y obtiene Python 3.9 → ModuleNotFoundError: No module named 'mcp' → "Trello MCP no se pudo conectar." Lanzada desde una terminal, hereda el PATH del shell donde Anaconda aparece primero → funciona. Por lo tanto: rota la mayoría de las mañanas, funciona bien cuando se prueba manualmente.

Reproducir el fallo anterior y la solución:

env -i PATH=/usr/bin:/bin:/usr/sbin:/sbin python3 "$HOME/Claude/Projects/Daily Trello/trello_mcp.py"   # ModuleNotFoundError
env -i PATH=/usr/bin:/bin:/usr/sbin:/sbin ~/mcp-servers/trello-mcp/.venv/bin/python3 -c "import mcp; print('ok')"  # ok

Nombrar el intérprete por ruta absoluta significa que no se realiza ninguna búsqueda de PATH. La aplicación inicia un binario conocido, que encuentra un directorio de paquetes conocido. El mismo resultado a las 7 AM que a las 7 PM.

Related MCP server: trello-mcp-server

Qué es realmente un venv (y contra qué no protege)

Python busca paquetes instalados en un directorio vinculado al intérprete específico en ejecución. Cuatro intérpretes = cuatro directorios de paquetes separados; mcp solo se instaló en uno. Un venv crea uno privado que pertenece únicamente a este servidor.

Técnicamente: python3 -m venv .venv crea .venv/bin/python3 y un pyvenv.cfg que registra la instalación base. Al iniciarse, el intérprete lee ese archivo y establece sys.prefix al venv, por lo que import resuelve a .venv/lib/python3.12/site-packages.

Limitación honesta: en macOS, venv enlaza simbólicamente el intérprete en lugar de copiarlo, y la biblioteca estándar aún se carga desde la instalación base:

.venv/bin/python3 -> /opt/anaconda3/bin/python3
stdlib             = /opt/anaconda3/lib/python3.12

Por lo tanto, este venv aún depende de que Anaconda esté instalado. Aísla paquetes, no el intérprete.

Reconstruir después de cualquiera de esos, ~15 segundos:

cd ~/mcp-servers/trello-mcp && rm -rf .venv
/path/to/any/python3.10+ -m venv .venv && ./.venv/bin/pip install -r requirements.txt

Si alguna vez deseas independencia real de Anaconda, instala uv y construye el venv desde un Python independiente gestionado por uv. No se hace aquí porque añade una nueva herramienta a la máquina.

No actualices ciegamente mcp

requirements.txt fija mcp==1.27.2. Esto es deliberado: mcp 2.0.0 eliminó la API de decoradores @app.list_tools() / @app.call_tool() en la que se basa este servidor. Instalar la última versión rompe el servidor instantáneamente con AttributeError: 'Server' object has no attribute 'list_tools' — que se ve exactamente como el fallo de conexión que todo este montaje pretendía solucionar. Actualiza solo junto con la reescritura de los manejadores para la nueva API.

Cómo funciona el archivo de credenciales

~/.config/trello-mcp/config.json:

{ "api_key": "...", "token": "...", "board_id": "676f0bfc11723d27f716291d" }

Nada alojado, ningún servicio externo — un archivo JSON ordinario en este disco. Dos cosas lo hacen "secreto":

1. Vive fuera del código, por lo que copiar o publicar trello_mcp.py no lleva credenciales.

2. chmod 600 — solo esta cuenta de usuario macOS puede leerlo.

El servidor lo lee al inicio y mantiene los valores en memoria. Para compartir el servidor, envía trello_mcp.py; el destinatario crea su propia configuración con su propia clave de Trello. El valor no es cifrado — es separar lo que compartes de lo que no compartes.

El token de Trello no tiene caducidad (dateExpires: null) y tiene permisos de lectura+escritura en Miembro/Tablero/Organización. A diferencia del token de actualización OAuth del servidor de Google Drive, no necesita re-autorización periódica.

Las listas nunca están codificadas

Cada lista se resuelve por nombre en el momento de la llamada contra la API en vivo, por lo que una lista añadida en Trello (una nueva clase cada trimestre) funciona inmediatamente — sin cambio de código, sin reinicio. Una caché de 60 segundos mantiene eso barato; un fallo de caché fuerza una reobtención antes de informar "no encontrada", por lo que una lista creada hace segundos aún se resuelve.

Medido en este tablero: una obtención de lista es ~307 ms. Sin la caché, cada llamada de herramienta la pagaba (get_cards cuesta dos viajes de ida y vuelta), por lo que una sesión de planificación de 12 tarjetas consumía ~3.7 s solo en reobtenciones. Con ella, una obtención cubre el pico.

Los únicos nombres de lista en el código son los tres anclajes de flujo de trabajo al inicio de trello_mcp.py:

LIST_TODO    = "To Do Today"
LIST_WORKING = "Working on"
LIST_DONE    = "Done Today"

Están nombrados porque la rutina diaria se define en términos de ellos (sort_todo_today no se puede decir "ordena la lista que significa hoy" sin un nombre). Cambia el nombre de uno en Trello → cámbialo en ese bloque y en el CLAUDE.md de Daily Trello. rename_list te advierte cuando cambias el nombre de un anclaje.

Herramientas (37)

Lectura — get_all_lists, get_cards (incluye archivos adjuntos, etiquetas, fecha, posición), get_card (detalle completo), search_cards, get_board_summary

Tarjetas — create_card (con archivos adjuntos/etiquetas/posición), update_card, move_card, complete_card, archive_card, unarchive_card, copy_card, set_card_position, set_card_cover, sort_todo_today

Archivos adjuntos — get_attachments, add_attachment (URL o subir un archivo local), view_attachment (devuelve imágenes visualizables — así es como Claude lee una captura de pantalla en una tarjeta), delete_attachment

Etiquetas — get_labels, add_label_to_card, remove_label_from_card, create_label

Comentarios — get_comments, add_comment

Listas — create_list, rename_list, archive_list, move_list

Listas de verificación — get_checklists, create_checklist, add_checklist_item, complete_checklist_item, uncheck_checklist_item, rename_checklist_item, delete_checklist_item, delete_checklist

Configuración conocida del tablero: comentarios deshabilitados

add_comment devuelve un 401 porque el tablero en sí tiene los comentarios desactivados (prefs.comments: "disabled") — no es un problema de token o código. Para habilitar: Trello → menú del tablero (···) → Configuración → Permisos de comentarios → Miembros del tablero. La herramienta detecta esto y lo explica en lugar de mostrar un 401 en bruto.

Nota sobre search_cards

El índice de búsqueda de Trello se retrasa unos segundos. Una tarjeta creada hace unos momentos puede no aparecer todavía; usa get_cards en su lista en su lugar.

Solución de problemas

# 1. Does the interpreter still work?
~/mcp-servers/trello-mcp/.venv/bin/python3 -c "import mcp; print('ok')"

# 2. Does the server start and reach Trello? (Ctrl-C to exit; silence = healthy)
~/mcp-servers/trello-mcp/.venv/bin/python3 ~/mcp-servers/trello-mcp/trello_mcp.py

# 3. Are the configs still pointing at the venv?
grep -A3 '"trello"' ~/.claude.json "$HOME/Library/Application Support/Claude/claude_desktop_config.json"

Después de cambiar cualquiera de las configuraciones, cierra y vuelve a abrir completamente la aplicación — los servidores MCP solo se inician al arrancar.

Copias antiguas de este script aún están en ~/Claude/Projects/Daily Trello/trello_mcp.py y ~/Downloads/trello_mcp.py. Nada apunta a ellas; aún contienen las credenciales incrustadas, así que no compartas esas dos.

Para el currículum / portafolio

Mantenido aquí para que una futura sesión de currículum tenga la versión honesta en lugar de reconstruirla.

La historia que vale la pena contar es el fallo, no la funcionalidad. Este servidor fallaba cada mañana durante semanas y funcionaba cada vez que se probaba manualmente — que es todo el diagnóstico: el código estaba bien y el entorno no. La configuración nombraba python3; una aplicación iniciada al iniciar sesión hereda un PATH mínimo (/usr/bin:/bin:/usr/sbin:/sbin) donde eso resuelve a un Python del sistema sin ninguno de los paquetes requeridos, mientras que una terminal hereda un PATH donde resuelve correctamente. Probar desde un shell era el único caso que se garantizaba que funcionara.

Lo que realmente hice: dirigí la depuración. Mías fueron las decisiones — tratar "funciona cuando lo pruebo" como evidencia sobre la prueba en lugar de tranquilidad sobre el código, y requerir una prueba que reproduzca las condiciones reales de inicio (PATH reducido) en lugar de las convenientes.

Lo que resultó de ello, ahora aplicado a cada integración: rutas de intérprete absolutas en configuraciones, un entorno dedicado por proyecto, cada dependencia fijada, y un script de diagnóstico que verifica cada modo de fallo conocido y repara lo que puede.

Viñeta para portafolio:

Dirigí el desarrollo de tres integraciones de automatización que conectan macOS con servicios en la nube, ejecutándose sin supervisión en trabajos programados. Diagnosticé un fallo diario recurrente debido a la resolución de PATH que difería entre el contexto del shell y el de inicio de la aplicación, y establecí convenciones de ruta absoluta y dependencias fijadas que lo eliminaron en las tres.

Caso de estudio completo: https://zeno-blade-creator.github.io/projects/personal-integrations.html