Personal Cronometer MCP

Это локальный персональный мост между Cronometer и MCP-клиентами, такими как Codex и Claude Code. Он сочетает полезное покрытие живого аккаунта из клиента cronometer-mcp Пола Хоскинса с более строгим слоем на TypeScript, который сохраняет отсутствующие данные о питании, честно помечает действия, изменяющие аккаунт, и не допускает попадания учетных данных в конфигурационные файлы MCP.

Это личный учебный проект, созданный сертифицированным тренером по спортивному питанию NASM (CSNC), который также прослушал университетские курсы по питанию помимо своей основной специальности. Этот опыт определяет приоритеты проекта, но данное программное обеспечение не является медицинским устройством и не заменяет медицинскую помощь.

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

Важные ограничения

• Это неофициальный персональный инструмент. Cronometer не предоставляет и не поддерживает этот интерфейс. Изменение веб-сайта Cronometer может нарушить его работу без предупреждения, а автоматизированный доступ может подвергнуть аккаунт риску. Прежде чем включить его, прочтите текущие Условия использования Cronometer.

• Некоторые функции экспорта CSV могут требовать Cronometer Gold. Cronometer документирует поддерживаемый процесс ручного экспорта в Настройках учетной записи: Экспорт данных.

• Этот инструмент сообщает, что было записано и насколько полна запись. Он не является медицинским устройством, не диагностирует дефицит питательных веществ и не дает медицинских советов.

• Держите его локальным. Проект намеренно не имеет HTTP-сервера, режима удаленного развертывания, телеметрии или инструмента для произвольного выполнения кода.

Что делает сводку по питательным веществам безопаснее

Ежедневная сводка Cronometer содержит скрытую ловушку: пустая ячейка питательного вещества означает «нет данных», а отображаемый ноль означает записанный ноль. Его строка Total может схлопывать отсутствующие ячейки в ноль. Этот сервер сам разбирает строки дневниковых групп, вычисляет покрытие для каждого питательного вещества и возвращает значение потребления только при достижении запрошенного порога покрытия. При пороге по умолчанию 1 каждая ячейка дневниковой группы для этого питательного вещества должна содержать данные.

Таким образом, результат по питательному веществу имеет одну из двух форм:

• kind: "value" — содержит значение, единицу измерения, покрытие группы, покрытие дня и сравнение с итогом Cronometer.

• kind: "insufficient-data" — содержит покрытие и явно названную нижнюю границу observedSubtotal, но не может выразить эту промежуточную сумму как потребление.

Это различие сохраняется от разбора CSV до финального вывода MCP.

Каждое чтение дневника разбирается здесь, а не выше по потоку

Закрепленный клиент читает CSV с помощью csv.DictReader и возвращает строки нетипизированных строк. Это нормально как транспорт, но бесполезно как модель вашего дневника, поэтому этот сервер его не использует. cronometer_get_food_log, cronometer_get_exercises, cronometer_get_biometric_log и cronometer_get_notes вместо этого сами получают необработанный экспорт и разбирают его здесь. Что это вам дает:

• 1.00 container - each 5.3 oz возвращается как количество и единица измерения, а не как одна строка, которую нужно угадывать позже.

• Пустая длительность упражнения сообщается как отсутствующая, а не как ноль минут.

• Единицы измерения остаются такими, как их отображает ваш аккаунт. Ничего не конвертируется.

• Строка, которую невозможно прочитать, отбрасывается и сообщается, с указанием файла и строки, так что короткий список никогда не становится незаметно коротким.

• Время, которое никогда не было записано, равно null, а не полуночи.

Стоит знать об одном осознанном отказе. Если экспорт Cronometer когда-либо потеряет колонку, необходимую этому серверу, парсер вернет ноль строк — что выглядит ровно как день, который вы не записывали. Вместо того чтобы вернуть это, вызов завершится ошибкой и назовет отсутствующую колонку. Пустой ответ здесь был бы ошибкой того же класса, что и чтение отсутствующего питательного вещества как нуля.

