MCP Inspector gjen gabimet funksionale, jo kufijtë e besimit

Për të testuar një server MCP, lidhe me MCP Inspector, krahaso mjetet e publikuara me ato që prisje dhe provo thirrje me hyrje të vlefshme e të gabuara. Udhëzimi zyrtar për klientin web tregon se Inspector shfaq skemat, pranon argumente, ekzekuton mjetet dhe paraqet rezultatet e gjurmën e protokollit. Kështu mund të gjesh një lidhje që dështon, një mjet që mungon ose një përgjigje që nuk përputhet me sjelljen e pritur.

Pas provës funksionale, përdor identitete me leje të ndryshme dhe kontrollo çfarë mund të lexojë, ndryshojë ose dërgojë serveri. Një thirrje e suksesshme nuk tregon nëse përdoruesi kishte të drejtë ta kryente atë. Udhëzimi i NSA-së për sigurinë e MCP rekomandon kufij të qartë besimi, validim të parametrave sipas kontekstit, leje minimale, izolim, kontroll të lidhjeve dalëse dhe regjistra auditimi.

Lidhja dhe inventari i serverit

Nise serverin në një mjedis prove me të njëjtin transport që do të përdorë klienti yt. Për një server lokal që punon me stdio, Inspector mund ta nisë vetë procesin; një komandë shembull është npx @modelcontextprotocol/inspector node path/to/server/index.js. Për një server HTTP, lidhe me adresën e tij të provës. Përdor kredenciale dhe të dhëna prove që lejojnë kontrollin e rezultateve pa prekur objekte reale.

1. Kontrollo nëse lidhja hapet dhe cilat aftësi shpall serveri. Shiko nëse seksionet për mjete, burime ose modele kërkesash përputhen me funksionet që serveri synon të ofrojë.
2. Krahaso emrat dhe përshkrimet e mjeteve me inventarin e projektuar. Një mjet që mungon pengon përdorimin e funksionit; një mjet i papritur mund të zgjerojë sipërfaqen e qasjes.
3. Hap skemën e çdo mjeti. Kontrollo fushat e detyrueshme, llojet e vlerave dhe kufizimet kundrejt sjelljes së zbatimit, sepse një formë që shfaqet saktë nuk provon se serveri i zbaton rregullat.

Nëse serveri publikon burime, lexo një burim prove dhe verifiko përmbajtjen e kthyer. Nëse publikon modele kërkesash, jep argumentet e kërkuara dhe shiko mesazhin e prodhuar. Këto prova zbulojnë ndryshimin mes një aftësie të shpallur dhe një funksioni që punon.

Thirrjet e mjeteve dhe hyrjet e gabuara

Thirr çdo mjet fillimisht me një kërkesë të zakonshme dhe krahaso përgjigjen me kontratën e tij. Për një mjet leximi, kontrollo që kthen objektin e kërkuar dhe strukturën e parashikuar. Për një mjet shkrimi, përdor një objekt prove dhe kontrollo gjendjen e tij pas thirrjes; vetëm mesazhi i suksesit nuk mjafton për të vërtetuar ndryshimin.

• Hiq një fushë të detyrueshme dhe provo një vlerë të llojit të gabuar. Kërkesa duhet të refuzohet pa kryer veprimin.
• Provo një vlerë jashtë kufijve të aplikacionit, një identifikues që nuk ekziston dhe një hyrje tepër të gjatë. Krahaso gabimin e kthyer me gjendjen e të dhënave pas provës.
• Nëse mjeti lejon thirrje të njëkohshme, dërgo kërkesa me objekte prove të ndara. Kontrollo nëse rezultatet ndërrohen, veprimi përsëritet ose mbetet një ndryshim i pjesshëm pas gabimit.

Shiko gjurmën e kërkesave dhe përgjigjeve për të dalluar gabimin e serverit nga mënyra si e paraqet Inspector. Nëse formulari pengon dërgimin e një hyrjeje të pavlefshme, provo të njëjtën hyrje drejtpërdrejt te serveri me një klient prove. Refuzimi në ndërfaqen e testimit nuk vërteton që serveri do ta refuzojë kërkesën kur ajo mbërrin nga një klient tjetër.

Autorizimi kërkon identitete të ndryshme

