MCP nədir və o sizin ChatGPT App‑iniz üçün niyə lazımdır

1. Niyə ümumiyyətlə ayrıca protokola ehtiyac var

Bu modulda nəhayət MCP‑nin (Model Context Protocol) nə olduğunu və onun ChatGPT App yığınında necə yerləşdiyini başa düşəcəyik. Gəlin əvvəlcə MCP‑nin arxitekturada yerini dəqiqləşdirək, onu “tipik REST” ilə müqayisə edək və protokolun əsas entitilərini: tools, resources və prompts nəzərdən keçirək.

Təsəvvür edin ki, adi bir veb‑xidmət yazırsınız. Köhnə, yaxşı ənənə ilə siz REST API qaldırırsınız: sizdə /api/gifts, /api/users, /api/orders var, hər birinin öz giriş‑çıxış formatı, öz xəta kodları və avtorizasiyası var. Bu tanışdır, amma bir nüans var: hər bir müştəriyə nəyi və necə reallaşdırdığınızı izah etməyə məcbursunuz. Sənədləşmə, OpenAPI, nümunələr, SDK — bunların hamısı lazımdır, çünki API formatını siz özünüz uydurmusunuz.

ChatGPT App ilə vəziyyət mürəkkəbləşir. Müştəri sizdə yalnız frontend deyil, həm də modelin özüdür. Ona lazımdır:

• ümumiyyətlə hansı əməliyyatların əlçatan olduğunu bilmək;
• hər əməliyyat üçün hansı arqumentlərin lazım olduğunu anlamaq;
• dialoq gedişində bu əməliyyatları çağırmaq, bəzən bir neçə dəfə, bəzən müxtəlif parametrlərlə;
• strukturlaşdırılmış cavabı şərh etmək və istifadəçiyə nəyi göstərmək, nəyi isə növbəti replikaya kontekst kimi istifadə etmək barədə qərar vermək.

Əgər hər bir developer öz API formatını uydursa, model inteqrasiya cəhənnəminə düşəcək: hər App üçün xüsusi müştəri, tonlarla “obvazka” və kövrək məntiq lazım olacaq. Problemi protokol ideyası həll edir.

MCP (Model Context Protocol) — bu, LLM‑klientin (ChatGPT, IDE plugin, agent və s.) sizin alət və məlumat serverinizlə necə danışdığını müəyyən edən açıq spesifikasiyadır. O, serverin alətlərini, resurslarını və promptlarını elan etdiyi, müştərinin isə onları çağırdığı və nəticələri aldığı ümumi bir dili müəyyənləşdirir.

İntuisiya səviyyəsində MCP AI dünyası üçün USB‑C port kimidir: əgər siz “USB yaddaş” (xidmət, verilənlər bazası, CRM, axtarış mühərriki) hazırlayırsınızsa, bir standart qoşulma reallaşdırmalısınız. Onda istənilən “noutbuk” (ChatGPT, başqa agent, IDE) sizə xüsusi kabelsiz qoşula bilər.

2. Yuxarıdan baxış: MCP ChatGPT App arxitekturasında haradadır

Şəkli dəqiqləşdirmək üçün artıq tanış arxitekturanı xatırlayaq, amma indi açıq MCP qatını da əlavə edək.

Hazırkı mental təsvir sizə tanışdır: istifadəçi ChatGPT ilə danışır, dialoq daxilində vidcet (Apps SDK) render olunur, haradasa kənarda isə sizin backend yaşayır. İndi MCP əlavə edək və hər şeyi qatlara ayıraq.

Sadələşdirilmiş sxem budur:

İstifadəçi
   ↓ (təbii dil)
ChatGPT (model + UI)
   ↓ (MCP üzərindən tool çağırışları)
ChatGPT daxilində MCP‑klient
   ↓ (JSON-RPC, MCP)
Sizin MCP‑serveriniz (backend)
   ↓
Sizin MB / xarici API‑lər / növbələr

Burada “ChatGPT daxilindəki MCP‑klient” dedikdə, protokol üzrə sizin MCP‑serverinizlə danışan platformanın daxili hissəsi nəzərdə tutulur: discovery edir, alətləri çağırır və resursları oxuyur.

Apps SDK baxımından minimal ChatGPT App üç komponentdən ibarətdir. Birincisi — alətləri elan edən və strukturlaşdırılmış məlumat verən MCP‑server. İkincisi — ChatGPT daxilində render olunan və bu məlumatları window.openai vasitəsilə oxuyan UI bundl (vidcet). Üçüncüsü — istifadəçiyə nə vaxt hansı aləti çağırmalı və necə cavab verməli olduğunu qərar verən modelin özü.