То же правило теперь применяется к живым чтениям, которые не проходят через CSV. Если одно из них вернется пустым в форме, которую коннектор не распознает, результат будет содержать unverified: true — то есть «пусто, и я не мог это подтвердить». Вызов, который действительно завершается ошибкой, вместо этого вызывает исключение, так что этот флаг зарезервирован для единственного действительно неоднозначного случая: ответа, который называет данные, но затем не может их найти.

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

Живые вызовы также выполняются с интервалом не менее секунды. Это незаметно, пока вы читаете ответы, и это разница между разговором и скрапингом.

Одна вещь, которой стоит избегать при настройке дневника: не называйте дневниковую группу Total. Cronometer записывает свой собственный итог за день в ту же колонку, что и названия ваших групп, и экспорт не дает возможности их различить. Группа с таким названием была бы прочитана как итог дня и исключена из суммы, поэтому ее еда незаметно исчезла бы из всех показателей потребления. Любое другое название подойдет.

Ячейки питательных веществ также читаются строго. Ячейка должна быть пустой или содержать простое неотрицательное десятичное число; все остальное — текст, разделитель тысяч, отрицательное число — записывается как отсутствующее с примечанием, указывающим колонку и строку, а не преобразовывается в число, которое незаметно изменило бы итог.

Настройка в Windows

Откройте PowerShell и выполните:

Set-Location C:\dev\cronometer
.\scripts\setup-windows.ps1

В macOS эквивалент — sh scripts/setup-macos.sh, который делает то же самое в том же порядке — см. Другие платформы о том, что там проверено, а что нет.

Установка делает следующее:

1. Переустанавливает заблокированные зависимости Node.

2. Создает или обновляет приватное окружение Python 3.12 из хэш-проверенного файла блокировки из пяти пакетов (requests и четыре его транзитивные зависимости — клиент протокола встроен, а не устанавливается).

3. Собирает сервер и запускает все автономные тесты.

4. Запрашивает часовой пояс дневника Cronometer. America/New_York — рекомендуемый вариант по умолчанию для этого компьютера.

5. Показывает предупреждение о неподдерживаемом интерфейсе и требует точное слово ENABLE перед включением живого доступа.

6. Запрашивает имя пользователя и пароль Cronometer. Windows DPAPI шифрует пароль для текущей учетной записи Windows; он не записывается в этот репозиторий, командную строку, конфигурацию Codex или конфигурацию Claude.

7. Предлагает зарегистрировать сервер в каждом обнаруженном установленном клиенте — Codex, Claude Code и Claude Desktop. О каждом спрашивается отдельно, и пропуск одного не влияет на остальные.

   • Codex также получает запись default_tools_approval_mode = "writes" в свой config.toml, поэтому каждый инструмент, не помеченный как только для чтения, требует подтверждения. Если этот шаг не удается, установка прямо говорит об этом, а не оставляет вас с зарегистрированным сервером, который не спрашивает.

   • Claude Code не требует настройки подтверждения; см. Безопасность записи, почему.

   • Claude Desktop не имеет CLI для этого, поэтому его claude_desktop_config.json редактируется напрямую. Сначала создается резервная копия предыдущего файла, все уже существующие серверы сохраняются, а существующая запись cronometer-personal никогда не перезаписывается.

Перезапустите MCP-клиент после регистрации. Начните с:

Вызовите cronometer_status, затем проверьте подключение к Cronometer. Ничего не меняйте.

Первое реальное подключение может занять больше времени, поскольку оно выполняет вход и создает сессию. Последующие подключения используют проверенный кэш сессий JSON.

Для покрытия питательных веществ требуется скачанный экспорт

Это та часть, которую стоит понять, потому что она определяет, какой инструмент отвечает на вопрос о питательных веществах.

Cronometer предлагает одни и те же данные двумя способами, и они не эквивалентны:

Покрытие работает путем сравнения приемов пищи. Если ячейка омега-3 в обеде пуста, а в завтраке указано 0.00, это пробел в базе данных, а не нулевое потребление. Живой экспорт уже свернул эти приемы пищи в одно число — и это число как раз то, которое посчитало пустые ячейки как ноль. Поэтому живая сводка теперь отказывается отвечать на этот вопрос и указывает сюда, а не возвращает что-то, похожее на ответ.

