Все статьи
AnthropicClaudeAItool use

Tool use Anthropic локально: туннели для Claude

Tool use у Claude — это не вебхук. Ваш бэкенд отправляет сообщение, Claude отвечает, иногда с запросом вызвать инструмент, ваш код выполняет инструмент и отправляет результат обратно. Всё это идёт по исходящему HTTPS с вашей машины. Тогда почему эта статья о туннелях?

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

Где туннель действительно помогает

Браузерные фронтенды для приложений с Claude

Та же схема, что и в настройке OpenAI Realtime. Ваш фронтенд не должен хранить API-ключ Anthropic, поэтому он общается с вашим бэкендом, а тот — с Anthropic. Фронтенду нужен HTTPS, чтобы потоковые ответы корректно отрисовывались (некоторые браузеры ухудшают обработку SSE по обычному HTTP), а бэкенду нужен HTTPS, если фронтенд на HTTPS. Туннель решает и то, и другое.

MCP-серверы, работающие локально

Model Context Protocol позволяет Claude (и другим клиентам) подключаться к инструментам, которые вы предоставляете как MCP-серверы. Для MCP-серверов с HTTP-транспортом — в отличие от stdio — клиент должен достучаться до вашего сервера. Если вы прототипируете MCP-сервер и хотите протестировать его с Claude Desktop или другим удалённым клиентом, открыть локальный MCP-сервер через туннель — путь наименьшего сопротивления.

Колбэки computer use

Если вы используете бету computer use у Claude и модель взаимодействует с сервисом, который шлёт вебхуки обратно на вашу машину, вы на территории вебхуков. Те же паттерны, что и у любого провайдера: захват, повтор, проверка (если применимо).

Чего туннель не делает

Туннель не нужен, чтобы просто вызвать Claude из локального скрипта. curl https://api.anthropic.com/v1/messages работает с любой машины. SDK для Python и TypeScript работают нормально. Сам tool use — это исходящее взаимодействие: Claude не звонит на вашу машину, когда хочет вызвать инструмент, — вызывает ваш код на основе ответа Claude.

В первый раз это сбивает с толку. Паттерн такой:

  1. Ваш код отправляет Claude сообщение пользователя со списком доступных инструментов.
  2. Claude отвечает, возможно с блоком tool_use, описывающим инструмент для вызова.
  3. Ваш код выполняет инструмент в вашей локальной системе.
  4. Ваш код отправляет результат инструмента обратно Claude в следующем сообщении.
  5. Цикл до завершения.

Все пять шагов происходят в одном процессе Python или TypeScript. Никакого входящего трафика. Никакого туннеля.

Настоящая причина, почему тунелирование помогает воркфлоу с Claude

Причина, по которой мы в итоге запускаем туннель при разработке с Claude, — не сама модель. Это всё вокруг неё: дашборд для показа прогресса агента, фронтенд, стримящий вывод инструментов, открытый для тестов MCP-сервер, вебхук от стороннего инструмента, который вызвал агент («отправь сообщение в Slack», «создай задачу в Linear»). Агент запускает цепную реакцию, и где-то в этой цепочке внешний сервис в итоге хочет достучаться до вашей машины.

Настройка цикла разработки MCP-сервера

  1. Реализуйте MCP-сервер с HTTP-транспортом.
  2. Запустите его локально на выбранном порту.
  3. npx portpreview 3000 (или ваш порт).
  4. В Claude Desktop или другом MCP-клиенте укажите URL удалённого сервера, ведущий на ваш туннель.
  5. Отправляйте команды. Смотрите захват запросов в туннеле и ответы вашего сервера.

Если ваш MCP-сервер использует stdio-транспорт, это не применимо — stdio-серверы общаются через пайпы процессов и остаются локальными по замыслу.

Потоковые ответы и туннели

Claude стримит ответы через SSE. Туннели должны корректно обрабатывать долгоживущий потоковый ответ — большинство умеет, но некоторые старые HTTP-прокси буферизуют ответ и отдают его только в конце, что сводит смысл стриминга на нет. PortPreview, Cloudflare и ngrok обрабатывают SSE без буферизации. Если ваш фронтенд получает весь ответ одним куском после долгого ожидания — туннель буферизует. Это проблема туннеля, а не Claude.

Отладка цикла агента

Самое сложное в разработке tool use у Claude — не API. А понимание того, что модель решила сделать на каждом шаге. Логируйте каждый блок tool_use до выполнения. Логируйте каждый результат инструмента до возврата Claude. Если между фронтендом и бэкендом есть туннель, захват запросов также даёт журнал сообщений пользователя — удобно для повтора прогонов агента без перепечатывания промптов.

Куда это движется

Экосистема tool use у Anthropic развивается быстро — MCP, computer use, более длинные контекстные окна, меньшая задержка. Паттерны вебхуков из статьи отладка вебхуков локально и математика подписей из руководства по проверке подписей применимы, когда любой внешний инструмент, вызванный агентом, шлёт колбэк на вашу машину.

Запишитесь в лист ожидания PortPreview, чтобы получить туннель со встроенным захватом, повтором и безопасной для SSE передачей.

Часто задаваемые вопросы

Нужен ли туннель, чтобы использовать tool use у Claude?
Для основного API — нет. Tool use у Claude — исходящее взаимодействие: ваш код вызывает Anthropic, Claude отвечает запросами инструментов, ваш код их выполняет, вы отправляете результаты обратно. Всё исходящее. Туннель нужен только когда внешние сервисы звонят на вашу машину: браузерные фронтенды, удалённо открытые MCP-серверы или сторонние инструменты, шлющие вебхуки обратно.
Как протестировать MCP-сервер с Claude локально?
Для MCP-серверов с HTTP-транспортом запустите сервер локально и откройте его через туннель. Укажите в Claude Desktop (или другом удалённом MCP-клиенте) URL туннеля. Stdio MCP-серверам туннель не нужен, так как они общаются через пайпы процессов.
Не сломают ли туннели потоковые ответы Claude?
Большинство современных туннелей обрабатывают SSE-стриминг без буферизации. Если фронтенд получает весь ответ разом после долгой паузы — туннель буферизует и ломает стриминг. PortPreview и другие современные туннели этого избегают.