MCP для Claude Code та Codex — звірка пив зі свого агента

Та сама звірка пив, яку робить браузерне розширення на сторінках магазинів, доступна і напряму зі свого AI-агента: надсилаєш список пив — отримуєш, що з них ти вже пив (з оцінкою — де збіг певний), а що каталог бота знає про кожне. Це один інструмент, match_beers.

Знадобиться той самий токен, що й для розширення — див. Частину 1 у інструкції встановлення розширення (/start → /link → /import), якщо ти ще не проходив ці кроки.

Токен

Надішли боту в Telegram:

/extension

Бот дасть токен у копійованому блоці. Це той самий токен, що й для браузерного розширення — жодного окремого токена для MCP заводити не треба.

Важливо: видача нового токена (повторний /extension) скасовує попередній. Якщо після цього MCP раптом перестав з'єднуватись — онови токен у налаштуваннях клієнта нижче.

Claude Code

Одна команда:

claude mcp add --transport http warsaw-beer https://beer-api.ysilvestrov-ai.uk/mcp \
  --header "Authorization: Bearer ТВІЙ_ТОКЕН"

Заміни ТВІЙ_ТОКЕН на те, що дав бот. Перевірити з'єднання:

claude mcp list

Має з'явитися warsaw-beer зі статусом підключено.

Codex CLI

Спочатку постав токен у змінну середовища:

export WARSAW_BEER_TOKEN="ТВІЙ_ТОКЕН"

Тоді одна команда (саме так це підключення й перевіряли наживо):

codex mcp add warsaw-beer --url https://beer-api.ysilvestrov-ai.uk/mcp \
  --bearer-token-env-var WARSAW_BEER_TOKEN

Команда сама допише потрібний запис у ~/.codex/config.toml — ось що там з'явиться:

[mcp_servers.warsaw_beer]
url = "https://beer-api.ysilvestrov-ai.uk/mcp"
bearer_token_env_var = "WARSAW_BEER_TOKEN"

Якщо тобі зручніше редагувати файл руками, можна вписати цей блок і самому — Codex однаково читає токен зі змінної середовища WARSAW_BEER_TOKEN, а не з файлу.

Що означають статуси

Питаєш агента про список пив — у відповіді на кожне буде один із шести статусів:

Статус Що означає
drunk ти точно вже пив це пиво — відомо напевно
probably_drunk схоже, що ти вже пив, але збіг неточний — варто перевірити самому; оцінку тут не показуємо, бо не певні, що це те саме пиво
not_drunk твоя історія відома, і в ній цього пива немає
unknown про твою історію взагалі нічого не відомо — це не «ти не пив», а «нам нема звідки це знати»
not_in_catalog прийнятного збігу в каталозі бота не знайшли — пиво може бути в каталозі під іншою назвою
not_searched точного збігу нема, і ширший пошук по всьому каталогу не відбувся — це не «нема», а «не шукали»

Два з цих статусів варто зрозуміти правильно, бо вони легко переплутуються з іншими:

unknown з'являється, коли в бота взагалі немає твоєї історії пив — а наповнює її саме браузерне розширення (через /import або синхронізацію чекінів у розширенні). Поки цього не зроблено, бот не може сказати ні «пив», ні «не пив» — він чесно каже «не знаю». Це не привід вважати, що ти нічого не пив.

not_searched з'являється тому, що пошук по всьому каталогу — не лише по точних збігах — має бюджет 20 позицій на один виклик. Якщо в списку більше пив без точного збігу, частина з них лишається без цього ширшого пошуку: не тому, що їх нема в каталозі, а тому, що до них просто не дійшли за один раз.

Якщо не працює

Найважливіше — і найнеочевидніше — саме тут. Забутий або неправильний токен виглядає в обох клієнтах геть не так, як «немає токена».

Окремо, і це не про токен. У Codex є ще одна пастка: за замовчуванням він питає підтвердження перед кожним викликом тули. Якщо в тебе виставлена політика підтверджень never (автоматично відмовляти на всі запитання), виклик впаде з помилкою MCP tool call requires approval. Токен тут ні до чого — причина в цій політиці. Дозволь підтвердження для match_beers (або зміни політику підтверджень) і повтори запит.

Межі