Alətlər siyahısının dinamik idarə olunması (tool gating)

1. Tool gating nədir və niyə ayrıca mühazirə mövzusudur

İndiyə qədər sadələşdirilmiş nümunələrdə belə edirdik: App üçün alətlər dəstini təsvir edirik, MCP‑serveri qoşuruq — və bütün bunlar model üçün həmişə əlçatandır. “5 dəqiqəyə demo qurmaq” baxımından bu işləyir. Real məhsul baxımından — o qədər də yox.

Tool gating — bu elə bir pattern-dir ki, model üçün əlçatan olan alətlərin siyahısı sabit deyil, əksinə kontekstdən asılıdır: iş axınının addımından, istifadəçi hüquqlarından, verilənlərin vəziyyətindən və s.

Ən vacibi: tools siyahısı “nə vaxtsa yazdığınız hər şeyin təsadüfi yığnağı” deyil, ssenari dizaynının bir hissəsidir. Workflow-u layihələndirərkən, əslində modelin hər mərhələdə hansı alətləri görmək hüququ olduğunu da layihələndirirsiniz.

Sadə bənzətmə: bankda təcrübəçiyə dərhal bütün sistemlərə giriş vermirsiniz — əvvəlcə yalnız baxış, sonra sadə əməliyyatlar, sonra daha ciddiləri. Burada da eyni məntiq var, sadəcə təcrübəçi — LLM-dir.

2. “Bütün alətlər bir anda” problemi: kontekstin çirklənməsi və təhlükəsizlik

Modelə onlarla alət versəniz, o, eyni vaxtda bir neçə istiqamətdə əziyyət çəkir: kontekstin yüklənməsi, seçimdə çaşqınlıq və təhlükəsizlik məsələləri. OpenAI/Anthropic tədqiqatları göstərir ki, nə qədər çox funksiyanı kontekstdə təsvir etsəniz, bir o qədər pis model lazım olanı seçir.

Birincisi, hər bir alət tərifi — tokenlərdir: ad, təsvir, JSON Schema. 30–40 tools siyahısı asanlıqla bir neçə min token yeyir. Bu, dialoq tarixçəsinə, istifadəçi kontekstinə, yaxşı cavab nümunələrinə xərcləyə biləcəyiniz tokenlərdir. Onun əvəzinə model API-ləriniz haqqında “roman” oxuyur.

İkincisi, alətlər bir-birinə bənzəyəndə, model çaşır. Məsələn, sizdə search_products və get_product_details varsa, təsvir ona daha uyğun göründüyü üçün model mətn sorğusu ilə birbaşa get_product_details-i çağırmağa cəhd edə bilər.

Üstəlik, ayrıca təhlükəsizlik məsələsi qalxır. “Minimal səlahiyyət (least privilege)” adlı darıxdırıcı, amma vacib prinsip var: sistem yalnız “indi və burada” həqiqətən lazım olan imkanlara malik olmalıdır. Tanışlıq mərhələsində model artıq checkout-dan xəbərdardırsa, istifadəçinin kiçik bir prompt inyeksiyası belə onun vaxtından əvvəl ödəniş çağırmasına səbəb ola bilər. Tool gating — hüquqların minimallaşdırılmasının rahat xüsusi halıdır: hər addımda yalnız lazımi olanları aktivləşdiririk.

Və nəhayət, UX. Əgər model istifadəçinin gözləmədiyi “sehrli” bir şey edirsə (məsələn, hələ hədiyyə seçərkən sifariş yaradırsa), sizin App-a etibar sürətlə düşür.

3. Tool gating üçün nümunə kimi GiftGenius

Gəlin bizim GiftGenius keisini götürək və addımlara səmimi baxaq:

1. Müsahibə: alıcının yaşı, cinsi, maraqları, büdcəsi və s. barədə məlumat toplayırıq.
2. Seçim: kataloq üzrə malları axtarırıq, ideyalar göstəririk.
3. Checkout: istifadəçi artıq hədiyyəni seçəndə rəsmiləşdirməyə keçirik.

Əgər müsahibə addımında model artıq search_products, add_to_cart və checkout-dan xəbərdardırsa, o, aşağıdakıları edə bilər:

• normal üstünlükləri toplamazdan əvvəl axtarışı çox tez çağırmağa başlamaq;
• istifadəçi “Aaa, bu yaxşıdır, götürürəm” deyə kənar söz işlətdiyi üçün dərhal “sifarişi rəsmiləşdirməyə” cəhd etmək.