В реальный день из этого аккаунта при полном покрытии 16 из 61 питательного вещества могли быть представлены числами. Остальные 45 были отклонены, и каждый из них был случаем, когда собственный итог Cronometer суммировал отсутствующие данные как ноль. Энергия и белок точно совпали с Cronometer и заслуживают доверия. Омега-3 показала 0,01 г — в день, содержащий лосось, — только из двух из четырех приемов пищи.

Чтобы использовать это: в Cronometer выберите Настройки → Аккаунт → Экспорт данных, скачайте и распакуйте CSV-файлы в папку с датой в каталоге экспорта, который настраивает лаунчер (%LOCALAPPDATA%\CronometerPersonalMcp\exports\2026-08-16\ и так далее). cronometer_list_exports показывает, что он видит. Каждый экспорт — это снимок, поэтому хранение их с датами создает историю, необходимую для многомесячного анализа.

Две вещи об этом каталоге. Он находится в той же папке, защищенной ACL, что и ваши учетные данные, потому что экспорт — это весь ваш дневник по приемам пищи. И сервер никогда не принимает путь — инструмент передает имя папки, которое разрешается и проверяется на нахождение внутри этого каталога, поэтому ничто за его пределами не может быть прочитано даже через символическую ссылку.

Запись еды

Проверено, работает от начала до конца 2026-08-17: поиск, добавление, чтение, удаление, чтение.

Это требует двух шагов, потому что запись дневника идентифицируется по мере, а не по продукту:

1. cronometer_search_foods — возвращает food_source_id (продукт) и food_id (его мера по умолчанию), а также описание вида 1 large - 50g, сообщающее, сколько весит одна такая единица.

2. cronometer_add_food_entry — передайте оба идентификатора, measure_id: 0, количество мер как quantity и фактический общий вес как weight_grams.

cronometer_get_food_details перечисляет все меры продукта с их весом в граммах, так что вы можете вычислить weight_grams для «двух больших» или «полчашки» без догадок.

Одно реальное ограничение. servings.csv не содержит идентификатора порции, поэтому cronometer_get_food_log не может его вернуть — а cronometer_remove_food_entry требует его. На практике вы можете удалить только ту запись, чей ID у вас еще есть от ее добавления в том же разговоре. Чтобы удалить что-то, записанное ранее или в приложении, используйте приложение Cronometer. Это пробел в том, что предоставляет экспорт, а не то, что коннектор может обойти.

Что было фактически проверено

Инструменты сгруппированы по доказательствам, а не по намерениям. Все нижеперечисленное было опробовано на реальном аккаунте 2026-08-17.

Проверено, работает. Поиск продуктов, сведения о продукте, дневник питания и другие чтения на основе CSV, анализ скачанного экспорта, список/создание/удаление макрошаблонов, добавление/удаление повторяющихся элементов, добавление/удаление биометрии для веса, а также добавление и последующее удаление записи о еде.

Проверено, не работает, и отказано, а не предпринято.

• cronometer_add_biometric принимает только вес. Запрос частоты сердечных сокращений 60 создал запись Weight на 60 фунтов — кодировка метрики для остальных трёх — догадки, а body_fat делит кодировку с weight байт в байт, поэтому он должен ошибочно сохраняться так же. Запись, которая молча сохраняет данные под неверной метрикой, портит тенденцию, которую вы прочитаете позже, и не подаёт признаков того, что это произошло, поэтому остальные метрики отклоняются. Записывайте их в приложении Cronometer.

• cronometer_set_day_complete не работает: Cronometer удалил метод setDayComplete, так же как он удалил findFoods. Локально это исправить нельзя.

Исправлено после живого теста. cronometer_get_repeated_items раньше возвращал food_source_id и measure_id переставленными местами, всегда пустой список дней недели и группу дневника 0. Теперь он читает ответ так, как его реально записывает протокол, — задом наперёд, — и корректно сообщает дни недели.

Группа дневника возвращается как null, потому что Cronometer не отправляет её обратно: два правила, созданные в разных группах, вернули одинаковые ответы, за исключением их идентификаторов, количества и дней недели. Группа, которую вы выбираете при создании правила, применяется, но прочитать её обратно нельзя. null говорит именно об этом; 0 выглядел бы как настоящая группа.

