Trello MCP

Подключает Claude (Desktop/Cowork и Claude Code) к доске Trello.

Доска выбирается через board_id в вашей конфигурации — ничего о конкретной доске не зашито жёстко.

~/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)

Зарегистрирован в обоих:

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

• ~/.claude.json (Claude Code)

Оба указывают на абсолютный путь к интерпретатору виртуального окружения. Это важно — см. ниже.

Почему раньше каждое утро происходило отключение

Старая конфигурация запускала сервер с помощью простой команды python3. На этом Mac есть четыре бинарника python3, и только в одном есть пакет mcp:

Какой именно python3 будет использован, зависит от PATH процесса, запустившего приложение. Запущенное из Finder или при входе в систему, приложение наследует минимальный PATH launchd (/usr/bin:/bin:/usr/sbin:/sbin) и получает Python 3.9 → ModuleNotFoundError: No module named 'mcp' → "Не удалось подключиться к Trello MCP." Запущенное из терминала, оно наследует PATH оболочки, где Anaconda идёт первой → работает. Отсюда: сломано большую часть утра, но работает при ручной проверке.

Воспроизведите старую ошибку и исправление:

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

Указание интерпретатора по абсолютному пути означает, что поиск по PATH вообще не происходит. Приложение запускает один известный бинарник, который находит один известный каталог пакетов. Одинаковый результат в 7 утра и в 7 вечера.

Related MCP server: trello-mcp-server

Что такое виртуальное окружение на самом деле (и от чего оно не защищает)

Python ищет установленные пакеты в каталоге, привязанном к конкретному запущенному интерпретатору. Четыре интерпретатора = четыре отдельных каталога пакетов; mcp был установлен только в один. Виртуальное окружение создаёт частный каталог, принадлежащий только этому серверу.

Технически: python3 -m venv .venv создаёт .venv/bin/python3 и pyvenv.cfg, записывающий базовую установку. При запуске интерпретатор читает этот файл и устанавливает sys.prefix в виртуальное окружение, поэтому import разрешается в .venv/lib/python3.12/site-packages.

Честное ограничение: на macOS venv создаёт символическую ссылку на интерпретатор, а не копирует его, и стандартная библиотека всё равно загружается из базовой установки:

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

Таким образом, это виртуальное окружение всё ещё зависит от установленной Anaconda. Оно изолирует пакеты, а не интерпретатор.

Пересоздать после любого из этих событий, ~15 секунд:

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

Если когда-нибудь понадобится полная независимость от Anaconda, установите uv и создайте виртуальное окружение из управляемого uv автономного Python. Здесь этого не сделано, потому что это добавляет новый инструмент на машину.

Не обновляйте вслепую mcp

requirements.txt фиксирует mcp==1.27.2. Это сделано намеренно: mcp 2.0.0 удалил API декораторов @app.list_tools() / @app.call_tool(), на котором построен этот сервер. Установка последней версии мгновенно ломает сервер с ошибкой AttributeError: 'Server' object has no attribute 'list_tools' — что выглядит точно так же, как ошибка подключения, которую и должна была исправить вся эта настройка. Обновляйте только вместе с переписыванием обработчиков под новый API.

Как работает файл учётных данных

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

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

Ничего не размещено на хостинге, никакого внешнего сервиса — обычный JSON-файл на этом диске. Две вещи делают его "секретным":

1. Он находится вне кода, поэтому копирование или публикация trello_mcp.py не несёт учётных данных.

2. chmod 600 — только эта учётная запись macOS может его читать.

Сервер читает его при запуске и хранит значения в памяти. Чтобы поделиться сервером, отправьте trello_mcp.py; получатель создаёт свою собственную конфигурацию со своим собственным ключом Trello. Это не шифрование — это разделение того, чем вы делитесь, и того, чем не делитесь.

Токен Trello не имеет срока действия (dateExpires: null) и имеет разрешения на чтение+запись для Участника/Доски/Организации. В отличие от токена обновления OAuth сервера Google Drive, он не требует периодической повторной авторизации.

Списки никогда не зашиты жёстко

Каждый список разрешается по имени во время вызова через живой API, поэтому список, добавленный в Trello (новый класс каждый квартал), работает сразу — без изменения кода, без перезапуска. Кэш на 60 секунд делает это дёшево; промах кэша вызывает одну повторную выборку перед сообщением "не найдено", поэтому список, созданный несколько секунд назад, всё равно разрешается.

