Новый взгляд на MCP
Сложно сейчас представить использование AI-агентов без MCP-серверов.
MCP позволяет агенту подключаться к различным внешним системам, чтобы запрашивать данные, выполнять операции и выстраивать сложные цепочки взаимодействий.
Но текущий способ использования MCP-серверов имеет существенные недостатки.
Ребята из Anthropic выпустили очень любопытную статью, где описывают проблемы текущего подхода и предлагают конкретное альтернативное решение.
Проблемы с MCP:
– Как правило, все MCP-тулы и их описания загружаются в контекст. Если у вас подключено несколько MCP-серверов, у каждого может быть с десяток-другой тулов. В итоге, ещё до того как агент начал работу, у вас съедена большая часть контекста модели. В результате модель работает сильно хуже.
– Когда агент вызывает какой-то MCP-тул (например, запрашивает транскрипт из Google Docs), результат (полный текст) возвращается в контекст. А если нужно передать его дальше – допустим, вставить в запись Confluence – этот же текст снова дублируется в запросе. В итоге в контекст дважды попадает большой артефакт, который на самом деле не нужен агенту повторно, и он переполняется.
– Многие обоснованно переживают, что модель получит лишние данные, которые ей знать не нужно – например, персональные данные пользователей.
Что предлагают делать:
Вместо того, чтобы вызывать инструменты напрямую в контексте, предлагается позволить агенту писать и исполнять код, который сам будет обращаться к MCP-инструментам.
Если подробнее:
1. Информацию о всех тулах MCP-серверов мы храним локально в проекте – каждый тул оформлен как отдельный модуль (например, TypeScript-функция).
2. Агент изучает доступные инструменты через обход файловой системы: сначала смотрит, какие MCP-серверы есть в ./servers/, потом открывает нужные файлы и считывает интерфейсы только тех тулов, которые релевантны текущей задаче. Это позволяет не грузить всё подряд в контекст, а подгружать выборочно – по необходимости.
3. После этого агент пишет код, в котором использует нужные инструменты, вызывая только то, что требуется для выполнения поставленной цели.
4. Сгенерированный агентом код исполняется в отдельной изолированной среде (песочнице). Модель при этом не участвует в каждом шаге исполнения – она получает только итоговый результат (например, через вывод в терминал).
Это категорически снижает нагрузку на контекст: вместо передачи в модель всех промежуточных данных (например, больших таблиц, длинных текстов), результат возвращается в уже отфильтрованном или агрегированном виде.
Дополнительно, используя такой подход, можно:
– фильтровать большие данные (например, из таблицы в 10 000 строк вернуть модели только 5 нужных)
– токенизировать чувствительные данные перед их передачей в модель (модель будет видеть [EMAIL_1], а не сам email)
– строить полноценную логику: циклы, условия, обработку ошибок – без постоянных вызовов модели после каждого шага
На первый взгляд такой подход требует дополнительных приседаний, но, мне кажется, в итоге он перевесит те проблемы, с которыми мы сталкиваемся сейчас при использовании MCP.
#ai
Сложно сейчас представить использование AI-агентов без MCP-серверов.
MCP позволяет агенту подключаться к различным внешним системам, чтобы запрашивать данные, выполнять операции и выстраивать сложные цепочки взаимодействий.
Но текущий способ использования MCP-серверов имеет существенные недостатки.
Ребята из Anthropic выпустили очень любопытную статью, где описывают проблемы текущего подхода и предлагают конкретное альтернативное решение.
Проблемы с MCP:
– Как правило, все MCP-тулы и их описания загружаются в контекст. Если у вас подключено несколько MCP-серверов, у каждого может быть с десяток-другой тулов. В итоге, ещё до того как агент начал работу, у вас съедена большая часть контекста модели. В результате модель работает сильно хуже.
– Когда агент вызывает какой-то MCP-тул (например, запрашивает транскрипт из Google Docs), результат (полный текст) возвращается в контекст. А если нужно передать его дальше – допустим, вставить в запись Confluence – этот же текст снова дублируется в запросе. В итоге в контекст дважды попадает большой артефакт, который на самом деле не нужен агенту повторно, и он переполняется.
– Многие обоснованно переживают, что модель получит лишние данные, которые ей знать не нужно – например, персональные данные пользователей.
Что предлагают делать:
Вместо того, чтобы вызывать инструменты напрямую в контексте, предлагается позволить агенту писать и исполнять код, который сам будет обращаться к MCP-инструментам.
Если подробнее:
1. Информацию о всех тулах MCP-серверов мы храним локально в проекте – каждый тул оформлен как отдельный модуль (например, TypeScript-функция).
2. Агент изучает доступные инструменты через обход файловой системы: сначала смотрит, какие MCP-серверы есть в ./servers/, потом открывает нужные файлы и считывает интерфейсы только тех тулов, которые релевантны текущей задаче. Это позволяет не грузить всё подряд в контекст, а подгружать выборочно – по необходимости.
3. После этого агент пишет код, в котором использует нужные инструменты, вызывая только то, что требуется для выполнения поставленной цели.
4. Сгенерированный агентом код исполняется в отдельной изолированной среде (песочнице). Модель при этом не участвует в каждом шаге исполнения – она получает только итоговый результат (например, через вывод в терминал).
Это категорически снижает нагрузку на контекст: вместо передачи в модель всех промежуточных данных (например, больших таблиц, длинных текстов), результат возвращается в уже отфильтрованном или агрегированном виде.
Дополнительно, используя такой подход, можно:
– фильтровать большие данные (например, из таблицы в 10 000 строк вернуть модели только 5 нужных)
– токенизировать чувствительные данные перед их передачей в модель (модель будет видеть [EMAIL_1], а не сам email)
– строить полноценную логику: циклы, условия, обработку ошибок – без постоянных вызовов модели после каждого шага
На первый взгляд такой подход требует дополнительных приседаний, но, мне кажется, в итоге он перевесит те проблемы, с которыми мы сталкиваемся сейчас при использовании MCP.
#ai