Компанияға MCP-серверлерінің реестрі не үшін керек?

MCP-серверін модельге арналған жай ғана кітапхана деп қарауға болмайды. Ол модельді, пайдаланушыны және сыртқы жүйені байланыстырады, сондықтан құжаттарды оқуға, жазбаларды іздеуге, өтінімдер жасауға, хабарлама жіберуге немесе деректерді өзгертуге нақты мүмкіндік алады. Компания қандай коннекторларға рұқсат берілгенін және олар үшін кім жауапты екенін білмесе, оларды бәрібір басқарып отыр, тек бұл басқару ноутбуктер мен репозиторийлердегі кездейсоқ конфигурациялар арқылы жүзеге асады.

MCP-серверлерінің реестрі инженерлерге тәжірибе жасауға тыйым салу үшін керек емес. Ол қысқа мерзімді экспериментті жұмыс процесінің бөлігіне айналған қосылымнан ажыратады. Жақсы жазба қарапайым көрінгенімен шешуші сұрақтарға жауап береді: нақты қай сервер іске қосылған, ол қайдан алынған, қандай құралдарды жариялайды, қандай деректерді көреді, оны түнде кім өшіреді және шешімді қашан қайта қарау керек.

Реестр табылған нысандардың тізімін емес, компания шешімін бекітеді

Сыртқы каталог «қандай MCP-серверлері бар?» деген сұраққа жауап береді. Ішкі каталог басқа сұраққа жауап береді: «олардың қайсысына компаниямыз нақты орталарда және қандай шарттармен рұқсат береді?» Бұл екі мағынаны араластыру қауіпті. Жазбаның ашық реестрде немесе танымал репозиторийде пайда болуы банк, телеком-оператор немесе SaaS-команда ішінде оған автоматты түрде сенім бермейді.

Ресми MCP реестрі серверді метадеректер, нұсқалар, пакеттер немесе қашықтағы қосылу нүктелері арқылы сипаттайды. Бұл табу және жеткізу үшін пайдалы формат. Бірақ жеткізушінің метадеректері ішкі рұқсат үшін жеткіліксіз: онда әдетте деректеріңіздің санаты, бизнес-жүйенің иесі, тексеру мерзімі, рұқсат етілген пайдаланушылар топтары және журнал жүргізу туралы шешім болмайды.

Ішкі реестр сыртқы реестрді қайталауға міндетті емес. Ол қауіпсіздік қызметі, платформа және жүйе иесі «рұқсат ету», «құмсалғышта қалдыру», «уақытша тоқтату» немесе «бұғаттау» туралы шешім қабылдай алатын өрістерді қосуы керек.

Жазбаның өзгермейтін ішкі атауы болуы тиіс. Оған crm-mcp немесе filesystem-tools сияқты тек көрсетілетін атауларды пайдаланбаңыз, мұндай атаулар тез қайталанады. Иенің домені мен мақсатын біріктіру тиімдірек, мысалы com.company.sales.crm-readonly. Команда кейін репозиторийдің атауын өзгертсе де, бұл атау аудит журналдарында, конфигурациялар мен өтінімдерде сақталады.

Ең аз дегенде жазбада мыналар болуы керек:

• ішкі идентификатор және түсінікті көрсетілетін атау;
• рұқсат мәртебесі және оның қолданылатын орталары;
• техникалық иесі және қосылатын жүйенің иесі;
• жеткізу тәсілі, нақты нұсқасы немесе образ digest-і;
• тасымалдау протоколы, қашықтағы сервер мекенжайы немесе іске қосу командасы;
• жарияланған құралдар, құқықтар, деректер түрлері және келесі тексеру мерзімі.

Егер өрістерді адам немесе машина бірнеше минут ішінде тексере алмаса, олар инцидент кезінде көмектеспейді. «Талдау үшін пайдаланылады» деген өріс жарамайды. «CRM репликасындағы orders және customers кестелерін оқиды, жазуға тыйым салынған, қолжетімділік svc-mcp-crm-ro сервистік тіркелгісі арқылы беріледі» деген жазба әлдеқайда пайдалы.

Үш мәртебе ұзын жетілу шкаласынан жақсы

