𝗠𝗖𝗣 ਟੂਲ ਨੇ ਆਪਣਾ ਸਕੀਮਾ (schema) ਬਦਲ ਦਿੱਤਾ। ਤੁਹਾਡੇ ਏਜੰਟ ਨੇ ਇਸ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ।

ਤੁਹਾਡੀ ਟੂਲ ਕਾਲ (tool call) ਕ੍ਰੈਸ਼ ਨਹੀਂ ਹੋਈ। ਇਸਨੇ 200 ਸਟੇਟਸ ਕੋਡ ਅਤੇ ਵੈਲਿਡ JSON ਰਿਟਰਨ ਕੀਤਾ।

ਪਰ ਇਹ ਗਲਤ ਕੰਟਰੈਕਟ (contract) ਦੇ ਵਿਰੁੱਧ ਚੱਲੀ। ਅੱਪਸਟ੍ਰੀਮ ਸਰਵਰ ਨੇ ਤਿੰਨ ਦਿਨ ਪਹਿਲਾਂ ਇੱਕ ਫੀਲਡ ਦਾ ਨਾਮ ਬਦਲ ਦਿੱਤਾ ਸੀ। ਤੁਹਾਡਾ ਏਜੰਟ ਪੁਰਾਣਾ ਨਾਮ ਹੀ ਭੇਜਦਾ ਰਿਹਾ। ਸਰਵਰ ਨੇ ਚੁੱਪਚਾਪ ਇਸਨੂੰ ਡ੍ਰੌਪ (drop) ਕਰ ਦਿੱਤਾ। ਨਤੀਜਾ ਖਾਲੀ ਆਇਆ। ਕੋਈ ਐਰਰ (error) ਨਹੀਂ ਦਿਖਾਈ ਦਿੱਤਾ। ਇੱਕ ਹਫ਼ਤੇ ਤੱਕ ਕਿਸੇ ਨੇ ਇਸ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ।

ਇਹ ਇੱਕ 'ਸਾਈਲੈਂਟ ਫੇਲ੍ਹਅਰ' (silent failure) ਹੈ। ਇਹ ਉਸ ਕਿਸਮ ਦਾ ਨਹੀਂ ਹੈ ਜਿੱਥੇ ਲੌਗਸ (logs) ਲਾਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ ਉਸ ਕਿਸਮ ਦਾ ਹੈ ਜਿੱਥੇ ਸਰਵਰ ਤਾਂ ਸਹੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਪਰ ਡੇਟਾ ਗਲਤ ਹੁੰਦਾ ਹੈ।

MCP ਸਰਵਰ ਕਾਲਾਂ ਦੇ ਵਿਚਕਾਰ ਟੂਲ ਕੰਟਰੈਕਟ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ। ਉਹ ਕਿਸੇ ਪੈਰਾਮੀਟਰ (parameter) ਦਾ ਨਾਮ ਬਦਲ ਸਕਦੇ ਹਨ ਜਾਂ ਫੀਲਡ ਦੀ ਡਿਸਕ੍ਰਿਪਸ਼ਨ (description) ਬਦਲ ਸਕਦੇ ਹਨ। ਇਹ ਤਬਦੀਲੀਆਂ ਅਕਸਰ ਸੰਰਚਨਾਤਮਕ ਤੌਰ 'ਤੇ ਵੈਲਿਡ (structurally valid) ਰਹਿੰਦੀਆਂ ਹਨ। JSON ਵੈਲੀਡੇਸ਼ਨ ਪਾਸ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਰਵਰ 200 ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਏਜੰਟ ਬਿਨਾਂ ਕਿਸੇ ਐਰਰ ਦੇ ਗਲਤ ਡੇਟਾ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ।

ਇਸਦਾ ਹੱਲ ਸਧਾਰਨ ਹੈ: • ਹਰੇਕ ਟੂਲ ਕੰਟਰੈਕਟ ਦਾ ਇੱਕ SHA-256 ਹੈਸ਼ (hash) ਪਿੰਨ ਕਰੋ। • ਉਸ ਹੈਸ਼ ਵਿੱਚ ਸਕੀਮਾ ਅਤੇ ਡਿਸਕ੍ਰਿਪਸ਼ਨ ਦੋਵਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। • ਹਰ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਹੈਸ਼ ਦੀ ਜਾਂਚ ਕਰੋ। • ਜੇਕਰ ਕੰਟਰੈਕਟ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ (drift) ਆਉਂਦਾ ਹੈ, ਤਾਂ ਕਾਲ ਨੂੰ ਰੋਕ ਦਿਓ।

ਅਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਾਂ ਕਿ ਟੂਲ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਅਸੀਂ ਸਟੇਟਸ ਕੋਡ ਚੈੱਕ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਟਾਈਮਆਊਟ (timeouts) ਸੈੱਟ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ 5xx ਐਰਰਸ 'ਤੇ ਰੀਟ੍ਰਾਈ (retry) ਕਰਦੇ ਹਾਂ। ਲਗਭਗ ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਚੈੱਕ ਕਰਦਾ ਕਿ ਜਿਸ ਸਮੇਂ ਏਜੰਟ ਨੇ ਸਕੀਮਾ ਸਿੱਖਿਆ ਸੀ ਅਤੇ ਜਿਸ ਸਮੇਂ ਉਸਨੇ ਕਾਲ ਕੀਤੀ, ਉਸ ਵਿਚਕਾਰ ਕੰਟਰੈਕਟ ਬਦਲ ਤਾਂ ਨਹੀਂ ਗਿਆ।

