𝗧𝗵𝗲 𝗠𝗖𝗣 𝗧𝗼𝗼𝗹 𝗖𝗵𝗮𝗻𝗴𝗲𝗱 𝗜𝘁𝘀 𝗦𝗰𝗵𝗲𝗺𝗮. 𝗬𝗼𝘂𝗿 𝗔𝗴𝗲𝗻𝘁 𝗗𝗶𝗱𝗻'𝘁 𝗡𝗼𝘁𝗶𝗰𝗲.

உங்கள் டூல் கால் (tool call) செயலிழக்கவில்லை (crash). அது 200 ஸ்டேட்டஸ் கோட் மற்றும் சரியான JSON-ஐத் திருப்பிக் கொடுத்தது.

ஆனால் அது தவறான ஒப்பந்தத்தின் (contract) அடிப்படையில் இயங்கியது. மூன்று நாட்களுக்கு முன்பு அப்ஸ்ட்ரீம் சர்வர் (upstream server) ஒரு ஃபீல்டை (field) பெயர் மாற்றியது. உங்கள் ஏஜென்ட் பழைய பெயரையே அனுப்பிக்கொண்டிருந்தது. சர்வர் அதை அமைதியாகத் தவிர்த்தது (dropped). முடிவு காலியாக வந்தது. எந்த பிழையும் (error) தோன்றவில்லை. ஒரு வாரம் வரை யாரும் இதைக் கவனிக்கவில்லை.

இது ஒரு அமைதியான தோல்வி (silent failure). லாக்ஸ் (logs) சிவப்பு நிறமாக மாறும் சத்தமான தோல்வி இதுவல்ல. சர்வர் சரியாகப் பதிலளிப்பது போலத் தோன்றும், ஆனால் தரவு (data) தவறாக இருக்கும் வகை இது.

MCP சர்வர்கள் அழைப்புகளுக்கு இடையே ஒரு டூல் ஒப்பந்தத்தை மாற்றக்கூடும். அவை ஒரு பாராமீட்டரை (parameter) பெயர் மாற்றலாம் அல்லது ஒரு ஃபீல்ட் விளக்கத்தை (field description) மாற்றலாம். இந்த மாற்றங்கள் பெரும்பாலும் கட்டமைப்பளவில் (structurally) செல்லுபடியாகும் வகையில் இருக்கும். JSON சரிபார்ப்பு (validation) வெற்றிகரமாக முடியும். சர்வர் 200 என்ற பதிலைத் தரும். உங்கள் ஏஜென்ட் ஒரு பிழையும் இல்லாமல் தவறான தரவின் அடிப்படையில் செயல்படும்.

தீர்வு எளிது: • ஒவ்வொரு டூல் ஒப்பந்தத்தின் SHA-256 ஹாஷையும் (hash) நிலையாக வைக்கவும் (Pin). • அந்த ஹாஷில் ஸ்கீமா (schema) மற்றும் விளக்கம் (description) ஆகிய இரண்டையும் சேர்க்கவும். • ஒவ்வொரு அழைப்பிற்கும் முன் ஹாஷைச் சரிபார்க்கவும். • ஒப்பந்தம் மாறினால் (drifts), அழைப்பை நிறுத்திவிடவும்.

ஒரு டூல் பதிலளிக்கிறதா என்பதில் மட்டுமே நாம் கவனம் செலுத்துகிறோம். நாம் ஸ்டேட்டஸ் கோட்களைச் சரிபார்க்கிறோம். டைம்அவுட்களை (timeouts) அமைக்கிறோம். 5xx பிழைகளின் போது மீண்டும் முயற்சிக்கிறோம் (retry). ஏஜென்ட் ஸ்கீமாவைத் தெரிந்துகொண்ட தருணத்திற்கும், அது அழைப்பைச் செய்த தருணத்திற்கும் இடையில் ஒப்பந்தம் மாறியுள்ளதா என்பதை யாரும் சரிபார்ப்பதில்லை.