Burada vacib olan budur. Əvvəlki modullarda siz çoxunu Apps SDK və vidcet səviyyəsində — yəni sxemin yuxarı hissəsində — etmisiniz. İndi isə biz MCP‑server səviyyəsinə enirik — bu, ChatGPT və sizin App‑ı istifadə etmək istəyəcək digər müştərilərlə “rəsmi ünsiyyət dilinizdir”.

3. MCP və “tipik REST”: fərq nədədir

Yuxarıdakı sxemdə MCP‑nin ChatGPT App arxitekturasında harada yerləşdiyini qeyd etdik. İndi isə “öz REST” yanaşması ilə MCP‑ni diqqətlə müqayisə edək ki, niyə ChatGPT Apps kontekstində ikinci variant demək olar ki, həmişə üstün gəlir, aydın olsun.

REST yanaşmasında siz endpointləri, sorğu və cavab formatlarını sizə uyğun olan kimi layihələndirirsiniz. Müştərinin sizinlə işləməsi üçün URL‑ləri, metodları, sxemləri və xəta kodlarını bilməsi lazımdır. Bəzən OpenAPI kömək edir, bəzən sadəcə README‑yə sorğu nümunəsi atırsınız. Model öz‑özlüyündə bunların heç birini anlamır: ona “50 yaşlı ana üçün hədiyyə seç” kimi təbii istəyi konkret HTTP sorğusuna çevirəcək, sonra isə JSON cavabı dialoq üçün yararlı məlumatlara geri çevirəcək kod qatı lazımdır.

MCP‑də isə hər şey fərqlidir. Protokol özü müəyyənləşdirir:

• müştəri sizin alətlər siyahınızı necə öyrənə bilər;
• arqumentləri və nəticələri JSON Schema ilə necə təsvir etmək olar;
• resursları və promptları necə təsvir etmək olar;
• alət çağırışı və ona cavab necə görünür.

Bunun sayəsində ChatGPT və digər MCP‑klientlər avtomatik olaraq:

• discovery icra edə bilir — sizdə hansı tools/resources/prompts olduğunu öyrənir;
• hər alət üçün daxili parametr sxeması qurur;
• onları xüsusi hard‑code müştəri məntiqi olmadan çağırır;
• metadataları keşləyir və onları tətbiqlərin axtarışı və reytinqində istifadə edir.

Fərqi kiçik bir cədvələ də toplamaq olar.

Emosional desək: REST — “hər kəs özü üçün”, MCP — “ekosistemanın bütün iştirakçıları arasında model və məlumatlarla necə danışmağın razılaşdırılmasıdır”.

4. MCP‑nin əsas entitiləri: tools, resources, prompts

İndi isə MCP‑nin üç əsas qəhrəmanını adları ilə çağıraq: alətlər (tools), resurslar və promptlar.

Tools: artıq alışdığınız əməliyyatlar

Tools ilə siz artıq Modul 4‑də qarşılaşmışdınız: orada aləti təsvir edir, ona ad, təsvir və JSON Schema arqumentləri verirdik, sonra isə model onu callTool vasitəsilə çağırırdı. MCP səviyyəsində alət — dəqiq müqaviləsi olan server əməliyyatıdır:

• ad və təsvir (model və UX/discovery üçün);
• arqumentlər üçün JSON Schema;
• nəticənin strukturu üçün JSON Schema və ya təsvir;
• əlavə meta‑məlumat (məsələn, Apps SDK‑da müəyyən UI komponentinə bağlama).

MCP serveri ən azı “alətlərin siyahısını soruşma”ya cavab verməyi və “alət çağırışı”nı işləyib strukturlaşdırılmış nəticə qaytarmağı bacarmalıdır.

Tədris tətbiqimiz olan Gift köməkçisində, məsələn, suggest_gifts adlı alət var, hansı ki, yaş, cins, büdcə və bir neçə üstünlüyü qəbul edir və tövsiyə olunan hədiyyələr siyahısını qaytarır.

Şərti TypeScript sketşi MCP serverinin kodunda, məsələn, belə görünə bilər (psevdo‑kod/plug‑in):