Алғашқы жұмыс реестрі үшін «рұқсат етілген», «тест» және «бұғатталған» мәртебелері жеткілікті. «Кандидат», «қаралуда», «пилот», «шектеулі рұқсат етілген», «ескіріп келеді» сияқты ұзын шкала шешімді сөздер туралы дауға айналдырады. Қосымша белгілерді жаңа мәртебелер ойлап таппай, бөлек өрістерде сақтаған дұрыс.

Рұқсат етілген деген нақты нұсқа немесе рұқсат етілген нұсқалар аралығы нақты анықталған орталар, пайдаланушылар және құқықтар үшін тексеруден өткенін білдіреді. Бұл мәртебе «бәрі қоса алады» дегенді білдірмейді. Білім базасын оқитын сервер қолдау қызметкерлеріне рұқсат етілуі мүмкін, бірақ сыртқы чат-ботқа тыйым салынуы мүмкін. Сатып алу жүйесіне арналған коннектор тек тест контурында рұқсат етілуі ықтимал.

Тест компанияның шектеулі экспериментке рұқсат беретінін білдіреді. Оның қатысушылары, ортасы, деректер жиыны, аяқталу күні және эксперимент иесі алдын ала белгіленеді. Аяқталу күні, пайдаланушылар лимиті және қолжетімділікті тез қайтарып алу мүмкіндігі жоқ тест мәртебесі жасырын production-ға айналады. Жұмыс ортасына «бір-екі күнге» берілген токендердің осылай түсіп кеткенін көрдім.

Бұғатталған клиент, прокси немесе орнату саясаты қосылымға жол бермеуі керек дегенді білдіреді. Бұғаттау себебін нақты жазыңыз: расталмаған пакет көзі, артық рұқсаттар, осалдық, қолдаудың тоқтатылуы, деректерді орналастыру талаптарымен қайшылық немесе жеткізуші шарттарының бұзылуы. «Ұсынылмайды» деген тұжырым жарамайды, өйткені ол адамға өзіне ыңғайлы түсіндіруге мүмкіндік береді.

Тыйым салынған жазба жоғалмауы керек. Себебі мен бұғаттау күні көрсетілген архив сол жобаны жаңа атаумен қайта импорттауға жол бермейді. Ол аудиторға команда мәселені талқылауды ғана тоқтатпағанын, қолжетімділікті жауып, құпияларды қайтарып алғанын да көрсетеді.

Нұсқасы мен құралдар жиыны бақылаусыз өзгеретін болса, сервердің өзін толықтай «рұқсат етілген» деп белгілемеңіз. Рұқсат брендке, GitHub ұйымына немесе доменге берілмейді. Рұқсат нақты ортада мінез-құлқы түсінікті нақты артефактқа беріледі.

Иесінің коннекторды өшіруге өкілеті болуы керек

Әр MCP-серверіне кемінде екі жауапты адам қажет. Техникалық иесі кодқа, құрастыруға, тәуелділіктерге, нұсқа шығаруға, бақылауға және ақауларды түзетуге жауап береді. Қосылатын жүйенің иесі серверге осы деректерді көруге немесе өзгертуге шынымен рұқсат бар-жоғын бақылайды. Екі мандаттың бір адамда болуы сирек кездеседі.

Мысалы, AI Platform командасы ішкі құжаттар қоймасынан іздеуге арналған серверді қолдауы мүмкін. Бірақ шарттарды немесе кадрлық файлдарды оқуға рұқсат беру құқығы платформа командасына тиесілі емес. Мұны қойма иесі және қажет болса, деректерге жауапты адам растауы керек. Әйтпесе платформа өз өкілетіне кірмейтін шешімді кездейсоқ қабылдайды.

Реестрде жай ғана пошта тізімін көрсетпеңіз. Нақты рөл, команда және жұмыс істейтін эскалация жолы қажет. owner: data-team жазбасы жұма кешінде токенді кім қайтарып алатыны белгісіз болғанда нашар жұмыс істейді. Техникалық иесі, кезекші резервтік тобы және жүйе иесі көрсетілген жазба ұйымдық құрылымды іздемей әрекет етуге мүмкіндік береді.

Иесіне тек атаулы міндет жүктеуге болмайды. Ол кемінде мына төрт әрекетті орындай алуы керек:

• құралдар мен құқықтарды кеңейтуді растау немесе қабылдамау;
• жаңа нұсқаның таралуын тоқтату;
• инцидент кезінде құпияларды қайтарып алып, серверді өшіру;
• мерзімі аяқталғанға дейін қайта бағалау сұрағына жауап беру.

Егер адам конфигурацияны да, токендерді де, шығарылымды да бақыламаса, ол иесі емес. Ол хабарландыру алатын байланыс тұлғасы. Бұл екі түрлі рөл, ал оларды бірінің орнына бірін көрсету реестрді жай сәндік құралға айналдырады.

successor_required өрісін қосу пайдалы. Иесі басқа командаға ауысқанда немесе жұмыстан кеткенде, жаңа жауапты адам жазбаны қабылдағанға дейін ол автоматты түрде шектеулі немесе тест мәртебесіне ауысуы керек. Әйтпесе ескі коннектор адамдардың ауысқанын ешкім байқамағандықтан ғана жылдар бойы деректерді оқи береді.

Рұқсаттарды әрекеттер мен деректер арқылы сипаттау керек

«Серверде тек оқу құқығы бар» деген сөздің өзі көп нәрсе айтпайды. Ол зиянсыз тауарлар каталогын да, клиент шарттарын, бастапқы кодты және әңгіме жазбаларын да жүктеп алуы мүмкін. Реестр рұқсаттарды нақты әрекеттер мен деректер санаттары деңгейінде сипаттауы керек.

MCP спецификациясы сервер мүмкіндіктерін құралдарға, ресурстарға және промпттарға бөледі. Тәуекелді бақылау үшін бұл маңызды айырмашылық. Құрал параметрлер арқылы әрекет орындайды немесе дерек алады, ресурс әдетте URI арқылы контекст береді, ал промпт өзара әрекет шаблонын ұсынады. Іс жүзінде ең қауіпті нысан атауы қорқынышты нысан емес, search сияқты зиянсыз көрінетін, еркін сұрау қабылдап, пайдаланушы құқықтары бойынша сүзгісіз құжаттарды қайтаратын құрал болуы мүмкін.

Әр құралға рұқсат карточкасын жасаңыз. Онда бүкіл JSON Schema-ны қайталаудың қажеті жоқ, бірақ шақыру салдарын көрсету керек:

«Оқу» және «жазу» деген белгілермен шектелмеңіз. Сыртқы арнаға хабарлама жіберу, дерекқорға сұрау орындау, файл жүктеу, тапсырма жасау, нысанды жою және қолжетімділік құқықтарын өзгерту әртүрлі салдарға әкеледі. Реестр бұл салдарды коннектордың құрылымын білмейтін адамға модель құралды ұсынғанға дейін көрсетуі керек.

Жанама жазуға ерекше назар аударыңыз. Сервер формалды түрде CRM жүйесінен тек оқуы мүмкін, бірақ кейін табылған мәтінді жіктеу үшін сыртқы API-ге жібереді. CRM иесі үшін бұл жай оқу емес, деректерді беру болып саналады. Реестрде кіріс деректерді, шығыс деректерді және барлық сыртқы алушыларды көрсетіңіз.

«Модель бәрібір пайдаланушыдан сұрайды» деген уәжді қабылдамаңыз. MCP клиенттері растауды көрсете алады, бірақ интерфейс дизайны, клиент саясаты және іске асыру ерекшеліктері өзгеріп отырады. Қауіпті әрекеті бар сервердің өзі шектелуі керек, қауіпсіздік пайдаланушы әр жолы диалогты оқиды деген үмітке сүйенбеуі тиіс.

Қашықтағы қолжетімділік пен жергілікті процесс әртүрлі тексеруді қажет етеді

Клиент stdio арқылы іске қосатын жергілікті сервер мен Streamable HTTP арқылы жұмыс істейтін қашықтағы сервердің тәуекел шекаралары әртүрлі. Оларды «MCP қолданылады» деген бір ғана белгімен бағалауға болмайды.