Düzgün variant — addımlardan keçdikcə əlçatan tools siyahısını dəyişmək. Aşağıda məhz belə bir ssenarini müzakirə edəcəyik: müsahibə addımında yalnız üstünlükləri saxlamaq alətləri görünür, seçim addımında — axtarış və səbətə əlavə etmə, checkout addımında — birbaşa checkout.

Bunu kiçik bir cədvəldə cəmləyək:

INTERVIEW

save_preference, finish_interview

search_products, add_to_cart, checkout

BROWSING

search_products, get_product_details, add_to_cart

save_preference

checkout

CHECKOUT

search_products, get_product_details, add_to_cart, checkout

Diqqət edin: checkout aləti yalnız rəsmiləşdiriləsi nəsə olduqda və yalnız müvafiq addımda görünür. Bu, commerce-ssenarisi üçün tool gating-in klassik nümunəsidir.

4. Tool gating strategiyaları: vəziyyətə, rollara, resurslara görə

Ən geniş yayılmış variant — state‑based gating (workflow addımlarına görə geiting): alətlərin siyahısı ssenarinin vəziyyətindən asılıdır. Yəni haradasa step adlı dəyişən saxlayırsınız və məhz o müəyyən edir ki, hansı alətlər aktivdir, hansılar deyil.

Amma alətlərə təsir edən təkcə addımlar deyil.

Bəzən siz role‑based gating (istifadəçi rollarına görə) edirsiniz: administratora servis alətləri (məsələn, kataloqu yenidən indeksləmək) əlçatandır, adi istifadəçiyə — yalnız istifadəçi alətləri. Bəzən — resource‑based gating (resursların vəziyyətinə görə): “qapını aç” aləti yalnız resursun vəziyyətində qapı bağlı kimi işarələnibsə görünür.

Sözgəlişi olmamaq üçün bunu kiçik bir TypeScript funksiyası şəklində təsvir edək. Tutaq ki, bizdə addım, rol, cari səbət və hansısa resursun vəziyyəti olan bir kontekst var:

type WorkflowStep = 'interview' | 'browsing' | 'checkout';
type UserRole = 'user' | 'admin';

interface WorkflowContext {
  step: WorkflowStep;
  role: UserRole;
  cartItems: number; // səbətdə neçə məhsul var
  doorIsClosed: boolean; // resource-based gating nümunəsi: konkret resursun vəziyyəti
}

İndi sistemdə ümumiyyətlə hansı tools var və onları necə filtrləmək olar, təsvir edək:

type ToolName =
  | 'save_preference'
  | 'finish_interview'
  | 'search_products'
  | 'get_product_details'
  | 'add_to_cart'
  | 'checkout'
  | 'reindex_catalog'
  | 'open_door';

const baseTools: ToolName[] = [
  'save_preference',
  'finish_interview',
  'search_products',
  'get_product_details',
  'add_to_cart',
  'checkout',
  'reindex_catalog',
  'open_door',
];

Burada open_door — konkret resursun vəziyyətindən (qapı bağlıdır, ya yox) asılı olan alət nümunəsidir.

Və geiting funksiyasının özü:

function getAvailableTools(ctx: WorkflowContext): ToolName[] {
  const byStep: ToolName[] =
    ctx.step === 'interview'
      ? ['save_preference', 'finish_interview']
      : ctx.step === 'browsing'
      ? ['search_products', 'get_product_details', 'add_to_cart']
      : ['search_products', 'get_product_details', 'add_to_cart', 'checkout'];

  const checkoutAllowed =
    ctx.step === 'checkout' && ctx.cartItems > 0
      ? byStep
      : byStep.filter((t) => t !== 'checkout');

  const withAdmin =
    ctx.role === 'admin'
      ? [...checkoutAllowed, 'reindex_catalog']
      : checkoutAllowed;

  const withResources =
    ctx.doorIsClosed
      ? [...withAdmin, 'open_door']
      : withAdmin.filter((t) => t !== 'open_door');

  return withResources;
}

Burada geitingin üç “qatı” aydın görünür:

• addıma görə (byStep);
• istifadəçi roluna görə (withAdmin);
• resursun vəziyyətinə görə (withResources və doorIsClosed bayrağı).

Bu SDK kodu deyil, sadəcə arxitektura eskizidir. Amma məhz belə düşünürlər: alətlərin tam kataloqu var və kontekstə görə alt çoxluğu qaytaran funksiya var.

