Своих MCP‑серверов у нас два: один к Битрикс24, второй к нашей системе заявок Okdesk. К Copilot оба подключены штатным путём, по документации Microsoft. Я Александр Жогов, основатель ИТ‑компании «+Альянс».
Путь оказался короче, чем я ожидал. И упирается он в одну строку документации. Ту самую, которую я бы читал первой.
Обе страницы, на которые тут ссылаюсь, я открывал 4 сентября 2026 года. Версий у них нет, правки приезжают тихо. Перед своим подключением сходите по ссылкам сами: вдруг за прошедшее время формулировка уехала.
Сначала транспорт. Всё остальное потом
Та самая строка живёт на странице «Connect your agent to an existing Model Context Protocol (MCP) server» (learn.microsoft.com, ms.date = 2026–05-28, updated_at = 2026–08-19):
“Currently, Copilot Studio supports the Streamable transport type.”
Соседняя строка объясняет, откуда взялось ограничение: «Given that SSE transport is deprecated, Copilot Studio no longer supports SSE for MCP after August 2025».
Из двух ходовых транспортов MCP остаётся Streamable HTTP. SSE после августа 2025 года Copilot Studio для MCP не поддерживает.
Если ваш сервер писался раньше и отвечает по SSE, это стоп‑кран. Подключать его в текущем виде нельзя: сначала транспортный слой. Хорошая новость одна: проверяется это быстро — открыть свой код и посмотреть, чем сервер отвечает клиенту.
У меня ушла минута.
Я бы тратил её до всего остального. Выяснить про транспорт после того, как согласовал с безопасностью схему авторизации, — удовольствие ниже среднего.
Как цепляют сервер, который уже написан
Страница про подключение существующего сервера открывается ровно нашим случаем: «If you already set up a Model Context Protocol (MCP) server, you can connect the MCP server to your agent». Сервер поднят — остаётся подключить его к агенту.
Способов документация даёт три.
Первый — мастер онбординга внутри самого Copilot Studio: “Add the MCP server in Copilot Studio by using the MCP onboarding wizard (recommended)”. Второй уместился в одну строку: «Create a custom connector to your server through Power Apps». Третий заявлен как организационный — «you can register your existing MCP server in Agents 365 using the Agents 365 CLI and Microsoft 365 Admin Center… it becomes available for use in Copilot Studio». Формулируется он как «Bring your own MCP server»: сервер сначала регистрируется в Agents 365 через CLI и админ‑центр, а потом становится доступен в Copilot Studio.
Слово recommended во всём перечне стоит ровно у одного пути.
Кого сервер пускает к себе
Тип аутентификации выбирается при подключении сервера, документация перечисляет варианты дословно: «Select the authentication type for your MCP server, if applicable. You have three options: None; API key: Configure API key authentication; OAuth 2.0: Configure OAuth 2.0 authentication». Три варианта: без аутентификации, с ключом API или по OAuth 2.0; других нет.
У OAuth 2.0 внутри своя вилка — режимы «Dynamic discovery», “Dynamic” и «Manual». Различаются они, по документации, тем, поддерживает ли MCP‑сервер автоматическую регистрацию клиента (DCR), и если поддерживает — с обнаружением конечных точек или без него.
Практический вывод отсюда такой: какой режим вам подойдёт, решает не настройка в Copilot Studio, а свойства самого сервера. Идти за ответом надо в свою реализацию OAuth.
Место, которое я бы выделил жёлтым
Про доступ к MCP‑серверам страница о подключении существующего сервера говорит вот что:
“Access to MCP servers in Copilot Studio relies on Power Platform connectors for connectivity. This condition means that if a data policy regulates Power Platform connectors, it also regulates access to the MCP server and its tools for your agent.”
Связка получается такая. Подключение к MCP‑серверам в Copilot Studio идёт через коннекторы Power Platform. И если в тенанте есть политика данных, которая эти коннекторы регулирует, она распространяется и на доступ вашего агента к MCP‑серверу и к его инструментам.
Теперь представьте отладку. Сервер поднят, транспорт правильный, авторизация настроена, инструментов агент не видит. Причина может лежать в политике данных тенанта, которую заводил вообще другой отдел и совсем по другому поводу.
Сама связь описана прямым текстом, это документация. Моё дополнение — про очерёдность: политику я держу в списке первых гипотез, а не последних.
Где в большом Copilot живёт MCP
До сих пор речь шла про Copilot Studio. Рядом стоит вторая история — коннекторы Microsoft 365 Copilot, и термины там свои.
Страница «Copilot connectors overview» (learn.microsoft.com, ms.date = 2026–05-14, updated_at = 2026–08-13) делит их на два типа: «Your organization can either index external data by using synced connectors or connect to data in real time by using federated connectors». Про второй тип сказано без обиняков: «Federated connectors: Use a Model Context Protocol (MCP) model to fetch data in real time, without indexing content into Microsoft 365». Федеративный коннектор построен на модели MCP и тянет данные в момент обращения, ничего не индексируя.
Отдельной третьей ветки под названием «MCP» в этой классификации нет.
Свойства федеративного типа перечислены дословно: «No indexing required; data remains in the source system»; “Connector fetches responses in real time through MCP APIs”; “Secure by design; federated access respects source permissions and authentication (OAuth 2.0)”. Индексации не требуется, данные остаются в системе‑источнике, права источника и OAuth 2.0 соблюдаются.
А вот строка, которую стоит сверить со своими ожиданиями заранее:
“Federated connectors are read‑only; they can search and fetch content but can’t write data back.”
Искать и получать контент — да. Писать обратно в источник — нет.
Оговорюсь: read‑only — это свойство, которое документация называет у федеративных коннекторов. Распространяется ли оно на инструменты вашего MCP‑сервера в агенте Copilot Studio, страница «Copilot connectors overview» не сообщает.
Готовые федеративные коннекторы поставляет сам Microsoft: “Default federated connectors are provided by Microsoft and appear as Ready in your connections list in the Microsoft 365 admin center”. Такие коннекторы видны в списке подключений центра администрирования Microsoft 365 со статусом Ready.
Чего на этих двух страницах нет
На обеих страницах, «Copilot connectors overview» и «Connect your agent to an existing Model Context Protocol (MCP) server», я 4 сентября 2026 года не встретил трёх вещей.
Списка совместимых MCP‑серверов сторонних разработчиков там нет. Описана механика подключения существующего сервера, и только она. Значит, проверку совместимости никто за вас не сделал: берёте документацию своего сервера и сверяете два пункта — транспорт и то, как у него устроена регистрация клиента в OAuth.
Дальше лимиты. Сколько MCP‑серверов и коннекторов организация может подключить, документация не говорит: лимита на их число там не названо. Архитектуру, где число подключений критично, ссылкой на документацию не обоснуешь — это допущение проекта, и записывать его надо как допущение.
Третье — поведение при одновременном synced‑ и federated‑коннекторе к одному источнику. Что увидит пользователь, документация не описывает. Проверять придётся своими руками. Если оба подключения в вашем случае собираются, мой порядок был бы такой: поднять тестовый тенант, подключить там одну систему обоими типами коннекторов, задать агенту контрольный вопрос по данным этой системы и записать, что вернулось. Запись с датой и станет вашим основанием для проектного решения.
Наша сторона: Python, контейнеры и несколько переписываний
Здесь документация заканчивается и начинается наш опыт. Это наша практика, нормой платформы она не является.
Оба сервера написаны на Python и крутятся в контейнерах. В Битрикс24 и Okdesk они авторизуются штатными методами самих этих продуктов.
Главное, что я вынес из работы: сервер живёт не в момент запуска, а весь срок эксплуатации. Переписывать наши серверы пришлось несколько раз, причин было две. Обновляются сами продукты — и Битрикс24, и Okdesk. И схему выдачи мы расширяли сами: по Битрикс24 начинали с контактов и компаний, а дальше доросли до сделок, предложений, счетов, сотрудников и телефонных разговоров.
Была ещё попытка обойтись без MCP — отдельный агент, ходивший в Битрикс24 напрямую.
Отказались.
Такой агент работает с данными одной системы, а запрос нужен был сразу по всем данным компании. Ради этого всё и затевалось.
Одну развилку я так и не закрыл
Из трёх пробелов документации сильнее всего меня цепляет последний. Допустим, в тенанте к одной системе подключены сразу оба коннектора: индексирующий synced и федеративный по MCP. Что окажется в ответе — индексная копия, живая выдача или обе сразу, с дублями?
Честный ответ у меня один: не знаю. На странице «Copilot connectors overview» этого нет, а выдавать догадку за норму платформы я не стану.
Пока замера нет, я считаю поведение неподтверждённым и в проектных решениях на него не опираюсь.