Për çdo mjet që prek të dhëna ose kryen veprime, përcakto kush duhet të ketë qasje. Përsërite kërkesën pa kredenciale, me një identitet që ka vetëm leje leximi dhe me identitetin e autorizuar për veprimin. Përdor llogari prove të ndara edhe për të kërkuar objektin e një përdoruesi tjetër: leja për të thirrur mjetin nuk nënkupton leje për çdo objekt që mjeti mund të marrë si argument.

Për serverët HTTP që zbatojnë autorizimin sipas MCP, specifikimi i autorizimit kërkon verifikimin e tokenit për serverin e synuar, përgjigje HTTP 401 kur autorizimi mungon ose tokeni është i pavlefshëm dhe HTTP 403 kur lejet janë të pamjaftueshme. Provo edhe token të skaduar ose të lëshuar për një shërbim tjetër. Te serverët lokalë me stdio, kontrollo kredencialet që procesi merr nga mjedisi dhe lejet që ato i japin në shërbimet pasuese; aty prova nuk mbështetet te përgjigjet HTTP.

Inspector mund të të tregojë përgjigjen e një kërkese të caktuar, por një llogari me leje të plota nuk zbulon çfarë ndodh me llogaritë e kufizuara. Ruaj të njëjtin mjet dhe të njëjtat argumente gjatë krahasimit të identiteteve, që ndryshimi i rezultatit t'i përkasë vendimit të autorizimit.

Izolimi, përmbajtja e pabesuar dhe dalja në rrjet

Përcakto paraprakisht skedarët, depot, bazat e të dhënave dhe shërbimet e rrjetit që secili mjet duhet të arrijë. Në mjedisin e provës, kërko një shteg jashtë hapësirës së lejuar, një objekt të përdoruesit tjetër ose një adresë dalëse që nuk i përket funksionit. Serveri duhet ta refuzojë veprimin edhe nëse argumenti përputhet me skemën: forma e vlefshme e një vlere nuk provon se përdorimi i saj lejohet.

Kontrollo edhe kufijtë e procesit që ekzekuton serverin. Nëse një mjet lexon vetëm një dosje prove, procesi nuk ka nevojë për qasje te dosjet e tjera ose te një rrjet i brendshëm. Një refuzim në kod është i dobishëm, ndërsa kufizimi i lejeve të procesit mban të njëjtin kufi edhe kur mjeti merr një hyrje të papritur.

Vendos në një burim prove tekst të pabesuar që i kërkon agjentit të ndryshojë udhëzimet ose të dërgojë të dhëna diku tjetër. Pastaj vëzhgo rrjedhën që e përdor atë burim: përmbajtja duhet të trajtohet si e dhënë, ndërsa vendimi për veprim duhet të vijë nga identiteti dhe rregullat e aplikacionit. Kjo provë përfshin klientin dhe hapat pasues, sepse ekzekutimi i një mjeti të vetëm në Inspector nuk tregon si do të veprojë agjenti me rezultatin.

Regjistrat dhe trafiku dalës

Për çdo kërkesë prove, krahaso gjurmën e Inspector me regjistrat e serverit dhe të shërbimit që ai thërret. Duhet të mund të lidhësh identitetin, mjetin, parametrat e nevojshëm për hetim, vendimin e autorizimit dhe rezultatin. Shmang ruajtjen e tokeneve ose të përmbajtjes së ndjeshme kur një identifikues kërkese dhe të dhëna më të kufizuara mjaftojnë për gjurmim.

Vëzhgo destinacionet e trafikut dalës si për thirrjet e pranuara, ashtu edhe për ato të refuzuara. Një kërkesë e refuzuar nuk duhet të nisë veprim në një shërbim tjetër ose të dërgojë të dhëna para se të zbatohet kontrolli i lejes. Kriteri i pranimit është konkret: funksionet punojnë me hyrjet e parashikuara, hyrjet e gabuara trajtohen pa veprime të padëshiruara dhe i njëjti konfigurim zbaton kufijtë e lejeve, të procesit dhe të rrjetit.

Lexoni gjithashtu:

• Transkriptimi në shqip: 6,98% gabime s’krahasohet pa të njëjtin test
• Viera apo KUQ: beta funksionale përballet me listën e pritjes
• Shqipëria nënshkruan Konventën e OKB-së: provat elektronike kalojnë kufijtë