// Psevdo-kod, yekun SDK API deyil
const suggestGiftsTool = defineTool({
  name: "suggest_gifts",
  description: "Alıcı parametrlərinə görə hədiyyə ideyalarını seçir",
  inputSchema: z.object({
    age: z.number(),
    relation: z.enum(["friend", "partner", "parent"]),
    budgetUsd: z.number(),
  }),
  handler: async (input) => {
    // TODO: sizin biznes məntiqiniz
    return { items: [] };
  },
});

Real imzaları növbəti mühazirələrdə müzakirə edəcəyik, burada ideya vacibdir: alət sadəcə REST endpointi deyil, elan olunmuş sxemi olan protokol elementidir.

Resurslar (resources): ID/URI ilə müraciət oluna bilən məlumatlar

MCP‑də resurslar (resources) əlçatan məlumatları təsvir etməyin üsuludur: fayllar, kataloqlar, MB qeydləri, viki səhifələri, hətta axtarış indekslərinin nəticələri. Müştəri:

• resursların siyahısını ala bilər;
• konkret resursu ID/URI ilə oxuya bilər;
• bəzən — onlar üzrə axtarış da edə bilər.

Bir şey “edən” tools‑lardan fərqli olaraq, resources adətən “bir şeyi saxlayır”. Məsələn, Gift‑App‑də məhsullar kataloqunu modelin mövcud kateqoriyaları, filtrləri, qiymət diapazonlarını və s. öyrənmək üçün müraciət etdiyi gift_catalog resursu kimi təqdim edə bilərsiniz.

Kodda bu konseptual olaraq belə görünə bilər:

const giftCatalogResource = defineResource({
  uri: "catalog://gifts",
  description: "Tövsiyə üçün əlçatan hədiyyələr kataloqu",
  read: async () => {
    // Kataloqun strukturunu qaytarırıq
    return { categories: [], priceRanges: [] };
  },
});

Hələlik MCP mesaj formatına girmirik, amma yadımızda saxlayaq: resurslar ünvanlana bilən entitilərdir, MCP serveri onlara istinad edə bilər, müştəri isə onları oxuyub kontekstin bir hissəsi kimi istifadə edə bilər.

Prompts: əvvəlcədən hazırlanmış təlimatlar

MCP kontekstində Prompts — serverin müştəriyə təqdim edə biləcəyi sorğu və ya təlimat şablonlarıdır. Məsələn, siz gift_followup adlı prompt elan edə bilərsiniz; o, aləti çağırmazdan əvvəl modelin istifadəçidən hədiyyə alıcısı barədə detalları necə dəqiqləşdirməli olduğunu təsvir edir.

Protokol ruhunda tipik nümunə: server promptun adını, təyinatını, bəzən də parametrlərini verir. Müştəri promptların siyahısını soruşur, lazımini seçir və onu modelə sorğuda yerinə qoyur.

Bu ChatGPT App üçün niyə lazımdır? Birincisi, mürəkkəb təlimatları müştərilər arasında yenidən istifadə etməyin vahid yoludur. İkincisi, MCP belə promptları təsadüfi kod parçalarında gizlətmək deyil, açıq və “müqaviləli” edir.

Capabilities: ümumiyyətlə nələri dəstəklədiyinizi elan etmə

Nəhayət, dördüncü element var — capabilities. Bu sadəcə bəyanatdır: server hansı entitiləri (tools, resources, prompts, bildirişlər və s.) dəstəklədiyini və hansı metodları reallaşdırdığını deyir. Müştəri üçün bu, nə etmək olar, nə olmaz — təxmin etməmək, serverin imkanlarına uyğun davranışını səliqəli şəkildə adaptasiya etmək deməkdir.

Praktikada ChatGPT sizin MCP‑serverinizə qoşularkən əvvəlcə “əl sıxma” (handshake) həyata keçirir, capabilities siyahısını alır, sonra isə “Yaxşı, alətlərini və resurslarını göstər” deyir.

5. MCP cari App‑inizə necə inteqrasiya olunur

Bunlar bir az abstrakt səslənə bilər, amma əslində siz artıq Apps SDK vasitəsilə MCP ilə rastlaşmısınız. Düşünürəm, başlamağa dəyər ki, sizin Apps SDK çərçivəsində yazdıqlarınızla bu necə birləşir? Gəlin yenicə təqdim etdiyimiz entitiləri hazırkı App şablonunuzun quruluşuna bağlayaq.

Şablonda artıq reallaşdırdığınız zənciri xatırlayaq:

1. Vidcet window.openai və ya hazır hook‑lar vasitəsilə alətin adını və arqumentləri verərək callTool çağırır.
2. Apps SDK ChatGPT daxilində bunu App‑ın server tərəfinə müraciətə çevirir.
3. Server aləti icra edir və ToolOutput qaytarır, o da structuredContent, content və _meta daxil edir.
4. Vidcet ToolOutput‑u alır və UI çəkir.