Жергілікті процесс пайдаланушы құрылғысында немесе жұмыс хостында жұмыс істейді. Орындау ортасын шектемесеңіз, ол файлдық жүйеге, орта айнымалыларына, прокси баптауларына, жергілікті сертификаттар мен тіркелгі деректеріне қол жеткізе алады. Сондықтан реестрде пакет көзі, хеш немесе digest, іске қосу командасы, рұқсат етілген орта айнымалылары, файлдық жүйе құқықтары және жаңарту саясаты маңызды.

Қашықтағы сервер тәуекелдің бір бөлігін желі мен қашықтағы инфрақұрылымға ауыстырады. Ол үшін домен атауын, аутентификация тәсілін, өңдеу аймағын, TLS саясатын, шығыс трафик шектеулерін, журнал жүргізуді және қолжетімсіздік кезіндегі әрекетті бекітіңіз. Сервер OAuth қолданса, «OAuth қосылған» деген фактпен ғана шектелмеңіз. Токен аудиториясын, қажетті scopes мәндерін, жарамдылық мерзімін, қайтарып алу жолын және тіркелгі түрін де сақтаңыз.

Қашықтағы серверлерге арналған MCP авторизациясының ресми спецификациясы OAuth тәсіліне сүйенеді және ресурсты алмастырудан және токендерді қате беруден қорғауды бөлек сипаттайды. Бұл әзірлеуші конфигурациясынан бір bearer token көшіріп, ортақ құпияға салуға рұқсат бермейді. Токен нақты клиент пен нақты ресурс үшін берілуі керек, ал сервер басқа алушыға арналған токенді қабылдамауы тиіс.

Төменде құпияларды емес, қашықтағы қосылымның тексерілетін келісімшартын қалай сақтауға болатыны көрсетілген:

id: com.company.support.ticketing
status: approved
transport:
  type: streamable-http
  endpoint: https://mcp.support.internal.example/mcp
identity:
  method: oauth2
  audience: https://mcp.support.internal.example
  scopes:
    - tickets.read
    - tickets.create
network:
  egress: internal-only
  data_region: kz
allowed_tools:
  - search_ticket
  - create_ticket
review:
  reviewed_on: 2026-07-23
  expires_on: 2026-10-23
owners:
  technical: ai-platform-oncall
  system: service-desk-owner

Бұл үзінді жиі кездесетін қатені болдырмайды: команда сервер мекенжайын есте сақтайды, бірақ токен қай аудиторияға берілгенін және қандай әрекеттерге шынымен рұқсат барын бекітпейді. Құпиялар құпияларды басқару менеджерінде немесе идентификация жүйесінде қалады. Реестр құпияның өмір сүруге құқығы бар-жоғын тексеретін ережелерді сақтайды.

Тексеру мерзімі тәуекел өзгерісіне байланысты болуы керек

Бүкіл тізімді жылына бір рет қайта қарау есеп үшін ыңғайлы, бірақ қауіпсіздік үшін нашар. Тест ортасындағы иесіздендірілген анықтамалықты оқитын сервер мен қаржылық операциялар жасайтын сервер бір күнтізбе бойынша жұмыс істемеуі керек.

Тексеру мерзімі қате салдарының қаншалықты тез өзгеретініне қарай белгіленеді. Кемінде төрт нәрсені ескеріңіз: жазу мүмкіндігі, деректердің сезімталдығы, сыртқы жіберу және қоңыраудың автономдылығы. Серверде осы мүмкіндіктер неғұрлым көп болса, мерзім соғұрлым қысқа, ал шарттар соғұрлым қатаң болуы керек.

Жазбадағы мерзімге дейін мына оқиғалардың бірі болса, қайта бағалау жүргізіледі:

• сервер жаңа құрал алды немесе бар құралдың мағынасы өзгерді;
• scopes, сервистік тіркелгі немесе авторизация моделі өзгерді;
• пакет, контейнер базасы немесе қашықтағы қосылу нүктесі жаңартылды;
• деректер иесі, өңдеу аймағы немесе жеткізуші өзгерді;
• деректердің тарағанын растамаса да, инцидентті тергеу басталды.

Артефактты қайта қарау мен рұқсатты қайта қарауды ажыратыңыз. CVE түзетілген кітапхана жаңартылса, техникалық бағалау қажет. Бар серверге send_email қосылса, рұқсатты қайта бағалау керек, өйткені бизнес салдары өзгерді. Командалар мұны жиі араластырады: жаңарту кәдімгі patch ретінде енгізіледі де, онымен бірге жаңа құралдар жиыны келеді.