5. App arxitekturasında tool gating harada yer alır

Bir az bunu ChatGPT App stəki ilə bildiklərinizlə bağlayaq.

Nəzəri olaraq MCP-protokol belə işləyir

MCP-də alətlər mütləq statik JSON-a sərt tikilməli deyil: server sessiyadan asılı olaraq siyahını dinamik qaytara bilər. Daha da önəmlisi, spesifikasiyada serverin alət siyahısının dəyişə biləcəyini bildirən capabilities mexanizmi və müştərinin (ChatGPT/agent) nəsə dəyişəndə alətlər siyahısını yenidən soruşması üçün tools/list_changed bildirişi var.

Formal olaraq bunu belə edə bilərsiniz və bəzi MCP‑müştərilər dinamik MCP tools list ilə işləyəcək. Amma bu gün üçün ChatGPT App tools/list_changed-i dəstəkləmir. Gələcəkdə dəyişə bilər, amma hələlik bu üsul işləməyəcək.

İşləyən yanaşma budur

Vəziyyəti və əlçatan metodların siyahısını model tərəfində saxlayırsınız. Sadəcə hər addımda modelə “dünyanın mənzərəsi”nin bir hissəsi kimi cari state və əlçatan tools siyahısını göndərə bilərsiniz: sistem promptunda cari addımı (məsələn, step = "browsing"), açar bayraqları (məsələn, cartItems = 2, role = "user") açıq yazıb, yalnız indi icazə verilən alət alt dəstini əlavə etmək kifayətdir.

Model “alətləri unutmağı” bacarmır, amma belə açıq təlimatlara çox yaxşı əməl edir: “Bu addımda yalnız bu funksiyalardan istifadə edə bilərsən…”. Nəticədə model üçün bütün geiting məntiqi sadə bir müqavilə kimi görünür: budur ssenarinin cari vəziyyəti, budur istifadə edə biləcəyin düymələr, qalanı sənin üçün sanki mövcud deyil. Heç bir “sehr” lazım deyil — addımlar arasında keçid edərkən sorğularda state-i və tools siyahısını ardıcıl yeniləmək kifayətdir.

Bundan əlavə, structuredContent-ə belə bir şey kimi təlimatlar əlavə edə bilərsiniz:

{
  "instructions": {
    "current_step": "browsing",
    "enabled_mcp_tools": ["search", "apply"]
  }
}

Eləcə də biznes-kod səviyyəsində müdafiə əlavə edə bilərsiniz. Hətta tools siyahısı artıq “yenilənmiş” olsa da, geiting məntiqini elə alətlərin öz handler-lərində təkrarlamaq vacibdir, çünki:

• uzun müzakirə olduğunda model təlimatları və/və ya məlumatları unuda bilər;
• model əvvəlki addımda əlçatan olmuş “fantom” aləti çağırmağa cəhd edə bilər;

Bu səbəbdən düzgün dizayn belədir: həm alətləri modeldən “gizlədirik”, həm də handler daxilində indi bunu edib-etməməyin mümkünlüyünü yoxlayırıq.

6. Model səviyyəsində vs məntiqi (logical) tool gating

Bunu əvvəlki bölmə ilə əlaqələndirsək: modeli çağırmaq səviyyəsində olan hər şey (prompta hansı bayraqları/step-i qoyursunuz) — model səviyyəsində geitingdir, alətlərin öz handler-lərindəki yoxlamalar isə — məntiqidir.

Adətən bu iki qatı ayırmaq məntiqlidir:

1. Model səviyyəsində geiting — model alətin məhz indi “icazəli” olduğunu bilir, çünki siz təlimatlarda hansı funksiyaların bu addımda əlçatan olduğunu açıq yazırsınız. Model üçün dünya belə görünür: “budur cari state, budur bir sıra düymələr, başqa düymələr yoxdur”.
2. Məntiqi geiting — alətin özünün daxilindəki yoxlamalar. Model keş, fantom yaddaş və ya əvvəlki addımlardan birində həmin aləti ona göstərdiyiniz üçün vaxtından əvvəl checkout çağırmağa cəhd etsə belə, handler cari vəziyyətə baxır və nəzakətlə rədd edir: “əvvəlcə hədiyyəni seç, sonra sifarişi rəsmiləşdirək” ruhunda (sadəcə istisna atmaq yox!).

Niyə hər iki qat lazımdır? Çünki LLM ətrafındakı infrastruktur və ssenarilərin özləri ideal davrana bilməz:

• model vaxtilə checkout alətini gördüyünü “xatırlayıb”, onu mülahizələrində və ya hətta tool-call-da qeyd edə bilər;
• siz özünüz səhvən hansısa addımda lazım olduğundan daha geniş tools dəsti verə bilərsiniz və model artıq funksiyalardan istifadə etməyə başlar;
• müştərilər/aralıq qatlar model çağırışının konfiqurasiyasını keşləyib bir müddət köhnə alətlər dəstini göndərə bilər.

Praktikada bu, sadə bir fikri ifadə edir: yalnız “tools-a aləti qoymadıq — deməli, o, bir daha heç vaxt çağırılmayacaq” düşüncəsinə güvənmək təhlükəlidir. Yoxlamalar yenə də handler-lərdə olmalıdır.

Məntiqi geiting üçün checkout handler-ində psixdo-TypeScript nümunəsi:

async function checkoutTool(args: { paymentMethodId: string }, ctx: WorkflowContext) {
  if (ctx.step !== 'checkout') {
    return {
      error: 'Checkout not available yet. Please finish selecting a gift first.',
    };
  }

  if (ctx.cartItems === 0) {
    return {
      error: 'Your cart is empty. Add at least one gift before checkout.',
    };
  }

  // ... rəsmiləşdirmənin real məntiqi
}

Belə cavab həm istifadəçiyə, həm də modelə kömək edir: model strukturlu səhv görür və fəaliyyət planını düzəldə bilir.

7. Tool gating-i UI və vidcetlə necə bağlamaq

Tool gating — təkcə server mövzusu deyil. UI/UX də dəyişiklikləri hiss etməlidir.

Vidget cari addımı bilir (artıq widgetState-dən və onun məsələn currentStep-i saxlayacağından danışmışdıq). Model də bilir, çünki addım ya alətlərə açıq ötürülür, ya da sistem promptuna yazılıb. UI və aktiv tools dəsti sinxronlaşdırılmalıdır.

Əgər model indi addımın “Seçim” olduğunu düşünürsə, amma vidcet “Müsahibə” interfeysini göstərirsə, istifadəçi çaşır. Əksinə — UI artıq “Ödə” düyməsini çəkir, amma checkout hələ əlçatan deyil, model qəribə vəziyyətdə qalır: düymə var, amma funksiya sanki “işləmir”.

Tool gating-i nəzərə alan addımın həyat dövrü üzrə kiçik bir sxem:

flowchart TD
  A[İstifadəçi vidcetdə müsahibəni doldurur] --> B[Vidget tool save_preference / finish_interview çağırır]
  B --> C[MCP / backend state.step-i yeniləyir]
  C --> D[Server sessiya üçün tools dəstini dəyişir]
  D --> E[ChatGPT müştərisi model üçün əlçatan tools-u yeniləyir]
  E --> F[Model yeni suallar verir
və/və ya yeni alətləri çağırır]
  C --> G[Vidget widgetState vasitəsilə yeni addımı alır
və UI-ni dəyişir]

İstifadəçi üçün bu, adi bir ustad kimi görünür: əvvəlcə bir neçə sual, sonra hədiyyə siyahısı, sonra son təsdiq. Amma pərdəarxasında eyni vaxtda həm UI, həm alətlərin siyahısı, həm də model üçün təlimat dəyişir.

Next.js vidcetində bunu çox sadə ifadə etmək olar. Tutaq ki, siz step-i widgetState-də saxlayırsınız:

type Step = 'interview' | 'browsing' | 'checkout';

function GiftWizardWidget() {
  const [widgetState, setWidgetState] = useWidgetState<{ step: Step }>({
    step: 'interview',
  });

  if (widgetState.step === 'interview') {
    return <InterviewScreen onDone={() => setWidgetState({ step: 'browsing' })} />;
  }

  if (widgetState.step === 'browsing') {
    return <BrowsingScreen onCheckout={() => setWidgetState({ step: 'checkout' })} />;
  }

  return <CheckoutScreen />;
}

Burada alətləri birbaşa göstərmirik, amma step-in vəziyyətdə dəyişməsinin backend-də alətlər dəstinin dəyişməsi ilə uzlaşdığını nəzərdə tuturuq. Addımların vidcetdə necə yaşadığını gördük. İndi isə MCP‑server tərəfinə qayıdaq və eyni step və səbətin vəziyyətinin alətlər siyahısına necə təsir etdiyinə baxaq.