Sır burada odur ki, 2–3‑cü addımlar MCP üzrə dialoq kimi reallaşdırılıb. Sizin Next.js şablonunuzda bir endpoint (adətən app/mcp/route.ts və ya oxşarı) var, hansı ki, məhz MCP‑serveridir. O:

• alətlərinizi qeydiyyatdan keçirir;
• onları JSON Schema ilə təsvir edir;
• handlerləri reallaşdırır;
• ChatGPT‑yə MCP sorğularına list tools və call tool cavab verir.

Yəni faktiki olaraq indi də, şablondan istifadə edərkən, siz MCP ilə “avtomatik” işləyirsiniz: protokol sehri əsasən SDK‑da gizlənib.

6‑cı modulun məqsədi MCP‑ni “sehrli qara qutu” kimi deyil, şüurlu şəkildə layihələndirməyə başlamaqdır:

• alətləri əlavə etmək və versiyalaşdırmaq;
• yalnız tools deyil, həm də resources və prompts istifadə etmək;
• MCP loglarını oxumaq və başa düşmək;
• lazım olduqda Next.js şablonundan kənarda ayrıca MCP serverləri qaldırmaq (məsələn, ML modeli üçün Python xidməti və ya korporativ bazaya çıxış üçün ayrıca xidmət).

6. Müxtəlif rolların baxış bucağından MCP: product meneceri və developer

MCP‑nin product meneceri və mühəndis üçün nə verdiyini ayrıca formalaşdırmaq faydalıdır.

Product meneceri üçün MCP

Məhsul baxımından MCP — xidmətinizi bütöv bir müştəri “zooloqu” üçün “qoşula bilən modul” etməyin yoludur: ChatGPT, digər LLM müştəriləri, IDE plaginləri, öz agentləriniz. Serverin imkanlarını tools/resources/prompts dəsti kimi bir dəfə təsvir etməklə, istənilən müştəriyə imkan verirsiniz:

• xidmətinizi avtomatik kəşf etsin;
• onun hansı problemləri həll etdiyini anlasın;
• lazımi əməliyyatları təhlükəsiz şəkildə çağırsın.

ChatGPT App halında bu həm də tətbiqinizin seçilmə ehtimalını artırır: model istifadəçiyə App‑ınızı nə vaxt təklif etməli və onu necə düzgün təqdim etməli olduğunu müəyyənləşdirmək üçün alətlərinizə dair metadatalardan istifadə edir.

Çox qısa desək: MCP xidmətinizi bir‑iki müştəri üçün xüsusi inteqrasiya deyil, ekosistemanın standart “kərpici” edir.

İnkişaf etdirici üçün MCP

Mühəndis baxımından MCP — müqavilə və protokoldur. O, suallara cavab verir:

• Aləti hansı formatda elan etməliyəm?
• Arqumentləri necə təsvir etməli və nəticəni necə qaytarmalıyam?
• Müştəri mənim resursları və promptları dəstəklədiyimi necə anlayacaq?
• Şəbəkə üzərindən ümumiyyətlə hansı JSON gedəcək?

Belə bir protokol olduqda, aşağıdakıları asanlaşdırır:

• fərqli dillərdə serverlər yazmaq (TypeScript və Python üçün rəsmi SDK‑lar var);
• tətbiqi MCP Inspector və oxşar alətlərlə sazlamaq;
• məsuliyyəti komandalar arasında bölmək: bir komanda məlumatlar və alətlərlə MCP serveri hazırlayır, başqa komanda Apps SDK üzərində vidcet qurur, üçüncüsü isə eyni MCP server üzərində öz agentlərini qura bilər.

7. Kiçik praktik perspektiv: bizim ilk MCP serverimiz

Bu mühazirədə biz qəsdən mesaj formatının detalları və serverin reallaşdırmasına girmirik — bu, növbəti mövzuların materialıdır. Amma hara getdiyimizi qabaqcadan anlamaq üçün TypeScript‑də minimal MCP serverinin ümumi quruluşunu görmək faydalıdır.

Reallıqda MCP‑nin rəsmi TypeScript kitabxanası server yaratmaq, tools/resources/prompts qeydiyyatdan keçirmək və nəqliyyatı (adətən HTTP və ya SSE) işə salmaq üçün primitivlər təqdim edir.