Никогда не проверялось. copy_day (он копирует целый день, и его нельзя аккуратно отменить, потому что идентификаторы порций нельзя прочитать обратно из экспорта), set_macro_targets и set_macro_schedule_day (Cronometer вычисляет рекомендуемые цели на основе вашего профиля, и их установка переопределяет этот расчёт — это не то, что стоит делать в качестве теста), а также два инструмента для голодания (инструмента создания голодания нет, поэтому нечего удалять или отменять).

Безопасность записи

Инструменты чтения и записи намеренно разделены. Каждый инструмент, изменяющий учётную запись, помечен как не-только-для-чтения, а каждый инструмент, помеченный как разрушительный, отклоняет вызов, если только не присутствует confirm: true.

Подтверждение работает в каждом клиенте по-разному, поэтому вот что именно вы получаете в каждом из них:

Случай Claude Code — самый надёжный, потому что требование перемещается вместе с инструментом, а не живёт в конфигурационном файле, который вы можете изменить позже. Остальные зависят от конфигурации клиента: скрипт настройки задаёт конфигурацию Codex и громко сообщает, если не смог. Более старые версии Claude Code игнорируют этот флаг и возвращаются к обычной обработке разрешений, как и другие MCP-клиенты, — неизвестный ключ _meta безвреден, поэтому он отправляется безусловно.

Инструменты чтения намеренно не несут такого флага. Проверка состояния, которая постоянно напоминает о себе, только приучила бы вас щёлкать по запросам, не читая их.

Записи никогда не повторяются автоматически. Если запись истекает по времени, сервер сообщает, что её результат неизвестен. Прежде чем решать, стоит ли пробовать ещё раз, проверьте приложение Cronometer; в противном случае повторная попытка может продублировать еду, биометрические данные, шаблоны или повторяющиеся элементы.

Ручная регистрация MCP

Обычно скрипт настройки предлагает сделать это. Если вы пропустили этот шаг, команда содержит только локальный путь к лаунчеру — и никогда учётные данные.

Codex:

codex mcp add cronometer-personal -- pwsh -NoProfile -ExecutionPolicy Bypass -File C:\dev\cronometer\scripts\run-mcp.ps1

Затем добавьте эту строку в новый раздел [mcp_servers.cronometer-personal] файла %USERPROFILE%\.codex\config.toml:

default_tools_approval_mode = "writes"

Claude Code, доступный пользователю Windows в каждом проекте:

claude mcp add --scope user cronometer-personal -- pwsh -NoProfile -ExecutionPolicy Bypass -File C:\dev\cronometer\scripts\run-mcp.ps1

У Claude Desktop нет команды регистрации. Добавьте это в объект mcpServers в %APPDATA%\Claude\claude_desktop_config.json, сохранив уже имеющиеся серверы, затем перезапустите Desktop:

"cronometer-personal": {
  "command": "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
  "args": ["-NoProfile", "-ExecutionPolicy", "Bypass", "-File", "C:\\dev\\cronometer\\scripts\\run-mcp.ps1"]
}

Используйте реальный путь к pwsh.exe на этой машине — его выводит (Get-Command pwsh).Source. Перед редактированием сделайте резервную копию файла: он содержит собственные настройки Claude Desktop, а также список серверов, и неудачное редактирование потеряет их. Скрипт настройки делает всё это за вас — это более надёжный путь.

Проверьте регистрацию с помощью codex mcp get cronometer-personal или claude mcp get cronometer-personal. Текущее руководство по Claude Code MCP от Anthropic объясняет области его конфигурации и правила разрешений, применимые к MCP-инструментам. Codex использует ту же конфигурацию MCP для своего CLI и расширения IDE; см. документацию MCP от OpenAI.

Упаковка этого в виде Desktop Extension (.mcpb/.dxt) устранила бы шаг ручного редактирования, но пакет расширения также должен был бы нести запрос учётных данных и окружение Python. Это не реализовано; маршрут «лаунчер плюс конфигурация», описанный выше, — то, что поддерживает этот репозиторий.

Граница учётных данных и сети