8. Nümunə: MCP‑serverdə dinamik tools/list

Artıq görmüsünüz ki, MCP‑server sessiya vəziyyətini saxlayıb ondan qərar vermək üçün istifadə edə bilər. GiftGenius keisinin ayrıca təhlilində step və səbətin (cart) vəziyyətinin yaddaşda və ya Redis-də saxlandığı və onlardan alətlər siyahısını formalaşdırmaq üçün istifadə edildiyi nümunə göstərilir. Server alətlər siyahısını sorğuya cavab olaraq onlara əsasən verir.

Yəqin bu mühazirəni oxuyanda, ChatGPT App artıq cari sessiya çərçivəsində toolChanged-i dəstəkləyir. Bu, olduqca məntiqlidir, buna görə də zaman məsələsidir deyə düşünürəm. Bu halda, MCP protokolunun məhz “nativ” mexanizmləri ilə tool gating-i necə etmək barədə qısa izahım var.

Fikri TypeScript ilə (abstrakt MCP‑server) təzədən yazaq:

interface SessionState {
  step: WorkflowStep;
  cartItems: number;
  doorIsClosed: boolean; // resurs vəziyyəti nümunəsi
}

const allTools: ToolDefinition[] = [/* alətlərin tam siyahısı */];

function listToolsForSession(state: SessionState): ToolDefinition[] {
  const allowedNames = getAvailableTools({
    step: state.step,
    cartItems: state.cartItems,
    role: 'user',
    doorIsClosed: state.doorIsClosed,
  });

  return allTools.filter((tool) => allowedNames.includes(tool.name as ToolName));
}

Və haradasa finish_interview handler-ində addımı dəyişib, müştəriyə alətlər siyahısının yeniləndiyini siqnal verirsiniz:

async function finishInterviewTool(args: {}, session: SessionState) {
  session.step = 'browsing';
  await notifyToolsListChanged(); // şərti MCP bildirişi çağırışı

  return { success: true };
}

Real MCP-də konkret SDK və mesaj formatlarından istifadə edəcəksiniz, amma məntiq təxminən belə qalacaq: vəziyyəti dəyişdiniz → alətlər dəstini yenilədiniz → müştəriyə xəbər verdiniz.

9. Təhlükəsizlik aləti kimi tool gating

Texniki detallarda asanlıqla itib-bata bildiyi üçün təhlükəsizlik aspektini ayrıca vurğulayaq.

Tool gating etdikdə, nəticələr avtomatik olaraq azalır:

• “qaydaları ignor et və dərhal ödənişi çağır” tipli prompt inyeksiyaları — çünki müsahibə addımında modelin seçəcəyi checkout ümumiyyətlə yoxdur;
• biznes məntiqindəki bug-lar — çünki hansısa kod budağı vəziyyəti sonadək yoxlamasa belə, alət fiziki olaraq əlçatan olmaya bilər;
• məlumat sızmaları — çünki admin alətləri adi istifadəçi üçün siyahıya düşmür.

Kurs sənədlərində tool gating, xüsusilə checkout və digər həssas addımlar üçün, LLM alətləri kontekstində minimal səlahiyyət prinsipinin tətbiq təcrübələrindən biri kimi birbaşa qeyd olunur.

Yəni bu, yalnız “modeli daha az gicləndirmək” yolu deyil — həm də real müdafiə qatıdır.

10. Necə özünüz məşq edə bilərsiniz

Materialı möhkəmləndirmək üçün istənilən ssenariniz üçün tool gating düşünə bilərsiniz. Məsələn:

• təhsil tətbiqi: məqsədin qoyulması addımı, cari səviyyənin qiymətləndirilməsi addımı, planın qurulması addımı — hər birində öz tools;
• bron etmə: seçimlərin axtarışı, variantın seçimi, təsdiq və ödəniş — yenə də üç fərqli alət dəsti;
• daxili korporativ assistent: sənədlərin axtarışı, giriş tələbi, əməliyyatların icrası — əməkdaş, menecer və admin üçün fərqli siyahı.

Kağızda və ya Miro-da “Addım ↔ hansı alətlər görünür ↔ hansılar gizlənir” cədvəlini çəkmək və hər bir addımın qarşısında məhz niyə bu tools lazım olduğunu və niyə digərlərini gizlətmək gərəkdiyini qısaca formalaşdırmaq çox faydalıdır.

11. Tool gating ilə işləyərkən tipik səhvlər