ਇੱਕ MCP ਸਰਵਰ tools/list ਰਾਹੀਂ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਰੇਕ ਟੂਲ ਵਿੱਚ ਇੱਕ inputSchema ਅਤੇ ਇੱਕ ਡਿਸਕ੍ਰਿਪਸ਼ਨ ਹੁੰਦੀ ਹੈ। ਤੁਹਾਡਾ ਏਜੰਟ ਸੈਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇਸਨੂੰ ਇੱਕ ਵਾਰ ਪੜ੍ਹਦਾ ਹੈ।

ਜੇਕਰ ਸਰਵਰ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਕਰ ਸਕਦਾ ਹੈ:

  • ਕਿਸੇ ਪੈਰਾਮੀਟਰ ਦਾ ਨਾਮ ਬਦਲਣਾ (ਜਿਵੇਂ query ਤੋਂ q) ਜਦੋਂ ਕਿ ਵਾਧੂ ਪ੍ਰੋਪਰਟੀਜ਼ ਨੂੰ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ। ਪੁਰਾਣਾ ਪੈਰਾਮੀਟਰ ਚੁੱਪਚਾਪ ਡ੍ਰੌਪ ਹੋ ਜਾਂਦਾ ਹੈ।
  • ਕਿਸੇ ਫੀਲਡ ਦਾ ਅਰਥ ਬਦਲਣਾ। ਇੱਕ ਲਿਮਿਟ "max results" ਤੋਂ ਬਦਲ ਕੇ "page index" ਹੋ ਸਕਦੀ ਹੈ। ਟਾਈਪ ਇੰਟੇਜਰ (integer) ਹੀ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਵੈਲੀਡੇਸ਼ਨ ਪਾਸ ਹੋ ਜਾਂਦੀ ਹੈ।
  • ਇੱਕ enum ਨੂੰ ਸੀਮਤ ਕਰਨਾ। ਇੱਕ ਵੈਲਿਡ ਵੈਲਯੂ ਨੂੰ ਨਵੇਂ ਡਿਫੌਲਟ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।

MCP ਸਪੈਕ (spec) ਕਹਿੰਦਾ ਹੈ ਕਿ ਜੇਕਰ ਕੋਈ ਲਿਸਟ ਬਦਲਦੀ ਹੈ ਤਾਂ ਸਰਵਰ ਨੂੰ ਕਲਾਇੰਟ ਨੂੰ ਸੂਚਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (SHOULD)। ਇਹ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਉਸਨੂੰ ਜ਼ਰੂਰ (MUST) ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਸਰਵਰ ਇਹ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨਹੀਂ ਭੇਜਣਗੇ। ਭਾਵੇਂ ਉਹ ਭੇਜ ਵੀ ਦੇਣ, ਤਾਂ ਵੀ ਉਹ ਸ਼ਾਇਦ ਤੁਹਾਨੂੰ ਇਹ ਨਾ ਦੱਸਣ ਕਿ ਕਿਸੇ ਖਾਸ ਟੂਲ ਦਾ ਸਕੀਮਾ ਬਦਲ ਗਿਆ ਹੈ।

ਸਿਰਫ ਸਟ੍ਰਕਚਰਲ ਵੈਲੀਡੇਸ਼ਨ (structural validation) 'ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਇਹ ਅਰਥ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਬਦਲਾਅ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦਾ।

ਆਪਣੇ MCP ਟੂਲਸ ਨੂੰ ਸਾਫਟਵੇਅਰ ਡਿਪੈਂਡੈਂਸੀਜ਼ (software dependencies) ਵਾਂਗ ਸਮਝੋ। ਲੌਕਫਾਈਲ (lockfile) ਅਪ੍ਰੋਚ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਪਹਿਲੀ ਵਾਰ ਸੰਪਰਕ ਕਰਨ 'ਤੇ, ਟੂਲ ਦੇ ਸਕੀਮਾ ਅਤੇ ਡਿਸਕ੍ਰਿਪਸ਼ਨ ਦਾ SHA-256 ਹੈਸ਼ ਲਓ। ਹਰ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ, ਹੈਸ਼ ਦੀ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰੋ। ਜੇਕਰ ਉਹ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਤਾਂ ਅੱਗੇ ਵਧੋ। ਜੇਕਰ ਉਹ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਤਾਂ ਬਦਲਾਅ (drift) ਨੂੰ ਫਲੈਗ ਕਰੋ ਅਤੇ ਰੋਕ ਦਿਓ।

ਡਿਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਹੈਸ਼ ਕਰਨਾ ਹੀ ਅਸਲੀ ਰਾਜ਼ ਹੈ। ਜੇਕਰ ਕੋਈ ਪੈਰਾਮੀਟਰ "max results" ਤੋਂ "page index" ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਸਕੀਮਾ ਇੱਕੋ ਜਿਹਾ ਲੱਗਦਾ ਹੈ। ਹੈਸ਼ ਬਦਲ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਸ਼ਬਦ ਬਦਲ ਗਏ ਹਨ। ਇਹ ਉਸ ਸੈਮੈਂਟਿਕ ਡ੍ਰਿਫਟ (semantic drift) ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਵੈਲੀਡੇਸ਼ਨ ਨਹੀਂ ਫੜ ਸਕਦੀ।

ਜਦੋਂ ਕੰਟਰੈਕਟ ਬਦਲਦਾ ਹੈ ਤਾਂ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ। ਅੰਨ੍ਹੇਵਾਹ ਰੀਟ੍ਰਾਈ ਨਾ ਕਰੋ। ਰੁਕੋ, ਅੰਤਰ ਨੂੰ ਲੌਗ ਕਰੋ, ਅਤੇ ਕੰਟਰੈਕਟ ਨੂੰ ਠੀਕ ਕਰੋ।

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

Optional learning community: https://t.me/GyaanSetuAi