• scripts/run-mcp.ps1 расшифровывает пароль, защищённый DPAPI, и передаёт его серверу через переменные окружения. Будьте честны насчёт того, чем это обходится: лаунчер работает столько же, сколько и MCP-сессия, и пока он работает, пароль в открытом виде присутствует в окружении трёх процессов — лаунчера, Node и дочернего процесса Python. Он никогда не записывается на диск открыто, никогда не помещается в командную строку и никогда не хранится в конфигурационном файле MCP, но любой процесс, работающий от имени этого пользователя Windows, может прочитать его. Такова плата за то, чтобы не вводить пароль в конфигурационном файле.

• Дочерний процесс Python заменяет существующую исполняемую pickle-сессию на JSON с проверкой размера и сохраняет её в приватном каталоге данных приложения. В Windows этот каталог защищён ACL, который применяет скрипт настройки: наследование отключено, одно правило доступа для вашей учётной записи и никаких записей для SYSTEM или группы администраторов. Его защищают два уровня, и они проверяют разные вещи. Лаунчер при каждом запуске читает фактический ACL и отказывается работать, если каталог стал наследуемым или приобрёл какую-либо другую идентичность. Python-мост не может прочитать Windows ACL без дополнительных пакетов, поэтому он отказывается работать только когда CRONOMETER_DATA_DIR не задан — этого достаточно, чтобы не допустить отката cookie сессии к незащищённому значению по умолчанию в домашнем каталоге, но это не проверка самих разрешений. Запустите сервер любым способом, кроме лаунчера, и вы получите более слабую из двух защит.

• Сетевая сессия принимает только HTTPS-запросы, чей точный хост — cronometer.com, включая перенаправления. Переменные окружения прокси и сертификатов не передаются дочернему процессу, поэтому общесистемный прокси не может вмешаться.

• Вызовы сериализованы, даты и идентификаторы проверяются дважды, а любой результат инструмента более 2 МБ отклоняется, а не молча обрезается, — запросите более короткий диапазон дат.

• Названия продуктов, заметки, ошибки веб-сайта и весь остальной «живой» текст возвращаются внутри явной границы недоверенных данных, закодированные в JSON, чтобы текст не мог подделать конец этой границы. Их никогда нельзя рассматривать как инструкции.

Полезные инструменты

32 MCP-инструмента концептуально сгруппированы следующим образом:

• Подключение: проверка состояния и подключения.

• Загруженные экспорты: выводить их список и запускать по одному из них анализ питательных веществ с учётом покрытия. Они читают папку на этом компьютере и никогда не обращаются к сети.

• Дневник: журнал питания, упражнения, история биометрических данных, заметки, сводка по питанию с учётом покрытия, сырой CSV-экспорт, добавление/удаление еды, копирование дня и отметка дня как завершённого.

• База продуктов: поиск и сведения о продуктах.

• Макросы: чтение целей/расписаний, установка дневных целей, список/создание/удаление шаблонов и назначение шаблона на день недели.

• Голодание: история, статистика, удаление голодания и отмена активного голодания с сохранением его серии.

• Биометрические данные: чтение последних значений, добавление значения и удаление значения.

• Повторяющиеся продукты: список, добавление и удаление правил.

Здесь намеренно нет инструмента произвольных GWT-запросов, автоматизации браузера, сырого SQL, выполнения команд оболочки, автоматической фоновой синхронизации или удалённого HTTP-транспорта.

Проверка разработки

Все тесты автономны и используют синтетические данные:

npm run verify      # typecheck, TypeScript, Python, and the setup scripts

Это 450 тестов TypeScript, 45 тестов Python и 24 проверки настройки. Отдельные шаги: npm run typecheck, npm test, npm run test:python и npm run test:setup; последний при отсутствии PowerShell громко пропускает себя, а не падает по причине, не связанной с проверяемым кодом.

npm test сначала собирает проект и проверяет как унаследованный MCP, так и современное stdio-рукопожатие 2026-07-28. Набор протокольных тестов вызывает каждый инструмент через поддельный мост, проверяет метки разрешений инструментов, проверяет, что каждый разрушительный инструмент отклоняет неподтверждённый вызов, гарантирует, что обработчики чтения не могут достичь методов изменения, и прогоняет враждебный многострочный текст как по пути успеха, так и по пути ошибки, чтобы доказать, что ни один из них не может подделать конец границы недоверенных данных.