Səhv №1: Bütün alətləri bir dəfəyə “tökmək” və modelə ümid etmək.
Bəzən developer belə düşünür: “Model axı ağıllıdır, nəyi nə vaxt çağıracağını özü anlayar”. Əslində bu, kontekstin çirklənməsinə, tokenlərin artmasına və daha çox səhv tool-call-lara gətirib çıxarır. Xüsusilə ağrılı olan odur ki, model siyahıda olduğu üçün qəfil checkout və ya başqa təhlükəli aləti çağırır. Tool gating məhz belə situasiyanın yaranmaması üçün lazımdır.

Səhv №2: Aləti siyahıdan gizlətməyin kifayət etdiyini düşünmək.
MCP‑server artıq tools/list-də aləti qaytarmasa belə, model onu tarixçədən “xatırlaya” bilər, infrastruktur isə köhnə alət dəstini keşləyə bilər. Nəticədə fantom alət çağırışı gəlir. Əgər handler məntiqi yoxlamalar etmirsə, “yanlış anda” əməliyyat yerinə yetirilə bilər. Buna görə geiting həm alətlər siyahısı səviyyəsində, həm də handler-lərin daxilində olmalıdır.

Səhv №3: UI ilə alətlər dəstinin asinxronluğu.
Elə hallar olur ki, vidcet artıq "checkout" addımına keçib və “Ödə” düyməsini göstərir, amma MCP tərəfində siz checkout-u əlçatan alətlər siyahısına daxil etməyi unutmusunuz. Model niyə düymə var, alət isə əlçatan deyil — anlamır və qəribə cavablar yaradır. Və ya əksinə: alətlər dəsti artıq dəyişib, model hədiyyələri seçməyə hazırdır, amma vidcet hələ də müsahibə suallarını verir. Workflow-u layihələndirərkən həm UI vəziyyətini, həm də alətlər siyahısını sinxron yeniləmək vacibdir.

Səhv №4: Həddindən artıq mürəkkəb geiting məntiqi.
Bəzən imkanlardan ilhamlanıb, developer onlarla vəziyyət və bütün hallar üçün şərtlərlə demək olar ki, tam BPMN diaqramı qurur. Nəticədə bir həftə sonra özü də anlamır ki, nə üçün hansısa alət yalnız sıçrayış ilində cümə axşamları əlçatandır. Çoxu App üçün sadə addımlar pilləsi və anlaşılan qaydalar kifayətdir: addıma görə, istifadəçi roluna görə və vəziyyətdə bir neçə əsas bayrağa görə.

Səhv №5: Tool gating-i server dəstəyi olmadan yalnız prompta sərt yazmaq.
Bəzən hər şeyi sistem promptunda sözlərlə həll etməyə çalışırlar: “Bu addımda checkout alətini istifadə etmə” — və eyni zamanda alətlərin real siyahısını dəyişmir və backend-ə yoxlamalar əlavə etmirlər. Model bəzən qulaq asacaq, bəzən yox — siz isə qeyri-sabit davranış alacaqsınız. Prompt təlimatları faydalıdır, amma infrastrukturdakı texniki geiting-i tamamlamalıdır, əvəz etməməlidir.

Səhv №6: Rolları və giriş hüquqlarını nəzərə almamaq.
Autentifikasiya olan tətbiqlərdə tez-tez unudurlar ki, tool gating təkcə addımı yox, rolu da nəzərə almalıdır. Nəticədə administrasiya üçün nəzərdə tutulmuş alətlər adi istifadəçi üçün yenə də görünür (və ya daha pis — çağırıla bilir). Avtorizasiya modulunda hüquqların kontekstə necə düşdüyünü artıq görmüsünüz; burada alət dəstini seçərkən bu məlumatdan istifadə etməyi unutmaq olmaz.

Səhv №7: Səhv tool-call-ların monitorinqinin olmaması.
Əgər haradasa geiting ilə səhv etmisinizsə, xarakterik simptom — “Tool not available”, “MethodNotFound” və ya “Checkout is not available yet” kimi öz məntiqi səhvlərinizin artmasıdır. Belə hadisələrin statistikasını toplamasanız, istifadəçilərin mütəmadi olaraq görünməz divarlara dirəndiyini uzun müddət görməyə bilərsiniz. Sadə loqlaşdırma və səhv tiplərinə görə sayğaclar workflow və geiting dizaynındakı problemləri vaxtında görməyə kömək edir.