1. Bu gün nə quracağıq və tətbiqə necə oturur
Tədris tətbiqimizi xatırlayaq: biz hədiyyə seçimi üzrə köməkçi hazırlayırıq. Əvvəlki modullarda bizdə artıq bunlar vardı:
- ChatGPT‑də vidcet (Next.js 16 + Apps SDK), UI və vəziyyəti göstərir və callTool çağırmağı bacarır;
- sadə backend (Apps SDK / Next.js marşrutları vasitəsilə), hansı ki, hədiyyələr üçün stub/mok qaytarırdı.
İndi köməkçimizin “beyinlərini” ayrı bir MCP‑serverə çıxarmaq istəyirik. Nəticədə şəkil belə olacaq:
flowchart TD
subgraph ChatGPT
U[İstifadəçi
söhbətdə]
W["Tətbiq vidceti
(Apps SDK)"]
end
subgraph MCP Client
C[ChatGPT MCP client]
end
subgraph OurServer[Bizim MCP serveri]
T1[Tool: suggest_gifts]
R1[Resource: gift_catalog]
P1[Prompt: birthday_template]
end
U --> W
W -- callTool --> C
C <-- JSON-RPC / HTTP --> OurServer
OurServer --> C
C --> W
Yəni indi:
- ChatGPT daxilindəki model bizim MCP‑serveri standart tools/resources/prompts dəsti kimi görür;
- vidcetdən callTool məntiqi olaraq daxili MCP çağırışına çevrilir;
- serverimiz müqavilələri (sxemlər, təsvirlər) təsvir edir və biznes‑məntiqi reallaşdırır.
Mühazirənin sonunda ayrıca MCP‑serveri olan bir Node/TypeScript layihəniz olmalıdır, hansı ki:
- lokalda bir əmr ilə qalxır;
- ən azı bir alət və bir resursu qeydiyyatdan keçirir;
- məntiqli məlumat qaytarır (hətta sadə moklarla olsa belə);
- elə qurulub ki, onu sonra inkişaf etdirmək rahat olsun.
Bu arada mövcud backend (Apps SDK/Next.js) indi yenidən yazılmır: olduğu kimi qalır, MCP‑serveri isə ayrıca xidmət kimi yanında qaldırırıq. Daha sonra onu ChatGPT App‑ə “bağlayıb” hədiyyə məntiqini tədricən köhnə stubların əvəzinə ora daşıya biləcəksiniz.
2. Yığın: TypeScript + MCP SDK + HTTP‑nəqliyyat
MCP‑serveri Node.js üzərində TypeScript ilə yazacağıq. MCP üçün rəsmi JS/TS SDK @modelcontextprotocol/sdk paketindədir. O, JSON‑RPC, validasiya və sxem konversiyası rutinlərini öz üzərinə götürür: siz arqumentləri Zod‑sxemlərlə təsvir edirsiniz, SDK isə onları modelin başa düşdüyü JSON Schema‑ya çevirir.
Nəqliyyat üçün HTTP variantı lazımdır: ChatGPT uzaq MCP‑serverlərlə şəbəkə üzərindən danışır, stdio/lokal deyil. MCP spesifikasiyası standart “axınlı HTTP” formatını təsvir edir — mahiyyətcə köhnə HTTP+SSE sxemasının təkamülü. Praktikada bu, bir HTTP‑endpoint‑dir, o, sorğunu (POST/GET) emal edir və lazım gələrsə cavabı axınlayır. TypeScript SDK‑da belə format üçün adətən Express və ya Hono ilə birləşən hazır nəqliyyat var.
Yayınmamaq üçün belə hesab edəcəyik ki, bizdə var:
- server obyekti — McpServer, @modelcontextprotocol/sdk paketindən;
- HTTP‑nəqliyyat (məsələn, StreamableHttpServerTransport və ya oxşarı), hansı ki, Express ilə dost olur.
Dəqiq sinif adları SDK versiyalarında bir qədər dəyişə bilər, amma arxitektura həmişə belədir:
- MCP‑server obyekti yaradırsınız;
- onda tools/resources/prompts qeydiyyatdan keçirirsiniz;
- nəqliyyatı HTTP tətbiqinə qoşursunuz.
3. Layihə quruluşu və hazırlıq
MCP‑server üçün ayrıca qovluq edək. Onu frontend tətbiqlə yanaşı saxlamaq rahatdır, amma ayrıca Node layihəsi kimi:
chatgpt-gift-app/
app/ ← Next.js + Apps SDK (vidcet)
mcp-server/ ← bizim MCP-server
mcp-server içində:
mcp-server/
src/
server.ts ← MCP-server üçün giriş nöqtəsi
gifts.ts ← hədiyyə seçimi üzrə biznes məntiqi
package.json
tsconfig.json
Sadə gifts.ts nümunəsini bir az sonra edəcəyik, indi isə server.ts üzərində cəmləşək.
Təsəvvür edək ki, layihəni artıq init etmisiniz:
mkdir mcp-server
cd mcp-server
npm init -y
npm install typescript ts-node-dev zod express @modelcontextprotocol/sdk
tsconfig.json — ən adi (esnext modules, target node, strict). İstənilən TS layihənizdən götürə bilərsiniz.
4. Biznes məntiqini ayrıca modulda saxlamaq
Dərhal server.registerTool(..., async () => {...}) yazıb bütün məntiqi orada yığmaq cazibədardır. Amma ən başdan bölmək daha yaxşıdır:
- heç nə bilməyən modul — MCP, JSON‑RPC və s. barədə;
- yalnız MCP barədə bilən modul, amma biznes məntiqdən az xəbərdar olan.
src/gifts.ts faylında sadə hədiyyə təklif funksiyasını yazaq:
// src/gifts.ts
export type GiftIdea = {
id: string;
title: string;
price: number;
occasion: string;
};
export type SuggestGiftsInput = {
age: number;
relationship: "friend" | "partner" | "child" | "coworker";
budget: number;
};
export function suggestGifts(input: SuggestGiftsInput): GiftIdea[] {
// hələlik sadə moklar
return [
{
id: "book-1",
title: "Sevimli hobbi barədə kitab",
price: Math.min(input.budget, 30),
occasion: "generic",
},
{
id: "game-1",
title: "Dostlar üçün stolüstü oyun",
price: Math.min(input.budget, 50),
occasion: "party",
},
];
}
Bu funksiya “saf”dır: girişdə parametrlər, çıxışda ideyalar massivi. Onu unit‑testlərlə test etmək, başqa yerdə təkrar istifadə etmək olar və o, heç cür MCP‑dən asılı deyil. Məhz belə etmək tövsiyə olunur: server örtüyü ayrı, biznes funksiyaları ayrı.
5. MCP‑server yaradırıq və HTTP‑nəqliyyatı qoşuruq
İndi giriş nöqtəsi src/server.ts. Sxematik olaraq bizə gərəkdir:
- MCP‑serverin bir instansiyasını yaratmaq;
- onda alətləri, resursları və promtları qeydiyyatdan keçirmək;
- HTTP‑server (məsələn, Express) qaldırmaq və ona MCP nəqliyyatını bağlamaq.
Qaralama ilə başlayaq:
// src/server.ts
import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server";
import { StreamableHttpServerTransport } from "@modelcontextprotocol/sdk/transport/streamable-http";
const app = express();
// 1. MCP-server yaradırıq
const mcpServer = new McpServer({
name: "gift-assistant-mcp",
version: "0.1.0",
});
// 2. Burada sonra tools/resources/prompts qeydiyyatdan keçirəcəyik
// 3. HTTP üzərində nəqliyyatı sazlayırıq
const transport = new StreamableHttpServerTransport({
path: "/mcp", // MCP üçün vahid endpoint
app, // Express tətbiqinə daxil edirik
});
transport.attach(mcpServer);
const PORT = process.env.PORT ?? 4000;
app.listen(PORT, () => {
console.log(`MCP server listening on http://localhost:${PORT}/mcp`);
});
Nəqliyyat sinfinin konkret adı fərqli ola bilər, amma pattern eynidir: bir HTTP‑endpoint yaradırsınız və MCP‑serveri HTTP/stream üzərindən JSON‑RPC emalçısı kimi ona qoşursunuz.
Bu mərhələdə server hələ bir faydalı iş görmür, amma artıq bacarır:
- MCP‑handshake‑dən keçmək;
- kəşf (discovery) üçün bazanı cavablandırmaq (tools/resources/prompts siyahısı — hələ boşdur).
Növbəti addım — ilk aləti qeydiyyatdan keçirməkdir.
6. suggest_gifts alətini MCP SDK ilə qeydiyyatdan keçirmək
Rəsmi Apps SDK və MCP sənədlərində eyni alət qeydiyyatı pattern‑i göstərilir: registerTool metodu; ora adı, deskriptoru (başlıq, təsvir, arqument sxemi) və emalçını ötürürsünüz.
Artıq gifts.ts faylında SuggestGiftsInput tipini təsvir etmişik. İndi Zod‑sxem əlavə edək ki, server giriş arqumentlərini validasiya edə bilsin və LLM‑ə avtomatik düzgün JSON Schema versin.
// src/server.ts (fraqment)
import { z } from "zod";
import { suggestGifts } from "./gifts";
const suggestGiftsInputSchema = z.object({
age: z.number().int().min(0).max(120),
relationship: z.enum(["friend", "partner", "child", "coworker"]),
budget: z.number().min(0),
});
İndi aləti qeydiyyatdan keçirək:
// hələ də server.ts içində
mcpServer.registerTool(
"suggest_gifts",
{
title: "Suggest gift ideas",
description:
"Yaşa, münasibət tipinə və büdcəyə görə hədiyyə ideyaları seçir.",
// SDK Zod-sxemi modeli üçün JSON Schema-ya çevirəcək
inputSchema: suggestGiftsInputSchema,
},
async ({ input }) => {
const ideas = suggestGifts(input);
const text = ideas
.map(
(g) =>
`• ${g.title} — ~${g.price} USD (occasion: ${g.occasion}, id: ${g.id})`
)
.join("\n");
return {
content: [
{
type: "text",
text,
},
],
// structuredContent vidcetdə istifadə oluna bilər
structuredContent: {
ideas,
},
};
}
);
Əsas məqamlar:
- inputSchema — Zod‑sxemdir. TS üçün SDK onu JSON Schema‑ya çevirir və beləliklə aləti model üçün avtomatik təsvir edir.
- Emalçı input olan obyekti qəbul edir (tipi sxemdən alınır). İçəridə öz biznes funksiyanızı çağıra bilərsiniz.
- result daxilində content qaytarırsınız — bu, modelin nəticə kimi görəcəyi mətndir və istəsəniz, sonradan vidcetinizin istifadə edə biləcəyi JSON strukturu ilə structuredContent.
Əvvəlki modullarda Apps SDK ilə alət etmisinizsə, bu kod çox tanış görünməlidir: pattern tam eynidir, sadəcə indi ayrıca MCP‑serverdə yaşayır.
7. Məlumat üçün gift_catalog resursu əlavə edirik
Alətlər — hərəkətlərdir. Bəzən modelin məlumatı resurs kimi almasını da istərsiniz ki, model onu oxuya, axtara bilsin və ya vidcetiniz şablonları, komponentləri və s. yükləyə bilsin. MCP resurslar konsepsiyasını ayrıca təsvir edir — URI, MIME‑tip və məzmunla.
Sadə gift_catalog resursu edək; o, mövcud hədiyyələrin siyahısını qaytarsın. Hələlik eyni moklar olacaq, amma realda bu, baza ixracı və ya product feed ola bilərdi.
Əvvəlcə kataloqun özünü yazaq:
// src/gifts.ts (əlavə)
export const giftCatalog: GiftIdea[] = [
{
id: "book-1",
title: "Proqramlaşdırma üzrə kitab",
price: 25,
occasion: "learning",
},
{
id: "lego-1",
title: "LEGO dəsti",
price: 60,
occasion: "fun",
},
];
İndi resursu serverdə qeydiyyatdan keçirək:
// src/server.ts (fraqment)
import { giftCatalog } from "./gifts";
mcpServer.registerResource(
"gift_catalog",
{
title: "Gift catalog",
description: "Demo və sazlama üçün sadə hədiyyə kataloqu.",
mimeType: "application/json",
},
async () => {
return {
contents: [
{
uri: "mcp://gift-catalog",
mimeType: "application/json",
text: JSON.stringify(giftCatalog, null, 2),
},
],
};
}
);
Burada məntiqi olaraq nə baş verir:
- gift_catalog resurs adı discovery zamanı müştəriyə görünəcək (sonra MCP inspector‑da resurslar siyahısında görəcəksiniz);
- deskriptor insan tərəfindən oxuna bilən təsvir və MIME‑tipini saxlayır;
- emalçı contents massivini URI və mətn ilə qaytarır — bu, MCP‑də resursun standart formatıdır.
Sonra edə biləcəksiniz:
- bu resursu müştəridən oxumaq (məsələn, agent və ya inspector);
- onu UI üçün şablonlar/məlumat kimi istifadə etmək;
- eksperimentlər aparmaq: model hazır kataloqu istifadə edib istifadəçiyə variantları necə izah edir və s.
8. Sadə prompt qeydiyyatdan keçiririk
MCP‑nin üçüncü obyekti — promptlar, əvvəlcədən hazırlanmış göstərişlərdir. Onlar uzun sistem və ya istifadəçi promptlarını təkrar etməməyə, serverdə adlarla saxlamağa imkan verir.
Kiçik bir nümunə edək: birthday_gift promptu, hansı ki, “ad günü üçün hədiyyə söhbətinin” əvvəlcədən doldurulmuş şablonu kimi çağırıla bilər.
// src/server.ts (fraqment)
mcpServer.registerPrompt("birthday_gift", {
title: "Birthday gift helper",
description: "Ad günü hədiyyəsi seçimi üçün sorğu şablonu.",
messages: [
{
role: "system",
content:
"Sən hədiyyə axtarışı üzrə köməkçisən. Dəqiqləşdirici suallar ver və bir neçə variant təklif et.",
},
{
role: "user",
content:
"Mənə ad günü üçün hədiyyə lazımdır. Lazım olan dəqiqləşdirmələri soruş və seçməyə kömək et.",
},
],
});
Qapaq altında MCP müştərilərə imkan verir:
- promptların siyahısını almağa (inspector‑da birthday_gift görəcəksiniz);
- onun məzmununu soruşub modeli üçün baza göstəriş kimi istifadə etməyə.
Ayrı modula — system‑prompt və təlimatlara — bu cür promptların tətbiqin qlobal təlimatları ilə necə uyğunlaşdığını ətraflı müzakirə edirik. Burada isə onları MCP‑serverin bir hissəsi kimi “görmək” bizim üçün kifayətdir.
9. Bütün bunlar runtime‑da necə işləyir
Şəkli tam yığaq.
Müştəri (məsələn, MCP Inspector və ya ChatGPT) bizim HTTP‑endpoint /mcp‑ə qoşulanda:
- handshake baş verir: müştəri və server dəstəklənən imkanlar barədə (tools/resources/prompts və s.) məlumat mübadiləsi edir;
- müştəri discovery metodlarını çağırır: alətlərin, resursların, promptların siyahısını təsvirləri və sxemləri ilə alır;
- model aləti çağırmaq qərarına gələndə, tools/call və ya oxşar metodla JSON‑RPC sorğusu formalaşdırır — server tərəfindəki SDK bunu daxili registerTool emalçısına çevirir;
- emalçı biznes məntiqini icra edir (bizdə bu, suggestGifts və ya giftCatalog verilməsi) və nəticəni standartlaşdırılmış formatda qaytarır;
- SDK cavabı yenidən JSON‑RPC‑yə seriyalaşdırır və eyni HTTP/stream nəqliyyatı ilə müştəriyə göndərir.
JSON‑RPC detallarının hamısı, id formalaşdırılması, metodların marşrutlaşdırılması və s. @modelcontextprotocol/sdk daxilində qalır. Sizin üçün interfeys Apps SDK‑ya çox oxşayır: registerTool/registerResource/registerPrompt və emalçılarla işləyirsiniz, protokol barədə düşünmədən.
10. Lokal işə salma və ilk sadə test
Güman edək, yuxarıdakıların hamısını əlavə etmisiniz. Qalır işə salmaq.
package.json‑a skript əlavə edə bilərsiniz:
{
"scripts": {
"dev": "ts-node-dev src/server.ts"
}
}
İşə salırıq:
npm run dev
Konsolda buna bənzər bir şey görünməlidir:
MCP server listening on http://localhost:4000/mcp
Tam inspeksiya və alətləri əl ilə çağırmağı növbəti mühazirədə MCP Inspector / MCP Jam vasitəsilə edəcəyik. Amma artıq indi curl ilə super sadə smoke‑test edə bilərsiniz:
curl -X POST http://localhost:4000/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
Bu curl — “xam” JSON cavablarına baxmağı sevənlər üçün sırf fakültativ smoke‑testdir. Real inkişafda MCP‑serverlə demək olar həmişə SDK vasitəsilə danışırsınız, JSON‑RPC sorğularını əl ilə yığmırsınız.
Metodun dəqiq adı protokolun və SDK‑nın versiyasından asılıdır, amma fikir budur ki, tools arasında suggest_gifts görünən JSON siyahısı alacaqsınız. Metod üst‑üstə düşməsə — problem deyil: bu mühazirənin məqsədi bütün adları əzbərləmək yox, JSON cavablarına baxmaqdan çəkinməmək və əvvəlki mühazirələr sayəsində onların strukturunu anlamaqdır.
11. ChatGPT App ilə əlaqə və daha da inkişaf
Hələlik MCP‑server ayrıca yaşayır. Növbəti modullarda siz:
- onu MCP Inspector‑a qoşacaq və tools/resources/prompts‑u ChatGPT‑yə toxunmadan ayrıca debug etməyi öyrənəcəksiniz;
- ChatGPT App‑i elə quracaqsınız ki, bu MCP‑serveri alət mənbəyi kimi görsün;
- əvvəllər Apps SDK daxilində reallaşdırılmış məntiqin bir hissəsini (məsələn, daxili tools vasitəsilə) MCP qatına keçirəcəksiniz;
- hazır karkas üzərində avtorizasiya, loqlaşdırma, axın ssenariləri əlavə edəcəksiniz.
İndi vacib olan:
- sizdə tətbiqin “bacarıqları” və “məlumatları”na cavabdeh olan ayrıca servis var;
- bu servis müştərilərlə standart MCP vasitəsilə danışır, xüsusi REST vasitəsilə yox;
- siz artıq protokoldan çəkinmədən alətləri, resursları və promptları əl ilə qeydiyyatdan keçirməyi bacarırsınız.
12. Kod quruluşu və best practices haqqında bir az
Bu cür kiçik nümunədə belə yaxşı vərdişlər formalaşdırmaq olar.
Birincisi, server konfiqurasiyasını ayrı saxlayın. Ad, versiya, loqlaşdırma, nəqliyyat sazlamaları (port, /mcp yolu) kimi hər şeyi kiçik config.ts moduluna çıxarmaq asandır. Sonra, Vercel‑ə və ya MCP‑gateway arxasına deploy edəndə env dəyişənləri əlavə etməli olacaqsınız və özünüzə minnətdar olacaqsınız.
İkincisi, registerTool/registerResource/registerPrompt metodlarının mümkün qədər “nazik” qalmasına çalışın. Sxemlərin, mətnlərin və biznes məntiqinin təsviri — ayrı fayllarda yaxşı görünən şeylərdir:
- gifts.ts — hədiyyə seçimi funksiyaları;
- catalog.ts — məhsul kataloqu ilə iş;
- prompts.ts — prompt toplusu.
Belə olanda server.ts özü “MCP provayderi” kimi bir şeyə çevrilir, hansı ki, hər şeyi sadəcə birləşdirir.
Üçüncüsü, yadda saxlayın ki, MCP‑server təbiəti etibarilə reaktivdir: o, müştərilərin qoşulmasını və onların sorğularını gözləyir. Bu o deməkdir ki, alətlər daxilində bloklayan və ya həddindən artıq uzun əməliyyatlar birbaşa ChatGPT‑də UX‑ə təsir edəcək. Növbəti modullarda timeoutlar, asinxron əməliyyatlar və axın cavabları barədə danışacağıq, amma artıq indi hansı əməliyyatları fonda ayırmaq, hansılarının isə tez cavab verməli olduğunu düşünməyə dəyər.
Insight: ChatGPT MCP‑nin yalnız bir hissəsini dəstəkləyir
Anlamaq vacibdir: ChatGPT Apps MCP‑ni nəqliyyat və format kimi istifadə edir, amma tam hüquqlu MCP müştərisi deyil. Yalnız protokolu oxusanız, runtime‑da hər şeyin necə işləyəcəyi barədə yanlış gözləntilər qurmaq asandır.
“Təmiz” MCP nə vəd edir:
- resurslar (resources) müştərinin sorğusuna əsasən dinamik oxuna bilər, təkcə bir dəfə yox;
- server resourceChanged/toolChanged bildirişləri göndərərək yenilikləri müştəri yenidən yüklənmədən “itələyə” bilər;
- konfiqlər və ya xarici vəziyyət ilə idarə olunan olduqca çevik sistem qurmaq olar, harada ki, tools/resources/prompts toplusu dəyişir.
ChatGPT Apps kontekstində belə deyil. Tətbiq üçün şəkil daha statikdir:
- App qeydiyyatı zamanı ChatGPT bütün tools və resources təsvirini bir dəfə oxuyur;
- sonra bu konfiqurasiya faktiki olaraq tətbiq versiyasının bir hissəsi kimi keşlənir;
- MCP bildirişləri ilə dinamik yeniliklər dəstəklənmir — platforma onları sadəcə görməzlikdən gəlir.
13. İlk MCP‑serveri yazarkən tipik xətalar
Səhv №1: Bütün biznes məntiqini birbaşa registerTool daxilində toplamaq.
“Emalçıda tez bir şey yazım” cazibəsi çox böyükdür, xüsusən də tədris nümunəsində. Amma sonra bu, validasiya, DB ilə iş və cavabın formatlanmasının qarışdığı oxunmaz kombayn olur. Daha yaxşısı — biznes funksiyaları (suggestGifts, kataloqla iş) ayrıca modullara çıxarın, emalçıda isə yalnız “yapışdırma” edin.
Səhv №2: MCP JSON metod adlarına sərt bağlanmaq.
Bəzən tələbələr if (method === "tools/list") kimi şeylər yazır və JSON‑u əl ilə parse edirlər. Belə etmək lazım deyil: bu iş SDK‑nın işidir. MCP spesifikasiyası və metod adları təkamül edə bilər, SDK isə bu qayğını öz üzərinə götürür. registerTool, registerResource, registerPrompt istifadə edin və qoy kitabxana JSON‑RPC‑də bunun necə göründüyünə qərar versin.
Səhv №3: Nəqliyyatı düşünməmək və ChatGPT‑ni stdio‑serverlə qidalandırmağa çalışmaq.
Stdio nəqliyyatı lokal mühitlər üçün idealdır, harada ki, müştəri serveri altproses kimi işə sala bilir. Amma ChatGPT HTTPS ilə danışır və ona HTTP/stream endpoint lazımdır. Stdio‑nu “necəsə tunel vasitəsilə keçirmək” cəhdi ağrı ilə bitir. ChatGPT App üçün dərhal HTTP‑nəqliyyat (Streamable HTTP) edin.
Səhv №4: MIME‑tipləri və resurs strukturunu görməməzlikdən gəlmək.
Resurslarda yalnız məzmun yox, həm də tip (mimeType) və URI vacibdir. Hər yerdə text/plain yazıb düşünmədən JSON sətirlər atsanız, müştərilər (və inspectorlar) bunun nə data olduğunu anlamaqda çətinlik çəkəcək. Düzgün MIME‑tiplərini göstərməyə çalışın (application/json, UI şablonları üçün text/html və s.) və stabil URI‑lər.
Səhv №5: MCP‑serveri “təsadüfi HTTP‑API” kimi istifadə etmək.
Bəzən belə bir cazibə yaranır: “Məndə artıq Express var, qoy bir də /api/whatever asım və ora birbaşa müraciət edim”. MCP endpointini istənilən REST ilə qarışdırmaq yaxşı deyil: bu, konfiqurasiyanı, marşrutlaşdırmanı və təhlükəsizliyi çətinləşdirir. Daha sadə — dəqiq müqavilə olsun: /mcp — MCP üçün, digər ehtiyaclar üçün ayrıca yollar və ya ümumiyyətlə başqa servis. Production‑da bu, gateways və avtorizasiyanın konfiqurasiyası üçün xüsusilə vacibdir. Yəni MCP‑serveri “təsadüfi HTTP‑API” — MCP müqaviləsi ilə bağlı olmayan təsadüfi HTTP endpointləri toplusuna çevirməyin.
Səhv №6: Gələn və gedən MCP mesajlarını loqlaşdırmamaq.
Loqlar olmadan MCP‑server “qara qutuya” çevrilir: “nəsə işləmir, amma nə olduğunu bilmirəm”. Artıq ilk serverdə ən azı stderr‑ə yığcam strukturlaşdırılmış loqlar yazmağın mənası var: alət metodu, status, icra vaxtı. Əsas — həssas məlumatları və tokenləri loqlaşdırmayın; təhlükəsizlik mövzusuna çatanda ayrıca danışacağıq.
Səhv №7: Inspector olmadan hər şeyi birbaşa ChatGPT vasitəsilə debug etməyə çalışmaq.
Tez‑tez belə bir mənzərə olur: tələbə MCP‑server yazır, dərhal onu ChatGPT App‑ə qoşur və hər şey “anlaşılmaz şəkildə qırılır”. Bu vaxt inspector bir dəfə də işə salınmayıb. Nəticədə problemi anlamaq çətindir — protokoldadır, serverdədir, Apps SDK‑dadır, yoxsa modelin davranışındadır. Doğru yol — əvvəlcə MCP‑serverin təcriddə düzgün işlədiyinə (MCP Jam / Inspector vasitəsilə) əmin olmaq, sonra onu tətbiqə qoşmaqdır.
GO TO FULL VERSION