Измерено на этой доске: выборка списка занимает ~307 мс. Без кэша каждый вызов инструмента платил за это (get_cards стоит два круговых запроса), поэтому сессия планирования из 12 карт сжигала ~3,7 с на повторной выборке. С кэшем одна выборка покрывает всплеск.

Единственные имена списков в коде — это три якоря рабочего процесса в начале trello_mcp.py:

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

Они названы, потому что ежедневная рутина определена через них (sort_todo_today нельзя сказать "отсортируй список, который означает сегодня", не указав имя). Переименуйте один в Trello → измените его в этом блоке и в CLAUDE.md ежедневного Trello. rename_list предупреждает вас, когда вы переименовываете якорь.

Инструменты (37)

Чтение — get_all_lists, get_cards (включая вложения, метки, сроки, позицию), get_card (полная детализация), search_cards, get_board_summary

Карты — create_card (с вложениями/метками/позицией), update_card, move_card, complete_card, archive_card, unarchive_card, copy_card, set_card_position, set_card_cover, sort_todo_today

Вложения — get_attachments, add_attachment (URL или загрузить локальный файл), view_attachment (возвращает изображения, доступные для просмотра — так Claude читает скриншот на карте), delete_attachment

Метки — get_labels, add_label_to_card, remove_label_from_card, create_label

Комментарии — get_comments, add_comment

Списки — create_list, rename_list, archive_list, move_list

Чек-листы — get_checklists, create_checklist, add_checklist_item, complete_checklist_item, uncheck_checklist_item, rename_checklist_item, delete_checklist_item, delete_checklist

Известная настройка доски: комментирование отключено

add_comment возвращает 401, потому что на самой доске отключено комментирование (prefs.comments: "disabled") — это не проблема токена или кода. Чтобы включить: Trello → меню доски (···) → Настройки → Разрешения на комментирование → Участники доски. Инструмент обнаруживает это и объясняет, а не показывает сырую 401.

Примечание о search_cards

Поисковый индекс Trello отстаёт на несколько секунд. Карта, созданная мгновение назад, может ещё не появиться; используйте get_cards для её списка.

Устранение неполадок

# 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"

После изменения любой конфигурации полностью закройте и снова откройте приложение — серверы MCP запускаются только при старте.

Более старые копии этого скрипта всё ещё находятся в ~/Claude/Projects/Daily Trello/trello_mcp.py и ~/Downloads/trello_mcp.py. Ничто на них не указывает; они всё ещё содержат встроенные учётные данные, поэтому не делитесь этими двумя.

Для резюме / портфолио

Оставлено здесь, чтобы будущая сессия по резюме имела честную версию, а не реконструировала её.

История, которую стоит рассказать — это сбой, а не функция. Этот сервер давал сбой каждое утро в течение недель и работал каждый раз при ручной проверке — в этом и заключается вся диагностика: код был в порядке, а окружение — нет. В конфигурации было указано python3; приложение, запущенное при входе в систему, наследует минимальный PATH (/usr/bin:/bin:/usr/sbin:/sbin), где это разрешается в системный Python без необходимых пакетов, в то время как терминал наследует PATH, где это разрешается правильно. Тестирование из оболочки было единственным случаем, гарантированно проходящим.

Что я на самом деле сделал: руководил отладкой. Моими были решения — относиться к "это работает, когда я тестирую" как к свидетельству о тесте, а не как к успокоению по поводу кода, и требовать тест, который воспроизводит реальные условия запуска (урезанный PATH) вместо удобных.

Что из этого вышло, теперь применяется к каждой интеграции: абсолютные пути к интерпретаторам в конфигурациях, выделенное окружение для каждого проекта, каждая зависимость зафиксирована, и скрипт диагностики, который проверяет каждый известный режим сбоя и исправляет то, что может.

Пункт для портфолио:

Руководил разработкой трёх интеграций автоматизации, подключающих macOS к облачным сервисам, работающих без присмотра по расписанию. Выявил коренную причину повторяющегося ежедневного сбоя — разрешение PATH, различающееся в контекстах запуска оболочки и приложения, и установил соглашения об абсолютных путях и фиксированных зависимостях, которые устранили его во всех трёх.

Полное исследование: https://zeno-blade-creator.github.io/projects/personal-integrations.html