Серверы MCP превращаются в платформы с расширенными возможностями, а не в простые оболочки инструментов.
Серверы MCP превращаются в платформы с различными возможностями: преобразование инструментов, поиск, пространства имен, прокси, навыки, задачи и версионирование, а также указания, когда следует воздержаться от использования.
Источники: Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #7
Любой, кто уже внедрял сервер MCP в производственную среду, знает необходимый список требований: четко определенные контракты инструментов, структурированные входные и выходные данные, разумная семантика ошибок, механизмы аутентификации, возможности отслеживания состояния, четкое разделение того, что контролирует модель, и того, что предоставляет среда выполнения (идентификатор пользователя, арендатор, роли и диапазоны полномочий), авторизация во время выполнения, а также модель развертывания, способная к масштабированию. Следующий шаг — это не новый способ передачи данных или еще одна рамка для агентов, и это не повод переписывать всю стек-технологии. Дело в том, что сервер MCP все больше напоминает настоящую платформу для реализации функций, а не простой конечный пункт с несколькими дополнительными инструментами.
Разница становится значимой, когда у вас есть десятки инструментов, несколько серверов MCP, несколько команд, пользователи с разными правами, различные клиенты, долгосрочные рабочие процессы, повторно используемые навыки, версии и всё больший объём контекста. В такой ситуации вопрос уже не в том, как сделать функцию Python инструментом. Он становится гораздо более масштабным:
Как сформировать, обнаружить, составить, управлять, запустить, отслеживать, тестировать и развивать всю поверхность возможностей, не загружая всё это в модель?
Именно в этом направлении развивается MCP, и далее в этой статье рассматривается именно это.
Первый сервер MCP и современные серверы MCP — это совершенно разные вещи
Ранние примеры MCP были намеренно простыми. Один сервер содержал всего несколько инструментов:
MCP server
├── search_documents
├── create_ticket
└── get_customer
Клиент перечислял инструменты, модель анализировала схемы и выбирала один из них, а сервер его запускал. Для небольшой системы такая модель мышления всё ещё подходит. При наличии пяти чётко определённых инструментов, одного бэкенда, одной команды и одного случая использования не требуется ничего более сложного.
Теперь представьте ту же структуру в реальной корпорации:
Salesforce MCP 60 capabilities
GitHub MCP 40 capabilities
Jira MCP 35 capabilities
Google Drive MCP 25 capabilities
Knowledge Base MCP 20 capabilities
Internal Platform MCP 70 capabilities
Reporting MCP 15 capabilities
Admin MCP 30 capabilities
Это уже не сервер инструментов. Это экосистема возможностей. Если просто объединить все схемы и отправить их всеми вместе модели, возникают три проблемы: контекст уничтожается ещё до начала задачи, выбор инструментов становится сложнее, а модель видит возможности, которые могут быть нерелевантными, рискованными или запутанными для данного пользователя и данного рабочего процесса.
Это давление знакомо по обсуждениям безопасности и поиска, но у него есть более широкие последствия, которые легко упустить: каталог инструментов сам по себе является инженерным продуктом. Его можно искать, преобразовывать, фильтровать и называть пространствами имен. Его можно создать на основе ресурсов других серверов, и он может содержать повторно используемые навыки и ресурсы. Некоторые операции могут приостанавливаться для задания вопроса пользователю, длительные задачи могут выполняться в фоновом режиме, контракты могут иметь версии, а весь интерфейс можно тестировать как любой производственный API.
Именно эту эволюцию рассматриваются в следующих разделах.
FastMCP — это одна из хороших реализаций этой идеи, но не сама идея
FastMCP часто присутствует в примерах, поскольку его текущая архитектура делает эти паттерны особенно заметными. Провайдеры предоставляют компоненты. Трансформации изменяют внешний вид компонентов до того, как их увидит клиент. Поиск позволяет заменить огромный каталог на небольшой интерфейс поиска. Прокси могут объединять другие серверы MCP. Навыки могут превращаться в ресурсы. Медленные операции могут становиться фоновыми задачами. Версии могут сосуществовать. А получившийся интерфейс MCP можно тестировать с помощью реального клиента, а не путем прямого вызова функций реализации.
Это полезно, но урок не в том, что «всем следует использовать FastMCP». Речь идет о том, что это превращается в повторно используемые архитектурные шаблоны для систем MCP. Те же самые идеи можно реализовать на Python, TypeScript, Go, C#, Java, Rust или на внутренней платформе, с другой фреймворком, с ручно написанными компонентами или с управляемым шлюзом. Важно замечать, куда смещается абстракция. Протокол стандартизирует способ общения клиентов с возможностями, в то время как архитектура вашего сервера определяет, как будет выглядеть интерфейс этих возможностей, и этот интерфейс теперь может быть гораздо умнее, чем простой статический список оформленных функций.
1. Трансформация инструментов: API бэкенда не должно автоматически превращаться в API агента
Одна из наиболее полезных идей здесь также является одной из самых простых. Инструмент, предоставляемый верхним уровнем сервиса, может быть технически корректным, но при этом совершенно не подходить для работы с LLM.
Представьте внутреннюю интеграцию Salesforce, которая обеспечивает выполнение этой операции:
salesforce_account_query_v2_internal(
q_string,
include_deleted_flag,
tenant_uuid,
raw_fields,
)
Внутри сервиса, который им управляет, такая подпись может быть приемлемой. Но должен ли модель видеть именно такой контракт? Вряд ли. Версия, предназначенная для модели, лучше будет выглядеть так:
find_customer_account(
company_name,
include_archived=False,
)
Основная операция осталась прежней. Изменился только интерфейс, представляемый модели, и это и есть преобразование инструмента.
FastMCP обеспечивает это с помощью специального слоя преобразований: изменение имени инструмента, переписывание его описания, изменение имён аргументов, модификация значений по умолчанию, скрытие ненужных аргументов, корректировка тегов и аннотаций, а также обёртка выполнения в пользовательскую логику. В общих чертах процесс выглядит следующим образом:
Backend capability
↓
Raw MCP tool
↓
Transformation layer
↓
Agent-facing contract
Есть несколько причин, по которым это имеет смысл.
У модели нет необходимости в деталях инфраструктуры. Такие поля, как tenant_uuid, internal_region, api_version или include_deleted_internal_records, относятся к области ответственности бэкенда. Если модель не должна определять значение, его следует полностью исключить из её схемы. Это соответствует правилу рабочего контекста: надёжные значения остаются за пределами границ возможностей и никогда не передаются через аргументы, определённые моделью.
Во-вторых, любое название, используемое в системе-источнике, может оставаться незамеченным агентом. Поставщик или устаревшая служба могут предоставлять операции, разработанные для человеческих разработчиков, что плохо подходит для ИИ-модели, которой нужно выбирать из 80 инструментов. Шлюз может предложить более упорядоченный словарь терминов, не требуя от команды источника переименовывать свой API.
В-третьих, контракт агента может оставаться стабильным, даже когда меняется бэкенд. Это имеет большее значение, чем кажется на первый взгляд. Если бэкенд переходит на новую версию API Salesforce, меняет название внутреннего параметра или превращает одну операцию в пару операций, инструмент, который видит модель, вовсе не обязан меняться. Слой трансформации выполняет роль защитного слоя между теми, кто использует данную функциональность, и теми, кто её реализует. Это обычная архитектура программного обеспечения, просто применяемая сейчас к интерфейсам, ориентированным на агентов.
Контракт бэкенда предназначен для системы, владеющей данной функциональностью. То, что предоставляет слой MCP, должно быть предназначено для агента, который будет его вызывать.
2. Поиск инструментов: каталог превращается в поисковый контекст
Этот аспект становится важным сразу при росте экосистемы. Типичная первоначальная реализация выглядит следующим образом:
connect to server
↓
list all tools
↓
put every schema into the model context
↓
ask model to choose
Этот метод работает, пока список небольшой, но становится всё более неэффективным с каждым добавляемым инструментом. Более зрелый подход выглядит следующим образом:
small discovery interface
↓
search relevant capabilities
↓
load only matching schemas
↓
execute
Инструменты поиска в FastMCP превращают эту идею в реальность. Вместо предоставления полного каталога сервер выдает синтетические инструменты для поиска, такие как search_tools и call_tool. В настоящее время используются встроенные стратегии — сопоставление с помощью регулярных выражений и ранжирование по алгоритму BM25. BM25 представляет собой лексическое ранжирование, а не семантический векторный поиск, однако архитектура не зависит от BM25. На вашей собственной платформе ранжирование может осуществляться на основе ключевых слов, эмбеддингов, гибридного поискового механизма с повторным ранжированием, фильтров метаданных, статистики использования, оценки с учетом правил или индекса, созданного специально для возможностей вашей области деятельности.
Ключевой момент заключается в том, что инструменты превращаются в объекты, которые можно найти. Вместо того чтобы вставлять 300 определений инструментов в контекст, модель может вызвать search_tools("найти возможности для клиентов и открыть сделки") и получить три-четыре результата, например salesforce_find_account, salesforce_list_opportunities и salesforce_get_pipeline_summary. Только эти схемы переходят на следующий этап.
Это не просто экономия ресурсов. Это улучшает условия принятия решения моделью. Выбор одной из 300 схем и поиск функций, связанных с задачей, а затем выбор из четырех соответствующих результатов — это совершенно разные задачи на рассуждение.
Постепенное открытие также лежит в основе подходов к выполнению кода, но поиск инструментов полезен даже в том случае, если вы никогда не запускаете код, написанный моделью, и он работает с обычными вызовами инструментов. Одно правило безопасности должно быть заимствовано из процесса авторизации: необходимо искать в каталоге, который пользователю разрешено обнаруживать, а не в полном каталоге платформы. Если в результатах поиска отображаются названия и схемы запрещенных административных инструментов, информация о их возможностях уже утекла, даже если дальнейшее выполнение кода отклоняется. Поэтому в реальном процессе необходим фильтр авторизации перед поиском.
Можно рассматривать это как инженерию контекста, примененную к возможностям.
3. Пространства имен: композиция создает проблему идентичности еще до проблемы масштабирования
Как только начинается объединение серверов MCP, сразу возникает крайне неприятная проблема: каждый сервер имеет стандартные имена вроде search, get_user, list_files или create_note. Если объединить сервер Salesforce, сервер Google Drive, сервер базы знаний и сервер GitHub, причем три из них предоставляют функцию search, возникает множество вопросов. Какой именно search используется моделью? Какой из них отображается в логах? Какой покрывается правилом политики? Какой изменился при смене «отпечатка схемы»?
Именно поэтому пространства имен имеют большое значение, когда MCP перестаёт быть единым изолированным сервером. FastMCP предоставляет функцию преобразования пространств имён, которая добавляет префикс к компонентам во время их объединения, так что search превращается в salesforce_search, gdrive_search, knowledge_base_search и github_search. URI ресурсов также могут иметь префиксы в своих путях.
Избежание коллизий — это очевидная выгода. Более тонкой выгодой является возможность отслеживания происхождения: префикс фиксирует источник той или иной функциональности, а этот источник используется для формирования правил политик, создания журналов аудита, отслеживания действий, установления лимитов скорости, определения владельца, выполнения миграций, отладки, а также для формирования описаний, которые читает модель.
Однако не стоит перегибать палку. Имя вроде enterprise_internal_platform_team_alpha_salesforce_v2_search_customer не является лучшим только потому, что оно уникально во всей системе. Пространство имён определяет идентичность, но процесс трансформации всё равно может сделать окончательный интерфейс более удобным для работы с моделью. Это две связанные, но разные проблемы:
Source identity
→ Namespace
Agent usability
→ Transformation
4. Видимость: инжиниринг контекста — это не только текст
Когда речь заходит об инжиниринге контекста, большинство людей думают о системных промптах, полученных документах, памяти, истории чатов и, возможно, описаниях инструментов. Однако любые возможности, которые может видеть модель, также являются частью её контекста.
Возьмём рабочий процесс исследования потребителей. Что сделала бы модель с такими инструментами, как rotate_api_key, terminate_employee, rebuild_search_index, publish_release и admin_delete_tenant, даже если у пользователя есть права на некоторые из них? Ничто из этого не поможет выполнить задачу. Более упорядоченный вариант может выглядеть так:
Customer Research
├── salesforce_find_account
├── salesforce_list_opportunities
├── knowledge_search
├── web_research
└── generate_customer_report
Эту проблему решает возможность видимости во время выполнения. Механизм видимости компонентов FastMCP позволяет включать или выключать компоненты по их имени, ключу или тегу; отключенный компонент исчезает из списка и не может быть обработан через стандартные интерфейсы сервера. Наборы функций, специфичные для рабочих процессов, флаги функций, различия сред, бета-инструменты, окна технического обслуживания, продукты, предназначенные для конкретных арендаторов, профили агентов, а также ограниченный набор действий для модели — все они используют один и тот же механизм:
workflow = customer_research
include:
salesforce.*
knowledge_base.*
reports.*
exclude:
admin.*
deployment.*
hr.*
Различие с работой в области безопасности по-прежнему сохраняется: видимость не является заменой авторизации. Видимость позволяет определить, принадлежит ли та или иная функция к текущему набору возможностей. Авторизация показывает, разрешено ли данному авторизованному пользователю фактически её использовать. Хорошая корпоративная платформа MCP обычно требует наличия обоих элементов: сначала сокращается набор доступных возможностей, а затем обеспечивается контроль за правами доступа.
5. Прокси MCP: один сервер в качестве шлюза к другим
Теперь дизайн становится по-настоящему интересным. Серверу не обязательно иметь все функции, которые он предлагает; он может выступать в качестве промежуточного звена перед другими серверами MCP. Провайдер прокси FastMCP загружает инструменты, ресурсы и запросы с удаленного сервера MCP и затем публикует их с текущего сервера.
Таким образом, получается простая цепочка вот такой структуры:
AI client
↓
Salesforce MCP
Он может превратиться в шлюз, обслуживающий несколько серверов высокого уровня, причем этому шлюзу не нужно копировать от них никакую бизнес-логику. Он проксирует их возможности и создаёт вокруг них платформенный слой: аутентификацию, правила работы, номенклатуру, видимость и возможности мониторинга.
Это значительное изменение в подходе к проектированию систем: серверы MCP больше не являются изолированными единицами и могут образовывать сеть. Одна команда может отвечать за интеграцию с Salesforce, другая — за знания, связанные с проектом, а третья — за работу инфраструктуры; при этом корпоративный шлюз объединяет всё в единый интерфейс продукта, не заставляя команды использовать общий репозиторий или цикл выпусков.
Прокси также оказывают пользу в менее очевидных аспектах: они обеспечивают связь между транспортными слоями, предоставляют стабильный конечный пункт подключения перед постоянно меняющимися серверами верхнего уровня, централизуют процедуры аутентификации, повышают уровень прозрачности, применяют единые правила, упорядочивают имена и скрывают внутреннюю топологию от клиентов.
Все это не означает, что каждой компании необходим гигантский центральный шлюз. Можно использовать несколько таких шлюзов, разделенных по доменам: инженерия, продажи, исследования, операции платформы. MCP обеспечивает протокольные рамки, позволяющие их четко интегрировать.
Как только серверы MCP могут взаимодействовать и преобразовывать данные друг у друга, естественной единицей проектирования становится не отдельный сервер, а граф управляемых возможностей.
6. Навыки как ресурсы MCP: сервер может распространять не только действия, но и знания
Инструменты отвечают на вопрос о том, что может делать система. Ресурсы отвечают на вопрос о том, какую информацию может получить клиент. Навыки добавляют третий вопрос: как агенту следует выполнять определённый тип задачи?
Навык обычно находится в каталоге: инструкции вместе с вспомогательными материалами, такими как примеры, схемы, скрипты, чек-листы, ссылки или рекомендации по конкретной области. Традиционно такие каталоги располагались внутри среды клиента, например, в папках ~/.claude/skills/, ~/.cursor/skills/ или ~/.gemini/skills/. Однако провайдер навыков FastMCP публикует их в виде ресурсов MCP, поэтому адрес навыка имеет форму skill://customer-research/... и включает основной файл SKILL.md, манифест, файл с примерами и JSON-схему.
Это важнее, чем кажется, поскольку теперь сервер может распространять процедурные знания наряду с возможностями для их выполнения. Представьте внутреннюю платформу для исследований потребителей, интерфейс MCP которой предоставляет такие инструменты, как search_salesforce, search_knowledge_base и generate_report, а также информацию о том, как команда определяет квалифицированные возможности, методологии исследований, ожидаемой структуре отчетов, требованиях к доказательствам и примерах качественных отчетов.
Инструмент сообщает агенту, что он может выполнять. Навык указывает ему, как ваша организация ожидает выполнения работы. Разделение помогает: вам не нужно включать каждую процедуру работы в один огромный системный запрос, и не нужно вручную копировать один и тот же навык в каждый ИИ-клиент. Клиент, понимающий ресурсы MCP, может находить и загружать навыки через ту же протокольную среду, в то время как клиент, ограниченный инструментами, всё равно может получать к ресурсам доступ через слой адаптации, который оборачивает их в вызовы инструментов.
Сервер MCP может объединять возможности, контекст и знания о процедурах работы в один многократно используемый продукт.
7. Получение информации: возможность для функции задавать пользователю вопросы
Самое простое взаимодействие с инструментом является однонаправленным: модель вызывает инструмент, и инструмент возвращает результат. На самом деле рабочие процессы гораздо сложнее. Предположим, пользователь просит создать новую облачную среду для проекта аналитики, и инструмент находит три подходящих региона и два профиля развертывания. Или выясняется, что создание запрашиваемой среды обойдётся примерно в 420 долларов в месяц. Или обнаруживаются два аккаунта Salesforce с практически идентичными именами. Правильным следующим шагом не всегда является угадывание; иногда системе следует задать вопрос.
В этом и заключается суть метода MCP elicitation. FastMCP предоставляет удобный API для получения структурированных данных от пользователя, но этот подход относится к стандарту MCP, а не к какой-либо конкретной Python-фреймворку.
Спецификация MCP от 2026-07-28 переработала этот механизм обмена с использованием многократных запросов-ответов (MRTR), чтобы он соответствовал новой модели протокола без состояния, вместо того чтобы опираться на сессию, оставшуюся открытой в обоих направлениях. Изменился механизм передачи данных. Сама возможность осталась прежней: операция сервера по-прежнему может приостанавливаться в ожидании ввода пользователя в процессе выполнения задачи. Типичные случаи применения — устранение неоднозначностей в сущностях, заполнение отсутствующих параметров, подтверждение дорогостоящих операций, проверка сгенерированного контента перед публикацией, выбор целевой среды и постепенный сбор структурированной информации.
Здесь существует важное замечание по вопросам безопасности: запрос у пользователя не является разрешением. Когда удаление требует одобрения, сам сервер должен хранить информацию об этом состоянии одобрения и обеспечивать его соблюдение. Дружелюбный вопрос «Вы уверены?» на естественном языке не решает проблему. Для чувствительных операций наличие человека, участвующего в процессе, должно приводить к реальной смене состояния.
8. Логирование: полезно для клиента, но наблюдаемость в производственной среде требует более глубокого подхода
Логирование делится на две отдельные категории. Первая — это информация для клиента о ходе выполнения операций: «Поиск в Salesforce… Найдено 18 соответствующих вариантов… Генерация отчета… Отчет создан». Вторая категория — это наблюдаемость в производственной среде: идентификаторы трейса, запроса, пользователя и арендатора, а также название инструмента, поставщика, время задержки, количество попыток, решение политики, идентификатор задачи и код ошибки. Считайте их отдельными задачами.
FastMCP по-прежнему предусматривает ведение журналов событий клиента, при котором сервер отправляет сообщения типа debug, info, warning или error обратно клиенту MCP, поддерживающему их. Это помогает во время разработки и позволяет клиенту получать представление о действиях той или иной функции. Однако в протоколе запланирована важная изменение на 2026 год: собственная функция ведения журналов протокола была устарожена для новых реализаций в MCP 2026-07-28. Поэтому новая система мониторинга в производственных условиях не должна зависеть от сообщений журналов MCP. Используйте стандартные инструменты мониторинга приложений: структурированные журналы, трейсы OpenTelemetry, метрики, Datadog, Grafana и Tempo, CloudWatch, ELK или любые другие инструменты, уже используемые в вашей организации.
Один из способов решения этой проблемы заключается в том, что сообщения о статусе позволяют пользователю или хосту следить за происходящим, в то время как телеметрия с серверной стороны помогает отделам инженерии, безопасности и операций понимать состояние системы. При корпоративном внедрении второй вариант является обязательным. Один запрос пользователя может проходить от хоста с ИИ через шлюз MCP, затем к прокси-серверу, далее к API SaaS и, наконец, к фоновому работнику, причем один трейс должен описывать весь этот путь. Чем проще производить проксирование и комбинирование с помощью MCP, тем важнее становится дистрибутированное представление информации.
9. Фоновые задачи: у функции может быть жизненный цикл выполнения
Классическая последовательность вызовов включает запрос, выполнение, получение результата и предполагает, что работа вмещается в один запрос. Однако многие важные корпоративные задачи не подходят под это ограничение: отчет клиента объемом 60 страниц, индексация 20 000 документов, анализ большого хранилища, полный экспорт данных из Salesforce, создание презентации с вспомогательными материалами, проверка соответствия стандартам, обработка большой партии записей. Такие задачи могут выполняться несколько минут, требовать повторных попыток, продолжаться после разрыва соединения с клиентом, сообщать о прогрессе или выполняться на другом работнике, отличном от конечной точки MCP.
Расширение MCP Tasks предоставляет долгосрочному выполнению задач нативный цикл жизни, определенный протоколом. Фоновые задачи FastMCP наглядно демонстрируют это: компонент отмечается как способный к выполнению задач, клиент получает управляющий объект задачи, а выполнение переходит на фонового работника, работающего в рамках системы управления задачами, вместо того чтобы оставлять первоначальный вызов открытым.
Это отличается от использования asyncio.create_task(...). Механизмы параллельных вычислений в Python оставляют работу внутри процесса, тогда как задачи на уровне протокола создают контракт между сервером и клиентом для длительных операций, благодаря чему у таких задач есть жизненный цикл, понятный клиенту. Ещё один признак того, что сервер MCP превращается в полноценную прикладную платформу, а не просто обёртку для RPC: его функция заключается не только в вызове функции и возврате JSON-результата. Ему также может потребоваться запускать работу, сохранять состояние, отображать прогресс, обрабатывать отмены, восстанавливаться после сбоев и возвращать результат позже.
10. Версионирование: когда агенты зависят от ваших инструментов, схема становится API
Каждая успешная внутренняя платформа рано или поздно сталкивается с ситуацией, когда кто-то изменяет схему, что нарушает работу потребителей, о существовании которых ранее никто не знал. MCP не является исключением.
Предположим, что версия 1 функции имеет вид calculate_risk(project_id), а версия 2 — calculate_risk(project_id, methodology="v2", include_history=True). Если вы сразу же внедрите новый вариант контракта у всех агентов и клиентов, это приведёт к изменению API, несовместимому с предыдущими версиями.
Система версионирования компонентов FastMCP позволяет нескольким реализациям одного инструмента, ресурса или запроса существовать под одним логическим идентификатором. По умолчанию предоставляется самая новая версия, а фильтры версий могут создавать отдельные интерфейсы для конкретных клиентов или определённых периодов миграции.
Более широкая архитектура имеет большее значение, чем конкретный API. Когда MCP становится общей инфраструктурой, развитие его возможностей должно рассматриваться так же, как и любой контракт на общественные услуги. Какие изменения приводят к сбоям? Какие клиенты всё ещё используют версию v1? Могут ли v1 и v2 работать параллельно, и как долго должно продолжаться окно миграции? Какая версия получила одобрение для использования в производстве, кто имеет к ней доступ, и в какой момент устаревшая версия уходит с эксплуатации? Полезный корпоративный реестр может в конечном итоге отслеживать название инструмента, поставщика, версию, «отпечаток» схемы, владельца, класс риска, дату и лицо одобрения, а также дату устаревания.
Для сервера с пятью инструментами это может показаться чрезмерным. Для платформы, обслуживающей 20 команд, — нет.
Как только другая система начинает использовать вашу схему MCP, это уже API, независимо от того, названо ли оно или нет.
11. Тестирование: проверяйте всю структуру MCP, а не только функцию на Python
Тестирование — это самый непривлекательный аспект здесь, но, возможно, самый важный. Представьте, что эта функция работает безупречно:
async def find_customer(company_name: str):
...
Тем не менее, сервер MCP может быть неисправен, причина ошибки может находиться где угодно в этой функции: неправильно сгенерированная схема, вводящее в заблуждение описание, преобразование, скрывающее неверный аргумент, пространство имён, тихо переименовавшее инструмент, настройки видимости, раскрывающие административные возможности, фильтрация авторизации для неверного пользователя, прокси, не передающий учетные данные, слой поиска, неспособный найти инструмент, фильтр версий, предоставляющий версию v1 вместо предусмотренной v2, вывод, не соответствующий своей структуре, или фоновая задача, которая так и не достигает окончательного состояния.
Именно поэтому лучшей практикой является тестирование самого интерфейса MCP. Руководство по тестированию FastMCP запускает реальный клиент против сервера внутри процесса, так что поведение протокола можно тестировать без необходимости развертывания отдельного сервиса. Вместо тестирования только реализации:
result = await find_customer("Acme")
assert result
Также проверьте, что на самом деле видит потребитель MCP:
async with Client(mcp) as client:
tools = await client.list_tools()
assert "salesforce_find_customer" in {
tool.name for tool in tools
}
result = await client.call_tool(
"salesforce_find_customer",
{"company_name": "Acme"},
)
Для платформы производственных возможностей тестированию должны подвергаться как минимум четыре слоя.
Тесты по контракту проверяют название инструмента, описание, схемы входных и выходных данных, аннотации и версию на соответствие ожиданиям.
Тесты на обнаружение определяют, какие инструменты видит конкретный пользователь и рабочий процесс, а какие остаются скрытыми, находит ли поиск нужную возможность и может ли случайно отобразиться запрещенные инструменты.
Тесты выполнения проверяют, успешен ли вызов, правильно ли структурированы ошибки, безопасны ли попытки повторного выполнения, передают ли прокси правильную идентификацию и проводится ли повторная авторизация во время выполнения.
Тесты жизненного цикла проверяют, завершаются ли фоновые задачи успешно или с ошибками, можно ли их отменить, сохраняет ли миграция версий работоспособность старых клиентов и что происходит, когда выходит из строя сервер MCP вышестоящего уровня.
Ничто из этого не является тестированием фреймворка. Это тестирование вашего контракта на использование продукта. Как только MCP станет слоем функциональности для нескольких клиентов и агентов, этот контракт заслуживает такой же строгой организации, как и интерфейсы REST, gRPC или событийного типа.
Собрав все элементы, сервер выглядит совершенно иначе
Если объединить все эти идеи, получится система, которая обеспечивает обнаружение ресурсов, маршрутизацию, адаптацию интерфейсов, контроль контекста, реализацию правил, работу с интерактивными рабочими процессами, асинхронную обработку задач, использование повторно применимых знаний, обеспечение совместимости и управление жизненным циклом разработки. Это уже давно перестал быть просто сервером с набором инструментов — это пользовательский интерфейс продукта. Что ещё лучше, ни один из этих элементов не требует от поставщика модели владения бизнес-логикой, поскольку та же платформа может работать за любым хостом, совместимым с MCP, который выберет организация. Именно это имеет стратегическое значение.
Часть наилучшей оптимизации происходит ещё до того, как модель что-либо увидит
Многие дискуссии о производительности ИИ сосредоточены на самой модели: какая именно, сколько у неё параметров, каков размер окна контекста, насколько хорошо она способна к логическим рассуждениям. Всё это важно, но в реальных условиях архитектура, окружающая модель, может устранить огромное количество ненужных операций.
Предположим, платформа содержит 300 инструментов. В наивном подходе все 300 схем загружаются в контекст большой языковой модели в надежде на правильный выбор. В продуманном подходе процесс сужается поэтапно: сначала политика ограничивает выбор до 85 допустимых схем, затем видимость рабочего процесса сокращает их до 24 наиболее релевантных, после чего поиск выделяет 4 кандидата, и именно эти 4 схемы загружаются для окончательного выбора модели.
Модель не стала умнее. Система — да. Именно поэтому эти закономерности так важны в реальных условиях работы. Контекст сокращается, точность выбора улучшается, ненужные действия исчезают, процедуры авторизации становятся более понятными, задачи бэкенда не влияют на работу модели, а независимые команды могут совместно работать, не сливая код, всё это до того, как от LLM требуется обдумать своё следующее действие.
Хорошая архитектура агентов не ограничивается улучшением способности модели к логическим рассуждениям. Она также формирует материал, над которым модели приходится размышлять.
От одного сервера MCP к сети таких серверов
Для корпоративных систем именно здесь развитие становится особенно интересным. Изначальная структура выглядела так:
AI client
↓
MCP server
↓
API
Следующий компонент больше похож на шлюз в центре, за которым находятся серверы доменов и рабочие узлы. Каждый сервер MCP сосредоточен на своей задаче, каждая команда отвечает за свой домен, а каждый сервис выпускается по собственному графику. Шлюз создаёт подходящий интерфейс для каждого пользователя, модель находит только то, что ей необходимо, длинный рабочий процесс преобразуется в задачу, а навык обучает агента тому, как компания ожидает выполнения рабочего процесса, причём всё это остаётся доступным через границы MCP.
Это гораздо ближе к платформе распределённых приложений, чем к набору обёрток для функций, поэтому называние серверов MCP «просто инструментами для LLM» всё чаще недооценивает их реальную роль.
Не создавайте платформу, пока не возникнет проблема, требующая платформы
Опасность очевидна. Прочитав всё это, можно прийти к выводу, что внутреннему серверу с пятью инструментами требуются три шлюза, реестр возможностей, встроенный поиск по схемам инструментов, несколько пространств имён, механизм согласования версий во время выполнения, распределённая очередь для задач, площадка для обмена навыками и дюжина наложенных преобразований.
Пожалуйста, не делайте этого.
Сервер с шестью стабильными инструментами, которые должен видеть каждый пользователь? Просто отправьте эти шесть. Если схема backend уже чистая, не добавляйте преобразование только потому, что фреймворк его поддерживает. С одним сервером нет необходимости в топологии прокси. Если операция завершается за две секунды, вряд ли она нуждается в задаче. Если никто больше не использует версию v1, нет причин вечно поддерживать две версии.
Архитектура должна возникать в ответ на проблему, а не наоборот. Цель не в том, чтобы максимизировать количество функций фреймворка в вашем репозитории. Речь идет о том, чтобы, когда возникает проблема, MCP не заставлял вас создавать полностью собственную платформу ИИ для ее решения. Теперь экосистема предоставляет повторно используемые элементы для решения тех же проблем, с которыми сталкивается любая зрелая платформа приложений, и это и есть прогресс.
Фреймворк можно заменить; важна архитектура
FastMCP заслуживает признания за то, что собрал многие из этих идей в одном месте. В его документации подробно рассматриваются провайдеры, преобразования, поиск, номенклатура, видимость, прокси, навыки, методы получения информации, задачи, версии и тесты, что позволяет легко понять, как связаны различные компоненты сервера MCP. Несколько из этих подходов уже используются в реальных проектах, поскольку они решают реальные проблемы: сокращение объема контекста инструмента, разделение контрактов, ориентированных на модели, от контрактов бэкенда, ограничение количества доступных функций, объединение интеграций и облегчение управления полученной системой.
Тем не менее командам следует скопировать саму идею, а не API библиотеки. Задайте себе вопросы: нужна ли нам функция поиска инструментов по запросу? Слой преобразования для работы с моделями? Шлюз функциональности? Возможность отслеживания процессов в рамках конкретных рабочих процессов? Навыки, распространяемые через ресурсы MCP? Надежный жизненный цикл для длительных операций? Контракты функциональности с версионированием? Проверяем ли мы то, что фактически видит клиент? Затем создайте решения с использованием той технологической стек, которая подходит вашей организации.
Протокол обеспечивает взаимодействие. Фреймворк — удобство. Архитектура остается вашей.
Что изменилось
Самое важное изменение в MCP заключается не в увеличении списка функций, а в расширении объема задач, которые должен выполнять сервер MCP. В начале всё было просто: публикуется инструмент, модель его вызывает, и возвращается результат. Современная модель включает в себя возможность получения данных из нескольких систем, нормализацию их интерфейсов, формирование уникальных идентификаторов, фильтрацию по релевантности, контроль допустимости действий, поиск информации в больших каталогах по запросу, предоставление повторно используемых навыков и контекста, задание вопросов пользователю при необходимости выбора, перевод медленных операций в формат надежной обработки, отслеживание всего процесса, версионирование интерфейсов и тестирование продукта как готового решения.
Это совершенно другая задача. MCP намеренно остаётся протоколом, а не фреймворком приложений, но экосистема вокруг него превращает серверы MCP в серьёзную основу для приложений, где могут быть реализованы слои маршрутизации, управления, жизненного цикла, совместимости и композиции, как это делается в зрелых бэкендах.
Хорошо спроектированный сервер MCP больше не является просто способом добавления ещё одной функции к большой языковой модели. Он может стать универсальным продуктом с повторно используемыми возможностями, полезным как для агентов, так и для моделей, команд и клиентских приложений. Одинокий сервер может оставаться небольшим, а сеть таких серверов может превратиться в корпоративную платформу. Модель остаётся гибкой, слой возможностей находится под контролем, а клиентский слой сверху можно заменять без необходимости пересоздания бизнес-функций, находящихся под ним.
Связанные материалы
- MCP 2026-07-28: Как бесстатусная версия 28.07.2026 меняет дизайн удаленных серверов — Как обновление MCP 28.07.2026 в бесстатусном режиме устраняет сессии и процедуру подключения, добавляет MRTR, задачи и подсказки к кэшу, и какое это влияние на миграцию.
- Cloud Browser: Безопасная платформа удаленного браузера для любого ИИ-агента — Пример проектирования универсальной удаленной браузерной службы, независимой от моделей: шлюз, рабочие процессы, прямая трансляция через WebRTC, механизмы утверждения, защита от SSRF, возможность повторного воспроизведения и все настройки.