Мерзім кестеде жай ғана өтіп кетпеуі керек. Егер иесі қайта қарауды растамаса, автоматтандыру жазбаны «рұқсат етілген» мәртебесінен шектеулі режимге ауыстыруы немесе жаңа қосылымдарды бұғаттауы керек. Нені өшіру керегі жүйенің маңыздылығына байланысты. Бірақ мерзімі өткеннен кейін approved мәртебесін сол күйінде қалдыруға болмайды, әйтпесе күн өрісі рәсім үшін ғана жазылған белгіге айналады.

Тексеру құралдардың нақты тізімін көруі керек

MCP-серверіне рұқсат бергендегі негізгі қате, іске қосылған нұсқаның әрекетін емес, README файлын тексеру. Сипаттама тез ескіреді. Сервер нұсқаға, орта жалаушасына, тіркелгіге немесе қашықтағы конфигурацияға байланысты басқа құралдар жиынын қайтара алады.

Тексеру серверді тест тіркелгілері бар оқшауланған ортада іске қосып, инициализация нәтижесін, құралдар тізімін және олардың кіріс схемаларын сақтауы керек. MCP Inspector мұндай техникалық тексеруге жарайды, бірақ оны рұқсат беру шешімімен шатастыруға болмайды. Inspector сервердің нені жариялайтынын көрсетеді. Мұны пайдалануға бола ма деген шешімді иелер мен бақылау процесі қабылдайды.

Практикалық бақылауды мүмкіндіктер суретінің айналасында құруға болады. Мысалы, команда күтілетін жиынды репозиторийде сақтайды:

{
  "server_id": "com.company.docs.search",
  "version": "1.8.4",
  "allowed_tools": [
    "search_documents",
    "get_document_excerpt"
  ],
  "forbidden_tools": [
    "download_document",
    "share_document"
  ]
}

Пайплайн серверді іске қосып, tools/list шақырады және атауларды осы суретпен салыстырады. Егер share_document пайда болса, құрастыруға автоматты түрде рұқсат мәртебесін беруге болмайды. Әзірлеуші бұл құралды модель әзірге пайдаланбайды деп есептесе де, ол қолжетімділік бетін өзгертті.

Тек атауларды тексермеңіз. Сипаттамаларды, міндетті параметрлерді, ұзындық шектеулерін, ресурс URI-ларын және қате кезіндегі әрекетті қараңыз. get_invoice құралы параметрдегі id шаблон қабылдап, басқа құжаттарды жаппай қарауға мүмкіндік беретіні анықталғанға дейін қауіпсіз көрінуі мүмкін. Бірнеше теріс сценарийді қолмен тексеру схеманы формалды оқудан көбірек нәрсе табады.

Қысқа тексеру хаттамасы пайдалы. Онда артефакт нұсқасы, күн, орта, пайдаланылған тест тіркелгілері, анықталған мүмкіндіктер тізімі, реестрден ауытқулар және шешім болуы керек. Нақты токендерді, дербес деректер үзінділерін немесе бизнес-жүйенің толық жауаптарын сақтамаңыз.

Бұғаттау тек жолдағы мәртебені емес, қосылу жолын өшіруі керек

«Бұғатталған» мәртебесі бұрыннан бапталған клиентті тоқтатпайды. Жетілген схема бойынша реестр кемінде бір орындау механизмімен байланысты болады: жұмыс станциясындағы саясат, шығыс трафигін бақылау, прокси, конфигурациялар каталогы, CI тексеруі немесе қашықтағы MCP-қосылымдарына арналған шлюз.

Бұғаттаудың өз реті бар. Алдымен жаңа қосылымдарды тоқтатып, орталық конфигурацияда серверді өшіріңіз. Кейін OAuth grants, API кілттерін, сервистік тіркелгілерді және құпияларға қолжетімділікті қайтарып алыңыз. Осыдан кейін аудит журналдарын тексеріңіз: коннекторды кім пайдаланды, қандай құралдар шақырылды, қандай токендер әлі белсенді. Тек содан соң жазбаны архивтік деп белгілеңіз.