Şərti psevdo‑nümunə belə görünə bilər:

// Bu konseptual nümunədir, SDK API-ni sonra nəzərdən keçirəcəyik
import { createServer } from "@modelcontextprotocol/sdk";

const server = createServer({
  name: "gift-genius",
  version: "1.0.0",
});

// Aləti qeydiyyatdan keçiririk
server.tool("suggest_gifts", {
  description: "Alıcının üstünlüklərinə görə hədiyyələr seçir",
  inputSchema: {/* ... */},
  handler: async (input) => {
    // sizin məntiqiniz
    return { items: [] };
  },
});

// Nəqliyyatı işə salırıq (məsələn, HTTP)
server.listen(3001);

Vacib məqam: burada heç yerdə ChatGPT, Apps SDK və ya sizin konkret frontend xatırlanmır. MCP serveri özlüyündə kifayətdir. O, sadəcə MCP sorğularına cavab verməyi bacarır. ChatGPT App — belə serverdən istifadə edə bilən müştəri tiplərindən sadəcə biridir.

Kurs çərçivəsində biz Next.js şablonuna sadiq qalacağıq, burada MCP serveri layihənin bir hissəsi kimi yaşayır, amma bu, yeganə mümkün variant deyil.

8. Ekosistemdə MCP: Apps SDK, Agents SDK və ACP

MCP‑ni “yalnız Apps SDK üçün funksiya” kimi qavramamaq üçün onu daha geniş mənzərədə görmək faydalıdır.

Birincisi, Apps SDK birbaşa MCP‑yə, ChatGPT ilə xarici xidmətlər arasında standart körpü kimi söykənir. Rəsmi sənədlər vurğulayır: Apps SDK istənilən MCP serverləri ilə işləyir. Protokolun özü alətləri təsvir etməyə, strukturlaşdırılmış məlumatlar qaytarmağa və UI‑də render üçün komponent göstərməyə imkan verir.

İkincisi, ayrıca modulda müzakirə edəcəyiniz Agents SDK da MCP serverlərinə qoşula bilir. Bu o deməkdir ki, eyni MCP biznes‑məntiq serverindən istifadə etmək olar:

• ChatGPT daxilində App‑ınızın bir hissəsi kimi;
• məsələn, məhsulunuzun fonunda və ya batch rejimində işləyən müstəqil agentin daxilində.

Üçüncüsü, alış‑veriş və Instant Checkout üçün lazım olacaq ACP (Agentic Commerce Protocol) məntiqi olaraq MCP yanaşmasının üzərində qurulur: model və agentlər commerce alətlərini çağırır, hansı ki, onlar da standartlaşdırılmış müqavilələrlə təsvir olunur.

Beləliklə, MCP UI (Apps SDK), agent ssenariləri (Agents SDK) və kommersiya (ACP) üzərində qurulan fundamentə çevrilir. Əgər siz MCP‑ni inamla anlayırsınızsa, qalan hər şey daha aydın və proqnozlaşdırıla bilən olur.

Qeyd: Formal olaraq ACP spesifikasiya kimi asılı deyil MCP‑dən, amma real reallaşdırmada ACP alətləri çox güman ki, model tərəfindən məhz MCP interfeysləri vasitəsilə çağırılacaq. Bu iki yanaşma bir‑birinə çox gözəl oturur, ona görə də çox gözləmək qalmayıb.

9. Təcrübədən əvvəl kiçik “beyin məşqləri”

Növbəti mühazirədə MCP mesaj formatına baş vurmamışdan əvvəl bir neçə düşüncə təcrübəsi etmək faydalıdır. Bu, düşüncəni “tipik REST”dən “protokol + müqavilə”yə “keçirməyə” kömək edəcək.

Təsəvvür edin ki, sizin Gift‑App‑ınıza təkcə ChatGPT deyil, həm də VS Code üçün IDE plagin və Slack‑də daxili korporativ assistent qoşulmaq istəyir. Onların hər birinin sizin xidmətiniz haqqında bilməli olduqlarını bir cümlə ilə təsvir edin. Çox güman, cavab belə olacaq: “Bizdə bu cür parametrləri olan suggest_gifts aləti və belə resurs vasitəsilə əlçatan hədiyyə kataloqu var”. MCP məhz bunu formallaşdırır.

Həmçinin iki cümlə ilə formalaşdırmağa çalışın:

• sizin App‑ın productu üçün MCP nədir (ipucu: müxtəlif müştərilər üçün funksionallığı “qablaşdırmağın” standart yolu);
• developer üçün MCP nədir (ipucu: aydın tools/resources/prompts primitivləri olan JSON‑RPC protokolu).