Два честных ограничения на то, что показывают эти тесты. Общая схема вывода намеренно типизирует data как unknown, потому что форму живого ответа определяет Cronometer, — поэтому «валидация по схеме вывода» является реальной проверкой только для сводки по питанию, единственного инструмента с полностью специфицированным результатом. Кроме того, каждый тест автономен: они доказывают, что обёртка ведёт себя корректно, а не что недокументированный интерфейс всё ещё работает.

Единственная живая проверка, которую можно запускать без подготовки, — это проверка подключения. Не тестируйте инструменты записи на реальной учётной записи, если только предполагаемое изменение учётной записи само не является тестом.

Примечание о двух файлах, которых нет в этом репозитории

Части исходного кода и аудита безопасности ссылаются на CLAUDE.md и AGENTS.md. Это рабочие файлы для ИИ-ассистентов, использованных при создании этого проекта, и они остаются на машине, а не в репозитории, — они написаны для ассистента, а не для читателя, и несут личный контекст, который без него читается плохо.

За этим не скрыто ничего существенного. Правила проектирования, которые они формулируют, видны там, где они применяются: тип «отсутствует против нуля» в src/domain/nutrient.ts, аннотации записи в src/mcp/registry.ts, ограждение недоверенных данных в src/mcp/server.ts, сетевая граница в python/live_bridge.py. Обоснование этих решений находится в BUILD_PLAN.md, DATA_MODEL.md и аудите безопасности, все они адресованы человеку. Ссылки на два отсутствующих файла оставлены как есть, а не вырезаны, потому что аудит в особенности является датированной записью, и тихое переписывание его цитат сделало бы его менее заслуживающим доверия, а не более.

Другие платформы

macOS собран: scripts/setup-macos.sh и scripts/run-mcp.sh зеркально повторяют пару Windows шаг за шагом, сохраняя пароль в связке ключей входа (login Keychain) вместо DPAPI и защищая каталог данных режимом 700 вместо ACL. Всё остальное — тот же код.

Будем откровенны о текущем состоянии, потому что это важнее, чем заявления:

Части пути macOS, которые являются обычным кодом — модуль записи конфигурации Claude Desktop, валидатор конфигурации, каждый парсер — покрыты тестами, которые запускаются на macOS в CI при каждом пуше. Что никогда не проверялось на Mac, так это часть, для которой нужен Mac: запрос Keychain, отказ при использовании режима каталога и одна реальная операция чтения и записи. В MACOS.md эти четыре проверки перечислены явно, и указано, какая из них с наибольшей вероятностью выявит различие.

Linux получает лаунчер бесплатно, поскольку для своего каталога данных и проверки прав он использует ветку, отличную от Darwin, но сценария установки нет, и никто его не запускал.

Происхождение и лицензия

Реализация протокола GWT-RPC изначально представляла собой MIT-лицензированный cronometer-mcp 2.0.3 Пола Хоскинса. Теперь она перенесена в каталог vendor и изменена и находится в python/vendor/cronometer_client.py, а не устанавливается из PyPI; уведомление об авторских правах Хоскинса сохранено в THIRD_PARTY_NOTICES.md, как того требует лицензия.

Это изменение было внесено в августе 2026 года по конкретной причине. Последний коммит апстрима был 8 марта 2026 года. К августу у него было восемь открытых issues и четыре не слитых пул-реквеста — два из них исправляли изменение в Cronometer, которое уже полностью сломало поиск продуктов, а вместе с ним и саму возможность вообще фиксировать приём пищи. Закреплённую зависимость нельзя пропатчить. Перенос в vendor позволил применить эти исправления, и он означает, что следующий сбой можно исправить здесь, а не только сообщить о нём в другом месте.

Каждое намеренное отличие от оригинала перечислено в заголовке файла в vendor, и два из них адаптированы из публичных пул-реквестов других участников, с указанием авторства в уведомлениях. Сама обратная разработка протокола — работа Пола Хоскинса, и она остаётся самой сложной частью этого проекта.

requests теперь — единственная зависимость времени выполнения, которая не принадлежит этому проекту.

Собственный код этого проекта распространяется по лицензии MIT; см. LICENSE.