Сервери MCP стають платформами з розширеними можливостями, а не просто обгортками для інструментів.
Сервери MCP перетворюються на платформи з різноманітними функціями: трансформація інструментів, пошук, простори імен, проксі, навички, завдання та версіонування, а також визначення моменту, коли варто відкласти дії.
Джерела: Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #7
Кожен, хто вже використовував сервер MCP у продакшені, вже знає цей перелік вимог: чіткі умови взаємодії з інструментами, структуровані вхідні та вихідні дані, зрозуміла семантика помилок, механізми автентифікації, можливість спостереження, чітке розділення того, що контролює модель, та того, що надає середовище виконання (ID користувача, тенант, ролі та обмеження), авторизація під час виконання та модель розгортання, яка дозволяє масштабуватися. Наступний крок — це не новий механізм передачі даних чи ще одна платформа агентів, і це не привід переписувати всю інфраструктуру. Справа в тому, що сервер 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("find customer opportunities and open deals") та отримати три-чотири результати, наприклад 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 досі підтримує функцію журналізації з боку клієнта, коли сервер надсилає повідомлення про дебагування, інформацію, попередження чи помилки назад до клієнта 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 схем у контекст ШІ з надією, що він правильно вибере. Ретельний підхід передбачає поступове звуження кола. Політика дозволів скорочує кількість інструментів з 300 до 85. Візуалізація робочого процесу зводить їх до 24 актуальних. Пошук залишає 4 кандидати, і саме ці 4 схеми завантажуються для остаточного вибору моделі.
Модель не стала розумнішою. Система — так. Це важлива причина, чому такі закономірності мають значення у практичному використанні. Контекст скорочується, точність вибору покращується, нерелевантні дії зникають, авторизація стає зрозумілішою, контракти бекенду не впливають на модель, а незалежні команди можуть працювати разом, не об’єднуючи код, і все це ще до того, як від LLM вимагають обміркувати наступну дію.
Чудова архітектура агента не обмежується лише покращенням здатності моделі до міркувань. Вона також формує матеріал, над яким модель мусить міркувати.
Від одного сервера MCP до мережі з них
Для корпоративних систем саме тут еволюція стає дійсно цікавою. Початкова структура виглядала так:
AI client
↓
MCP server
↓
API
Наступний елемент нагадує більше шлюз посередині, за яким знаходяться сервери доменів та робочі процеси. Кожен сервер MCP зосереджується на своїх функціях, кожна команда керує власним доменом, а кожен сервіс випускається за власним графіком. Шлюз створює відповідний інтерфейс для кожного користувача, модель знаходить лише те, що їй потрібно, довгий робочий процес перетворюється на завдання, а навичка навчає агента того, як компанія очікує виконання робочого процесу, причому все залишається доступним через межі MCP.
Це набагато більше схоже на платформу дистрибуйованих додатків, ніж на набір обгорток функцій, тому називання серверів MCP „просто інструментами для LLM“ все частіше не відображає їхнього справжнього потенціалу.
Не створюйте платформу, поки не виникне проблема, яку може вирішити платформа
Небезпека очевидна. Прочитавши все це, можна дійти висновку, що внутрішньому серверу з п’ятьма інструментами потрібні три шлюзи, реєстр можливостей, пошук у межах схем інструментів, кілька просторів імен, переговори версій під час виконання, розподілена черга для завдань, ринок навичок та десяток послідовних трансформацій.
Будь ласка, не робіть цього.
Сервер із шістьма стабільними інструментами, які має бачити кожен користувач? Просто надішліть ці шість. Якщо схема бекенду вже чиста, не додавайте трансформацію лише тому, що фреймворк її підтримує. З одним сервером немає потреби у топології проксі. Якщо операція завершується за дві секунди, ймовірно, вона не потребує завдання. Якщо ніхто більше не використовує версію v1, немає причин тримати обидві версії активними вічно.
Архітектура має виникати у відповідь на проблему, а не навпаки. Метою не є максимізація кількості функцій фреймворку у вашому репозиторії. Справа в тому, щоб коли з’являється проблема, MCP більше не змушував створювати навколо неї повністю індивідуальну платформу штучного інтелекту. Тепер екосистема надає повторно використовувані елементи для вирішення тих самих проблем, з якими стикається будь-яка зріла платформа додатків, і це є прогресом.
Фреймворк можна замінити; важлива архітектура
FastMCP заслуговує на похвалу за те, що зробив багато з цих ідей видимими в одному місці. Його документація розглядає провайдерів, трансформації, пошук, номенклатуру імен, видимість, проксі, навички, методи отримання інформації, завдання, версії та тести, що дозволяє легко зрозуміти, як взаємопов’язані елементи сервера MCP. Кілька з цих підходів використовуються в реальних проектах, оскільки вони вирішують реальні проблеми: скорочення обсягу інформації, розділення контрактів, орієнтованих на моделі, від контрактів бекенду, обмеження кількості доступних функцій, об’єднання інтеграцій та підтримка простоти керування результатом.
Проте команди повинні скопіювати саму ідею, а не API бібліотеки. Запитайте себе: чи потрібна нам можливість пошуку інструментів за запитом? Шар трансформації для роботи з моделями? Шлюз функціоналу? Візуалізація, специфічна для певного робочого процесу? Навички, розподілені через ресурси MCP? Надійний життєвий цикл для тривалих операцій? Контракти функціоналу у версіях? Чи тестуємо ми те, що насправді бачить клієнт? Потім створіть рішення за допомогою того стеку, який підходить вашій організації.
Протокол забезпечує взаємодію. Фреймворк — зручність. Архітектура залишається вашою.
Що змінилося
Найважливіша зміна в MCP — це не подовжений список функцій. Це розширення обсягу того, що очікується від сервера MCP. Спочатку все було просто: публікується інструмент, модель його викликає, і повертається результат. Тепер модель, яка поступово формується, включає збір можливостей з кількох систем, нормалізацію їхніх контрактів, створення унікальних ідентифікаторів, фільтрацію за релевантністю, авторизацію дозволених дій, пошук інформації в великих каталогах за потреби, надання повторно використовуваних навичок та контексту, постановку запитань користувачеві при необхідності вибору, переведення повільних операцій у стабільну реалізацію, відстеження всього процесу, версіонування контрактів та тестування продукту як справжнього товару.
Це зовсім інша робота. MCP навмисно залишається протоколом, а не фреймворком додатків, але екосистема навколо нього робить сервери MCP справжніми межами додатків, де можна створювати шари маршрутизації, керування, життєвого циклу, сумісності та композиції, як це робиться у зрілих бекендах.
Добре створений сервер MCP більше не є просто способом надати ШІ ще одну функцію. Це може бути продукт з можливостями, який можна використовувати знову та який слугує агентам, моделям, командам та клієнтським додаткам однаково. Одинокий сервер може залишатися невеликим, а мережа таких серверів може перетворитися на корпоративну платформу. Модель залишається гнучкою, шар можливостей контролюється, а клієнт, розташований зверху, можна замінити без необхідності перебудови бізнес-функцій під ним.
Пов’язана література
- MCP 2026-07-28: Як безстановий формат специфікації змінює дизайн віддалених серверів — Як безстанова версія MCP від 28.07.2026 відміняє сеанси та процедуру взаємодії, додає MRTR, завдання та підказки щодо кешу, та які наслідки це має для міграції.
- Cloud Browser: Безпечна платформа віддаленого браузера для будь-якого AI-агента — Описова схема моделі віддаленого браузерного сервісу, незалежного від конкретної моделі: шлюз, працівники, пряма трансляція через WebRTC, процедури схвалення, захист від SSRF, можливість повторного відтворення та кожна налаштування конфігурації.