Bunu kəkələmədən edə bilirsinizsə — siz artıq MCP ilə inamlı işləməyə gedən yolun yarısını keçmisiniz.

Yuxarıdakıların hamısını bir tezisdə toplasaq: MCP — bu, daha bir üst API qat deyil, sizin məntiqinizlə LLM müştəriləri arasında baza müqaviləsidir. Növbəti mühazirələrdə biz protokolun özünə baxacağıq: MCP mesaj formatını, handshake/capabilities və trafiki inspektorlar vasitəsilə izləməyi öyrənəcəyik ki, bütün bu prinsiplər abstraksiya deyil, iş aləti olsun.

10. MCP ətrafında tipik səhvlər və yanlış təsəvvürlər

Səhv №1: MCP‑ni “mənim REST‑imin üzərində daha bir API qatı” hesab etmək.
Bəzən belə bir həvəs yaranır: “Məndə artıq REST var, gəlin nazik bir adapter əlavə edib MCP çağırışlarını REST‑ə və geriyə çevirim və unudum”. Formal olaraq bunu etmək olar, amma onda siz çox vaxt köhnə API‑nin özəlliklərini MCP‑yə “dartıb gətirməyə” başlayırsınız: qəribə tiplər, strukturlaşdırılmamış cavablar, aydın sxemlərin olmaması. Zamanla adapter böyüyür, MCP‑dən qazanc isə azalır. MCP‑ni əsas müqavilə kimi qəbul etmək, köhnə REST‑i isə hələ lazımdırsa, daxili reallaşdırma detalı kimi saxlamaq daha yaxşıdır.

Səhv №2: MCP‑nin “yalnız ChatGPT Apps üçün” olduğunu düşünmək.
MCP — istənilən LLM müştəriləri üçün ümumi açıq protokoldur: ChatGPT, IDE plaginləri, müstəqil agentlər. Əgər siz MCP serverini yalnız bir App üçün nəzərdə tutaraq layihələndirirsinizsə, gələcəkdə özünüzü məhdudlaşdırırsınız. Daha sərfəlisi dərhal belə düşünməkdir: “bu serverdən başqa müştərilər də istifadə edəcək”, və alətləri və resursları bir qədər daha universal layihələndirmək.

Səhv №3: JSON Schema‑nı görməzlikdən gəlmək və arqumentləri “sözlərlə” təsvir etmək.
SDK haradasa “istənilən JSON” ötürməyə imkan versə belə, arqument və nəticə sxemlərini təsvir etməyə tənbəllik etməyin. Bundan modelin alətinizi düzgün çağırmaq qabiliyyəti, avtomatik tamamlanma və discovery keyfiyyəti, həmçinin inspektorlar vasitəsilə sazlama rahatlığı birbaşa asılıdır. Təsvir olunmayan və ya pis təsvir olunan arqumentlər — anlaşılmaz tool‑call xətalarına düz yol verir.

Səhv №4: MCP‑ni “sehrli nəqliyyat” kimi qəbul etmək və loglara baxmamaq.
Hər şey işləyənə qədər elə gəlir ki, MCP — görünməz bir şeydir və haqda düşünmək lazım deyil. Problem ondadır ki, nəsə sınan kimi, MCP strukturunu anlamadan uzun müddət “bu Apps SDK‑dır? modeldir? mənim backendimdir?” deyə təxmin edəcəksiniz. Erkən mərhələdə MCP mesajlarına və loglara baxmaq vərdişi sizi saatlarla mənasız vaxt itkisindən qoruyar.

Səhv №5: yalnız REST ilə mürəkkəb workflow layihələndirməyə çalışmaq, MCP primitivlərini görməməzlikdən gəlmək.
Çoxmərhələli ssenariləriniz (hədiyyə axtarışı → üstünlükləri dəqiqləşdirmə → seçim → sifarişin rəsmiləşdirilməsi) peyda olanda, sadəcə “bir böyük REST endpoint” etmək istəyirsiniz. ChatGPT Apps kontekstində bu çox vaxt idarəolunurluğu pisləşdirir: model aralıq addımları daha pis anlayır, MCP müştərisi isə resursları və promptları yenidən istifadə etmək imkanını itirir. Funksionallığı bir neçə yaxşı təsvir edilmiş tools/resources‑a bölmək və məntiqi sistem promptları və düzgün təsvirlərlə bağlamaq çox daha yaxşıdır.