ஒரு MCP சர்வர் tools/list மூலம் டூல்களை வெளிப்படுத்துகிறது. ஒவ்வொரு டூலுக்கும் ஒரு inputSchema மற்றும் விளக்கம் இருக்கும். உங்கள் ஏஜென்ட் ஒரு செஷனின் (session) தொடக்கத்தில் இதை ஒருமுறை வாசிக்கும்.

சர்வர் புதுப்பிக்கப்பட்டால், அது பின்வருவனவற்றைச் செய்யலாம்:

  • கூடுதல் பண்புகளை (properties) அப்படியே விட்டுவிட்டு, ஒரு பாராமீட்டரை பெயர் மாற்றலாம் (உதாரணமாக query என்பதிலிருந்து q என). பழைய பாராமீட்டர் அமைதியாகத் தவிர்க்கப்படும்.
  • ஒரு ஃபீல்டின் பொருளை மாற்றலாம். ஒரு லிமிட் (limit) "max results" என்பதிலிருந்து "page index" என மாறலாம். அதன் வகை (type) ஒரு integer ஆகவே இருப்பதால், சரிபார்ப்பு (validation) வெற்றிகரமாக முடியும்.
  • ஒரு enum-ன் வரம்பைக் குறைக்கலாம். ஒரு சரியான மதிப்பு புதிய இயல்புநிலை (default) மதிப்பிற்கு மாற்றப்படலாம்.

ஒரு பட்டியல் மாறினால் சர்வர் கிளையண்டிற்குத் தெரிவிக்க வேண்டும் (SHOULD) என்று MCP ஸ்பெக் (spec) கூறுகிறது. ஆனால் அது கண்டிப்பாகத் தெரிவிக்க வேண்டும் (MUST) என்று கூறவில்லை. பல சர்வர்கள் இந்த அறிவிப்பை அனுப்பாது. அப்படி அனுப்பினாலும், ஒரு குறிப்பிட்ட டூல் ஸ்கீமா மாறியிருப்பதை அவை உங்களுக்குத் தெரிவிக்காமல் போகலாம்.

கட்டமைப்பிலான சரிபார்ப்பை (structural validation) மட்டும் நம்பியிருப்பதை நிறுத்துங்கள். அது பொருளில் ஏற்படும் மாற்றத்தைக் கண்டறிய முடியாது.

உங்கள் MCP டூல்களை மென்பொருள் சார்புகளைப் (software dependencies) போலக் கருதுங்கள். ஒரு lockfile அணுகுமுறையைப் பயன்படுத்துங்கள். முதல் தொடர்பின் போது, டூலின் ஸ்கீமா மற்றும் விளக்கத்தின் SHA-256 ஹாஷை எடுத்துக் கொள்ளுங்கள். ஒவ்வொரு அழைப்பிற்கும் முன், ஹாஷை மீண்டும் கணக்கிடுங்கள். அவை பொருந்தினால், தொடரவும். அவை பொருந்தவில்லை என்றால், மாற்றத்தைக் (drift) குறித்துக் காட்டிவிட்டு நிறுத்தவும்.

விளக்கத்தை ஹாஷ் செய்வதுதான் ரகசியம். ஒரு பாராமீட்டர் "max results" என்பதிலிருந்து "page index" என மாறினால், ஸ்கீமா ஒன்றாகவே இருக்கும். ஆனால் வார்த்தைகள் மாறுவதால் ஹாஷ் மாறும். இது சரிபார்ப்பால் (validation) கண்டறிய முடியாத பொருள் சார்ந்த விலகலை (semantic drift) கண்டறிய உதவும்.

ஒப்பந்தம் மாறும்போது யூகிக்காதீர்கள். கண்மூடித்தனமாக மீண்டும் முயற்சிக்காதீர்கள். சற்று நிறுத்தி, வித்தியாசத்தைப் பதிவு செய்து (log), ஒப்பந்தத்தைச் சரிசெய்யுங்கள்.

Source: https://dev.to/0012303/the-mcp-tool-your-agent-calls-changed-its-schema-it-didnt-notice-5g6m

விருப்பமான கற்றல் சமூகம்: https://t.me/GyaanSetuAi