MCP-ն գործակալին հասցնում է API, սակայն դաշտերի մակարդակով հասանելիությունը ինքը չի որոշում

2026 թվականի սեպտեմբերի 29-ին The New Stack-ում հրապարակվեց Apollo GraphQL-ի հիմնադիր Մեթ դըԲերգալիսի հոդվածը. MCP-ի միջոցով համակարգին հասնելն այսօր հեշտ է, սակայն այն, թե ինչ կարող է տեսնել գործակալը միացումից հետո, MCP-ն ինքը չի որոշում։

Հասանելիությունն այսօր հեշտ է, տեսանելիությունը՝ ոչ

Հոդվածում օգտագործվում է օպերացիաների թիմի օրինակ. աշխատակիցը օգնականին խնդրում է որոշել, թե որ պատվերը չի հասցնի առաքման ժամկետին, ստուգել այլ պահեստների մնացորդը և ստեղծել տեղափոխման հարցումներ այնտեղ, որտեղ դա կփակի դեֆիցիտը։ Գործընթացին անհրաժեշտ են ընթացիկ պատվերներ, հասանելի պաշար և հետադարձ գրառում։

Ներքին API-ն գործակալին հասանելի դարձնելը հնարավոր է MCP սերվեր կառուցելով, սակայն դժվար հարցն այն է, թե ինչ տեսնելու իրավունք պետք է ունենա նա միանալուց հետո։

Ինչու ակնհայտ լուծումները չեն լուծում խնդիրը

Պատվերների կառավարման API-ն կարող է վերադարձնել շատ ավելին, քան պատվերի կարգավիճակը՝ անձնական տվյալներ, ֆինանսական և խարդախության մանրամասներ, ինչպես նաև գործառնական տեղեկատվություն, որը չպետք է դուրս գա վստահելի ցանցից։ Սովորական հավելվածում դա որոշում է սերվերը. ստուգում է իրավունքները և վերադարձնում միայն համապատասխան տեսքը։

Գործակալը կոտրում է այս սխեման. գործիքը, որը վերին համակարգից ամեն ինչ փոխանցում է, անվտանգության ռիսկ է։ Իսկ պատասխանի զտումը ստեղծում է երկրորդ խնդիրը. ֆինանսական բաժնին պետք է պատվերների այլ տեսք, աջակցությանը՝ ներքին նշումների մի մասը, մեկ այլ թիմ միանում է պաշարների համակարգին, և կուտակվում են տասնյակ համընկնող գործիքներ։

Դաշտերի մակարդակի պայմանագիր

Լուծումը, ըստ հեղինակի, դաշտերի մակարդակի պայմանագիրն է, որը ստույգ սահմանում է, թե ինչ կարող է տեսնել և ինչ անել յուրաքանչյուր գործակալ։ MCP-ն սահմանում է գործիքների հայտնաբերումն ու կանչը, իսկ պայմանագիրը՝ հասանելիության սահմանները. երկու շերտերն էլ անհրաժեշտ են։

Որպես գործնական ուղի հեղինակը առաջարկում է GraphQL. հարցումը ներառում է միայն անհրաժեշտ դաշտերը, օրինակ՝ status և shipBy, և պատասխանում վերադարձվում են միայն դրանք։ Եթե գործակալը պահանջում է զգայուն դաշտ, ինչպիսին internalFraudScore-ն է կամ customerSSN-ը, սերվերը կարող է մերժել հարցումը կամ այդ դաշտերը անհասանելի դարձնել։ Կանոնը պատկանում է հենց դաշտին։

Գրառումը նույնպես այսպես է աշխատում. միայն կարդալու իրավունքը չի թույլատրի աշխատանքը, իսկ անսահմանափակ հասանելիությունը գործակալին հնարավորություն կտա փոխել պաշարը, չեղարկել պատվերը կամ վերադարձնել գումարը։ Առանձին բիզնես գործողությունը, օրինակ requestInventoryTransfer-ը, հայտնվում է որպես առանձին օպերացիա. իրավունքը ստուգվում է գործարկման ժամանակ, իսկ պաշարի առկայությունը և անհրաժեշտ համաձայնությունները ստուգում է բազային ծառայությունը։ Բիզնես API-ները փոխել պետք չէ. շերտը տեղադրվում է առկա REST, gRPC կամ SOAP ծառայությունների վրա։

Ինչ է սա նշանակում գործնականում

Առաջարկը չեզոք չէ. հեղինակը ղեկավարում է GraphQL արտադրող ընկերություն։ Փաստարկն ինքնին գործում է անկախ կոնկրետ գործիքից. գործակալի հասանելիությունը API-ի և գործիքի միջև պետք է առանձին, հստակ սահմանված սահման ունենա՝ յուրաքանչյուր դաշտի և յուրաքանչյուր գործողության մակարդակով։ Ըստ հեղինակի՝ նման պայմանագիրն ավելի քան տասը տարի է աշխատում իրական համակարգերում և սպասարկում է միլիարդավոր գործարքներ այնպիսի ընկերություններում, ինչպիսիք են Shopify, Netflix, Airbnb, Expedia Group և Walmart։