1. Handshake nə üçün ümumiyyətlə lazımdır
Əgər REST endpoint-ləri URL-lərlə döyülən ayrı qapılar dəstəsidirsə, MCP daha çox bir kanalla davamlı dialoqa bənzəyir. Klient sadəcə pərakəndə sorğular göndərmir, o əvvəlcə sessiya qurur. Handshake — bu sessiyanın əvvəlindəki tanışlıq anıdır.
MCP-də bu an xüsusi initialize sorğusu kimi reallaşdırılıb; klient nəqliyyat (STDIO, HTTP/stream, WebSocket — fərq etmir) qurulan kimi göndərir. Sorğuda o belə bildirir: “Mən MCP-nin filan versiyasında danışıram, bunları bacarıram və ümumiyyətlə kiməm.” Server cavab verir: “Mən isə bu versiyanı və bu imkanları dəstəkləyirəm, tanış olduq.”
Uğurlu mübadilədən sonra klient notifications/initialized bildirişi göndərir və ancaq bundan sonra iş həyatı başlayır: tools/list, resources/list, tools/call və digər faydalı şeylər.
Analogiya aparsaq, MCP handshake — serveri data mərkəzinə gətirməzdən əvvəl icarə müqaviləsi kimidir. Qaydalar barədə (protokol formatı, data mərkəzinin təqdim etdiyi xidmətlər, ödəniş qaydaları) razılaşmadan serverləri daşımaq mənasızdır.
Praktiki baxımdan handshake üç vəzifəni həll edir:
- Protokol versiyalarının uyğunluğunu yoxlayır.
- MCP-nin hansı “primitivlərini” serverin ümumiyyətlə dəstəklədiyini elan edir: tools, resources, prompts, loglama, bildirişlər və s.
- Klient və server haqqında metainformasiya verir — implementasiya adı və versiyası.
2. MCP bağlantısının həyat dövrü: handshake harada yer alır
Mövzunu abstrakt etməmək üçün xeyli sadələşdirilmiş tipik bir qoşulma ssenarisinə (flow) baxaq:
sequenceDiagram
participant C as Klient (ChatGPT/Inspector)
participant S as MCP server
C->>S: (1) Transportu qururuq (STDIO/HTTP-stream)
C->>S: (2) Request: "initialize"
S-->>C: (3) Result: "initialize" (capabilities, serverInfo)
C->>S: (4) Notification: "notifications/initialized"
C->>S: (5) Request: "tools/list" / "resources/list"
S-->>C: (6) Nəticə: alətlərin/resursların siyahıları
C->>S: (7) Request: "tools/call" və s.
Texniki tərəfdən addımlar belə görünür:
- Nəqliyyat qurulur: məsələn, ChatGPT sizin serveri subprocess kimi işə salır və STDIO-ya qoşulur, yaxud Inspector /mcp ünvanına HTTP/stream sorğusu edir.
- Klient JSON-RPC initialize sorğusu göndərir.
- Server protocolVersion, capabilities və serverInfo sahələri ilə JSON-RPC nəticəsi qaytarır.
- Klient notifications/initialized bildirişini göndərir — siqnal: “hər şeyi oxudum, işləmək olar”.
- Klient serverin capabilities sahəsində gördüklərindən asılı olaraq discovery metodlarını çağırır (tools/list, resources/list, prompts/list).
- Server alətlər/resurslar/promptlar üçün metadataları qaytarır.
- Sonra artıq “iş” sorğuları gedir: tools/call, resources/read və başqaları.
Vacib məqam: handshake sadəcə adi initialize adlı JSON-RPC çağırışıdır. Heç bir sehr yoxdur. MCP mesaj formatı barədə mühazirədən sonra siz artıq belə sorğuları parse etməyi bacarırsınız; yeganə fərq — burada metod hər zaman bir dənədir, “xüsusidir” və birinci icra olunur.
3. Klient initialize-də nə göndərir
initialize sorğusunu hissələrə ayıraq. Minimal sorğu təxminən belə görünə bilər (mühazirə üçün sadələşdirilib):
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {
"elicitation": {}
},
"clientInfo": {
"name": "chatgpt-gift-client",
"version": "2.3.0"
}
}
}
Bu nümunə MCP-nin rəsmi sənədlərində göstərilənə yaxındır. params daxilində əsas sahələr:
protocolVersion
MCP spesifikasiyasının versiyası olan sətir; çox vaxt tarix formatında, məsələn "2025-06-18". Bu sizin tətbiqinizin versiyası deyil, protokolun öz versiyasıdır. Klient bildirir: “Mən MCP-nin bu versiyasında danışmağı gözləyirəm.” Server cavabda ya bunu təsdiqləməlidir, ya da bilmirsə xəta qaytarmalıdır.
Bu, “klient birini güman edir, server isə başqasını reallaşdırır” vəziyyətinə qarşı qorunmadır. Ortaq versiya tapılmırsa, uyğunsuz mesajlarla mübadilə etməkdənsə, bağlantını dürüstcə kəsmək daha yaxşıdır.
capabilities (klient)
Klientin özü hansı MCP imkanlarını dəstəklədiyini bəyan etdiyi obyekt. Məsələn, ChatGPT klienti çox vaxt elicitation açarını göstərir və bununla istifadəçidən əlavə daxilolmaları, təsdiqləri və s. tələb edə bildiyini siqnal verir.
Nümunə:
"capabilities": {
"elicitation": {},
"sampling": {}
}
Server bu məlumatdan istifadə edərək hansı genişləndirilmiş protokol imkanlarını ümumiyyətlə işlətməyin mənalı olduğunu anlaya bilər. Məsələn, elicitation o deməkdir ki, klient (ChatGPT) istifadəçiyə dəqiqləşdirici suallar verə və əlavə məlumat istəyə bilər.
clientInfo
Sadə metainfo: klientin adı və versiyası.
"clientInfo": {
"name": "ChatGPT",
"version": "2.0.0"
}
Server tərtibatçısı baxımından bu, loglar üçün qızıldır: hansı klientin qoşulduğunu — ChatGPT, MCP Inspector, öz test klientiniz və onun versiya nömrəsini — həmişə görə bilərsiniz.
4. Server nə cavab verir: initialize nəticəsi
initialize sorğusuna cavab — eyni id ilə adi JSON-RPC nəticəsidir, ancaq result sahəsinə serverin nələri bacardığını təsvir edən obyekt qoyulur.
Sorğuda capabilities-ə klient tərəfindən — yəni özü nəyi dəstəkləyir — baxdıq. İndi isə cavabdakı güzgü obyektini nəzərdən keçirək: serverin capabilities-i, yəni serverin bacardıqları. Sxematik:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-06-18",
"capabilities": {
"tools": {
"listChanged": true
},
"resources": {},
"prompts": {},
"logging": {}
},
"serverInfo": {
"name": "gift-genius-backend",
"version": "0.1.0"
}
}
}
Bənzər strukturu protokolun rəsmi təsvirində və/və ya SDK izahında görəcəksiniz. Əsas hissələr:
Cavabda protocolVersion
Server ya klientin təklif etdiyi versiyanı təkrarlayır, ya da (teorik olaraq) bir neçə ortaq versiya varsa başqasını seçə bilər. Tipik implementasiyalarda server dəstəkləyirsə, klientin versiyasını sadəcə təsdiqləyir. Dəstəkləmirsə — server xəta qaytarmalı və ünsiyyəti dayandırmalıdır.
serverInfo
Server haqqında metainfo: ad, versiya.
"serverInfo": {
"name": "gift-genius-backend",
"version": "0.1.0"
}
Səslənməsi darıxdırıcıdır, amma məhz bu məlumatlara əsasən loglarda sonra filtr edib axtaracaqsınız: “nə üçün X versiyalı ChatGPT Y versiyalı serverimizlə razılaşmır.”
Serverin capabilities-i
Ən maraqlı sahə. Burada server hansı MCP primitivlərini və genişlənmələri dəstəklədiyini elan edir: tools/*, resources/*, prompts/* işlədə bilir, siyahıların dəyişməsi barədə bildirişlər göndərə bilir və s.
Əgər capabilities-də tools bölməsi yoxdursa, düzgün implementasiya olunmuş heç bir klient tools/list və ya tools/call çağırmaz. Eyni şəkildə, resources yoxdursa, klient resources/list və resources/read göndərməyəcək.
Bu cür capabilities yüngül kontraktdır: “bu serverlə nə etmək olar, nə etmək olmaz”.
5. Capabilities “super qabiliyyətlərin siyahısı” kimi
Daha irəli yalnız serverin capabilities-i bizi maraqlandırır — initialize cavabında gələn və bu serverin hansı MCP primitivlərini dəstəklədiyini müəyyən edən obyekt.
Onun strukturuna daha yaxından baxaq. Nümunə (sadələşdirilmiş, amma spesifikasiyaya yaxındır):
{
"capabilities": {
"tools": {
"listChanged": true
},
"resources": {
"subscribe": true,
"listChanged": true
},
"prompts": {
"listChanged": false
},
"logging": {}
}
Belə nümunə MCP-nin rəsmi arxitekturasında izah olunur. Bölmələr üzrə açaq.
Capabilities.tools
tools açarının olması o deməkdir ki, server tools/list və tools/call metodlarına cavab verə bilir. Əgər orada listChanged: true bayrağı da varsa, bu, alətlərin dəsti dəyişəndə serverin gələcəkdə tools/list_changed bildirişləri göndərə biləcəyini göstərir.
ChatGPT üçün bu faydalıdır: alətlərin siyahısını keşləmək və list_changed alındıqda tam reconnect etmədən onu yeniləmək olar.
Capabilities.resources
resources bölməsi serverin resurslarla işləməyi dəstəklədiyini bildirir: resources/list, resources/read, bəzən axtarış. Daxili bayraqlar:
- subscribe: true — klient resurs dəyişikliklərinə abunə ola bilər (məsələn, canlı loglar və ya fayl yeniləmələri üçün).
- listChanged: true — resurslar əlavə olunanda və ya silinəndə server resources/list_changed bildirişi göndərə bilər.
Bu, xüsusilə böyük kataloqlar və daima dəyişən “canlı” məlumatlar üçün vacibdir.
Capabilities.prompts
Əgər server əvvəlcədən təyin olunmuş promptları (məsələn, domeninizə bağlı model müraciət şablonları) qeydiyyatdan keçirirsə, capabilities-də prompts açarı görünür. Burada da listChanged bayrağı ola bilər.
Klient bu bölməni görərək prompts/list və mümkün prompts/get metodunun əlçatan olduğunu anlayır.
Capabilities.logging və digərləri
Bəzi server implementasiyaları logging də elan edir — bu, serverin MCP üzərindən klientə strukturlu loglar göndərə bilməsi deməkdir, məsələn, sazlama üçün.
Başqa bölmələr də yarana bilər (məsələn, sampling və ya spesifik genişlənmələr). Vacib olan odur ki, protokol əvvəlcədən genişlənə bilən kimi layihələndirilib: capabilities-ə yeni açarlar əlavə edə bilərsiniz, köhnə klientlər isə onları tanımırlarsa sadəcə görməzlikdən gələcəklər.
Insight
Eksperimental olaraq məlum olub ki, ChatGPT App ona göndərilən listChanged mesajlarını nəzərə almır. Hazırda tətbiq yazarkən siz bir dəst aləti elan edib sonra dinamik şəkildə bir neçəsini əlavə/silməyi edə bilməzsiniz. Baxmayaraq ki, MCP protokolu buna imkan verir.
Bu kurs yazılan anda vəziyyət belədir: tətbiqinizi ChatGPT Store-da qeydiyyatdan keçirən zaman, ChatGPT tətbiqinizdən alətlər və resurslar siyahısını soruşur və onları həmişəlik keşləyir. Bu vəziyyətin 2026-cı il ərzində dəyişmə ehtimalı böyükdür, 2026-cı ilin birinci rübündə dəyişmə ehtimalı isə aşağıdır.
6. Handshake-dən sonra discovery: alət və resurs siyahısını necə almaq olar
Handshake “server ümumiyyətlə nə bacarır” sualına cavab verir. Sonrakı addım isə discovery adlanır: klient artıq konkret metodlarla detalları çıxarır — hansı alətlər var, hansı resurslar əlçatandır, hansı promptlar daxildir.
Bunun üçün discovery metodlarından istifadə olunur: şərti olaraq tools/list, resources/list, prompts/list. MCP arxitekturası sənədlərində məhz belə təqdim olunur: handshake → discovery → alət çağırışları.
Sorğu nümunəsi tools/list:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/list",
"params": {}
}
Serverin cavabında alətlərin massivi olur: adlar, təsvirlər, arqumentlərin JSON Schema-sı və bəzən kateqoriya və ya ikonlar kimi metadatalar.
Bundan sonra ChatGPT (və ya başqa klient) siyahını keşləyir və dialoq zamanı ondan istifadə edir ki:
- istifadəçinin tapşırığı üçün uyğun aləti seçsin;
- alətin adının mövcudluğunu yoxlasın;
- tools/call göndərməzdən əvvəl arqumentləri validasiya etsin.
Resurslarla hekayə oxşardır, sadəcə resources/list çox vaxt dərhal milyonlarla qeydi daşımamaq üçün kursorlarla səhifələməni dəstəkləyir. Bu da MCP spesifikasiyasında təsvir olunur və böyük kataloqlar üçün tipik hal kimi izah edilir.
7. Handshake və capabilities — bizim GiftGen tətbiqi nümunəsində
Əvvəlki modullarda hədiyyə seçməyə kömək edən tədris tətbiqi qurmuşduq. Artıq bir vidcetimiz, backend-də suggest_gifts alətimiz, hansısa hədiyyə kataloqumuz var. İndi təsəvvür edək ki, gift-genius MCP serveri üçün handshake necə görünür.
GiftGen üçün handshake nümunəsi
Klientdən sorğu:
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {
"elicitation": {}
},
"clientInfo": {
"name": "ChatGPT",
"version": "2.1.0"
}
}
}
Serverimizdən cavab:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-06-18",
"capabilities": {
"tools": { "listChanged": true },
"resources": { "listChanged": true },
"prompts": {},
"logging": {}
},
"serverInfo": {
"name": "gift-genius-backend",
"version": "0.2.0"
}
}
}
Əslində biz MCP arxitekturasının rəsmi nümunələrini təkrarlayırıq, sadəcə adları tətbiqimizə uyğunlaşdırırıq.
Klient bu cavabdan nə öyrənir:
- Alətlər var (tools) və siyahı dinamik dəyişə bilər (listChanged: true).
- Resurslar var (hədiyyə kataloqumuz, bəlkə fayllarda və ya DB-də saxlanılır).
- Promptlar var (məsələn, “İstifadəçi N üçün hədiyyənin qısa təsvirini formalaşdır” şablonu).
- Server loglar göndərə bilər (inspektorlar və sazlama üçün rahatdır).
Sonra klient tools/list çağırır və məsələn belə bir alət görür:
{
"name": "suggest_gifts",
"description": "Alıcının profilinə əsasən hədiyyə ideyalarını seçir.",
"inputSchema": {
"type": "object",
"properties": {
"age": { "type": "integer" },
"relationship": { "type": "string" },
"budget": { "type": "number" }
},
"required": ["age", "relationship"]
}
}
Və indi istifadəçi “Bacı üçün hədiyyə məsləhət ver, 25 yaş, büdcə 50 dollara qədər” kimi bir şey yazanda, model artıq bilir: suggest_gifts adlı alət var, belə arqumentlər dəsti var və onu tools/call vasitəsilə çağırmaq olar.
8. SDK handshake-i necə gizlədir (və niyə yenə də onu anlamaq vacibdir)
MCP üçün TypeScript SDK-sında (növbəti mühazirədə istifadə edəcəyimiz) bu initialize və notifications/initialized hekayəsinin hamısı connect metodunda gizlidir. Təxmini kod:
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
const server = new McpServer({
name: "gift-genius",
version: "1.0.0",
});
// Alətin qeydiyyatı – SDK bunun əsasında capabilities.tools bölməsini özü quracaq
server.tool(
"suggest_gifts",
{
description: "Hədiyyə ideyalarını seçir.",
inputSchema: {
type: "object",
properties: {
age: { type: "integer" },
relationship: { type: "string" },
budget: { type: "number" },
},
required: ["age", "relationship"],
},
},
async (input) => {
// ... hədiyyə seçimi məntiqi ...
return { suggestions: [] };
},
);
const transport = new StdioServerTransport();
// Burada SDK:
// 1) klientdən initialize qəbul edir,
// 2) serverInfo və capabilities ilə cavab verir,
// 3) notifications/initialized gözləyir,
// 4) sonra tools/* çağırışlarını emal etməyə başlayır.
await server.connect(transport);
SDK siz qeydiyyatdan keçirdikləriniz əsasında capabilities-i avtomatik toplayır: ən azı bir server.tool(...) varsa, capabilities-ə tools bölməsini əlavə edəcək. Resurs və ya promptlar qeydiyyatdan keçirsəniz, resources və prompts da görünəcək.
Handshake və capabilities-i başa düşmək JSON-u əllə yazmaq üçün deyil (heç vaxt belə etməyin), aşağıdakılar üçün lazımdır:
- MCP loglarını oxumaq və klientin alətlərinizi “görməməsinin” səbəbini anlamaq;
- Protokol versiyalarının uyğunsuzluğunu diaqnostika etmək;
- Gərək olduqda xüsusi server və ya qeyri-standart nəqliyyat implementasiya etmək.
9. Protokol versiyaları və imkanların təkamülü
Handshake-dəki protocolVersion sahəsi dekorasiya deyil. MCP spesifikasiyasında açıq vurğulanır: bu, uyğun protokol versiyası barədə anlaşma yoludur; ortaq versiya tapılmırsa, bağlantını tamamlamalıdır.
Tipik ssenari:
- Prod-da MCP serverini "2025-06-18" MCP versiyasını reallaşdıran SDK ilə yayımlayırsınız.
- Vaxt keçir, MCP-nin yeni versiyası çıxır, klienti yeniləyirsiniz, ancaq server hələ köhnədir.
- Klient protocolVersion kimi "2026-02-01" göndərir, server bu versiyanı tanımır və invalid protocol version (və ya oxşarı) xətasını qaytarır.
Təcrübə göstərir: tərtibatçılar tez-tez bu sahəni görməzlikdən gəlir və sonra bağlantının niyə qurulmadığına təəccüblənirlər.
Versiyalara düzgün yanaşma:
- SDK-nızın MCP-nin hansı versiyasını dəstəklədiyini həmişə bilin (adətən sənədlərdə/release qeydlərində yazılır).
- SDK yenilənəndə — protokol versiyasını şüurlu şəkildə yeniləyin.
- Loglar və monitorinq protocolVersion uyğunsuzluğundan doğan inicializasiya xətalarını açıq göstərməlidir.
İmkanların capabilities vasitəsilə genişləndirilməsi də təkamüllə bağlıdır: yeni MCP funksiyaları capabilities-də yeni açarlar kimi əlavə olunur. Köhnə klientlər onları görməzlikdən gəlir, yenilər isə istifadə edə bilir. Rəsmi sənədlərdə bu, geriyə uyğunluğu qorumağın üsulu kimi təsvir olunur.
10. Handshake — ChatGPT və inspektorların gözü ilə
ChatGPT MCP-yə qoşulanda nə edir
Dev Mode-da MCP serverini ChatGPT-yə bağlayanda, platforma pərdəarxasında təxminən belə edir:
- Nəqliyyatı açır (adətən /mcp ünvanında HTTP/stream).
- initialize göndərir — protocolVersion, capabilities və clientInfo ilə (məsələn, “ChatGPT Enterprise, filan versiya”).
- Cavabı alır, serverin capabilities-lərini keşləyir.
- Gördüyü capabilities-dən asılı olaraq tools/list, resources/list, prompts/list çağırır.
- Artıq dialoq zamanı model aləti çağırmaq qərarı verəndə, bu keşlə tutuşdurur: belə alət varmı, arqument sxemi nədir, çağırış necə tərtib olunmalıdır.
Əgər serverin capabilities-lərində tools yoxdursa, ChatGPT hətta tətbiqinizi alət kimi təklif etməyə çalışmayacaq. Əgər resources var, amma orada listChanged bayrağı yoxdur, ChatGPT resurs siyahısını keşləyə və dəyişiklik bildirişlərini gözləməyə bilər.
İnspektorlar və MCP Jam sazlamaya necə kömək edir
MCP Jam / MCP Inspector kimi alətlər demək olar eyni şeyi edir: bağlantı qurur, handshake icra edir, serverin capabilities-lərini sizə göstərir və tools/list, tools/call və başqasını əllə çağırmağa imkan verir.
Tərtibatçı baxımından bu mütləq lazımdır:
- serverin həqiqətən hansı protocolVersion qaytardığını görmək;
- capabilities-də tools, resources, prompts olub-olmadığını dərhal görmək;
- ChatGPT-nin alətləri niyə görmədiyini anlamaq (capabilities elan edilməyib və ya handshake keçməyib).
Bu modulun son mühazirəsində bu alətlərdən daha sıx istifadə edəcəksiniz, amma artıq indi bilməyiniz faydalıdır ki, onlar məhz bizim izah etdiyimiz handshake üzərində işləyir.
11. Handshake və capabilities ilə işləyərkən tipik səhvlər
Nəzəriyyədə hər şey çox düz görünür, amma praktikada məhz handshake və capabilities elan edilməsi çox primitiv bug-ların mənbəyi olur — xüsusən Dev Mode və ya MCP Inspector-da. Aşağıda öz kodunuzda və ya həmkarların loglarında demək olar ki, mütləq rastlaşacağınız bir neçə tipik səhv var.
Səhv №1: initialize sorğusunun yanlış formatı.
SDK-sız MCP serverinin əl ilə implementasiyasında çox yaygın problem — hansısa məcburi JSON-RPC sahəsini itirməkdir. Məsələn, jsonrpc: "2.0" yazmağı unutmaq, method-u qarışdırmaq ("initialize" əvəzinə "init" yazmaq) və ya capabilities-i obyekt əvəzinə boolean etmək. MCP spesifikasiyası dəqiq format gözləyir; istənilən sapma parse xətalarına və bağlantının qırılmasına gətirib çıxarır. Sənədlər və praktik bələdçilər ayrıca məsləhət görür: başqa şeylərə baxmazdan əvvəl initialize-ın spesifikasiyaya ciddi uyğun olduğuna əmin olun.
Səhv №2: protocolVersion-u görməzlikdən gəlmək.
Bəzən tərtibatçılar sənədlərdən nümunəni köçürüb ora təsadüfi sətir qoyur, SDK dəstəyinə baxmırlar. Nəticədə klient və server MCP-nin müxtəlif versiyalarında danışır və bağlantı qurulmur. Xəta “klient ümumiyyətlə qoşulmur” kimi maskalana bilər. protocolVersion-a real kontrakt kimi yanaşmaq lazımdır: bu versiyanı frontend/agent platforması komandası ilə MCP serverini yazan komanda arasında uzlaşdırın.
Səhv №3: Unudulmuş capabilities.
Klassik vəziyyət: serverdə alət qeydiyyatdan keçirmisiniz, amma handshake-i əl ilə implementasiya edərkən initialize cavabının capabilities sahəsinə "tools": {} əlavə etməmisiniz. Inspector-da alətləri görürsünüz, amma ChatGPT “No tools available” göstərir — çünki o capabilities-ə inanır və orada tools bölməsi yoxdursa, tools/list çağırmır. Apps SDK üçün troubleshooting bələdçiləri ayrıca vurğulayır: ChatGPT alətləri görmürsə, ilk növbədə capabilities-i yoxlayın.
Səhv №4: Capabilities-də bəyan edilməmiş metodlardan istifadə etməyə cəhd.
Bəzən tələbələr eksperiment edir və məsələn, capabilities-də resources bölməsi olmayan serverə resources/list göndərirlər. Formal olaraq server Method not found cavabı qaytara bilər, amma düzgün olan bu cür metodları ümumiyyətlə çağırmamaqdır. MCP məhz belə cəhdlərə qarşı capabilities anlayışını təqdim edir. Klient əvvəlcə capabilities-də müvafiq bölmə varmı, buna baxmalı, sonra metodları çağırmalıdır.
Səhv №5: Server notifications/initialized-dən əvvəl “danışmağa” başlayır.
Server initialize cavabını göndərən kimi klientdən notifications/initialized gəlməsini gözləmədən log və ya bildirişlər göndərməyə başlasa, bəzi klientlər bu mesajları görməzlikdən gələ və ya hətta bağlantını kəsə bilər. MCP arxitekturasında vurğulanır ki, əvvəlcə handshake tamamlanmalı, yalnız inicializasiya bildirişindən sonra “iş” həyatı başlamalıdır.
Səhv №6: Siyahının dəyişməsi siqnalı olmadan alət sxemini dəyişmək.
Alətin JSON Schema-sını dəyişəndə (məsələn, sahəni məcburi etmək, arqumentin adını dəyişmək), amma serveri yenidən başlatmırsınız və ya alət siyahısının dəyişdiyi barədə bildiriş göndərmirsinizsə, klient keşi köhnə sxemi saxlaya bilər. Bu isə qəribə validasiya xətalarına yol açır. Spesifikasiya listChanged bayrağından və tools/list_changed, resources/list_changed bildirişlərindən istifadə etməyi təklif edir ki, klient keşi vaxtında yeniləyə bilsin.
Səhv №7: Vaxtından əvvəl optimizasiya və capabilities ətrafında “sehr”.
Bəzən tərtibatçılar bazanı anlamadan klientlərə görə dinamik capabilities generasiyası, versiyalaşdırma və başqa ekzotik sxemlər uydurmağa başlayırlar. Başlanğıc üçün serverin dürüstcə nələri bacardığını elan etmək kifayətdir: tools, resources, prompts, logging. Capabilities-i “gələcək üçün” yox, real ehtiyac yarandıqca genişləndirmək lazımdır. Bu daha çox təşkilati anti-patterndir, sırf protokol xətası deyil, amma döyüş layihələrində çox tez-tez rastlanır.
GO TO FULL VERSION