Уақытша қолжетімсіздік пен бұғаттау бір нәрсе емес. Жеткізуші істен шықса, рұқсат мәртебесін сақтай отырып серверді уақытша пайдаланудан шығаруға болады. Ал сервердің жұмыс құжаттарын рұқсат етілмеген сыртқы сервиске жіберетіні анықталса, ол бөлек шешім қабылданғанға дейін бұғатталады. Бұл айырмашылық кезекші команда үшін маңызды: бірінші жағдайда қалпына келтіру керек, екіншісінде таралуды тежеу қажет.

Қазақстан және Орталық Азия ұйымдары үшін деректердің орналасуын және олардың берілу бағытын бөлек бекітіңіз. Деректерді ел ішінде сақтау талабы «жергілікті сервер» деген бір жазумен орындалмайды. Компоненттер қайда жұмыс істейтіні, сервер сұрауларды қайда жіберетіні, жеткізушіде қандай журналдар қалатыны және резервтік ауысу кезінде не болатыны туралы расталған мәліметтер керек.

AI Router бірыңғай OpenAI-үйлесімді API арқылы модельдерге жасалатын қашықтағы қоңырауларды бақылау нүктесі бола алады, бірақ ол MCP-коннекторларының реестрін алмастырмайды. Реестр сервердің жүйелер мен деректерге қолжетімділігіне жауап береді, ал модель шлюзі LLM сұрауының маршрутына, кілт ережелеріне және өз деңгейіндегі журналдауға жауап береді.

Реестрді бір кестеге емес, жеткізу процесіне енгізу керек

Бастапқыда кесте пайдалы, бірақ қолмен жүргізу ондаған команда мен жылдам жаңартуларға төтеп бере алмайды. Шынайы дерек көзі өзгерістері review арқылы өтетін, тарихы сақталатын және автоматты түрде тексерілетін репозиторийде немесе жүйеде болғаны дұрыс. Веб-интерфейсті адамдар файлдармен жұмыс істеуден қинала бастағанда кейін қосуға болады.

Әр өзгерісте CI тексеретін жазба схемасынан бастаңыз. Тексеру иесі, аяқталу күні, орта, жеткізу тәсілі жоқ немесе бекітілген профильде жоқ құралға рұқсат берілген жазбаны қабылдамауы керек. Осылайша сіз шабуылдарды емес, кәдімгі инженерлік ұқыпсыздықты шығарылымға дейін анықтайсыз.

Содан кейін реестрді серверлер іс жүзінде пайда болатын үш орынмен байланыстырыңыз:

1. MCP клиенттерінің конфигурациясымен. Клиент тек approved мәртебесі бар және сәйкес ортаға арналған жазбаларды алады.
2. CI/CD жүйесімен. Пайплайн жарияланған артефакт пен анықталған мүмкіндіктерді рұқсат карточкасымен салыстырады.
3. Идентификация жүйесімен. Токен немесе сервистік тіркелгі тек жазбада көрсетілген серверге және scopes мәндеріне беріледі.

Бірінші айда әрбір бейресми скриптті сипаттауға тырыспаңыз. Алдымен production, дербес деректер, қаржы жүйелері, пошта, файл қоймалары және сыртқы API-лерге тиетін коннекторларды енгізіңіз. Сонымен бірге мына ережені бекітіңіз: жаңа MCP-сервер реестрдегі жазбасыз ортақ каталогқа түспейді және жұмыс құпияларын алмайды.

Осыдан кейін ешкім еске алғысы келмеген ескі қосылымдар табылады. Бұл қалыпты нәтиже, процестің сәтсіздігі емес. Оларды көрінбейтін күйде қалдырып, модель төлем жасауға, құжат ашуға немесе деректерді рұқсат етілген контурдан тыс жіберуге мүмкіндік алған кезде ғана білген әлдеқайда қауіпті.

Реестр абсолютті қауіпсіздікке уәде бермеуі керек. Ол жауапкершілікті, құқықтарды және қолданылу мерзімін қосылымға дейін көрінетін етуі тиіс. Компанияда жаңа коннектор пайда болғанда, бірінші сұрақ «оның әдемі demo-сы қандай?» емес, «оның мәртебесі қандай, ол не істей алады және stop батырмасын кім басады?» болуы керек.