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.