ਤੁਹਾਡੇ MCP ਸਰਵਰ ਨੂੰ 40 ਟੂਲਸ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ
MCP ਡੈਮੋ ਅਕਸਰ ਸਭ ਕੁਝ ਇੱਕੋ ਵਾਰ ਦਿਖਾਉਂਦੇ ਹਨ। ਉਹ ਹਰ ਐਂਡਪੁਆਇੰਟ (endpoint) ਅਤੇ ਹਰ ਡੇਟਾਬੇਸ ਟੇਬਲ ਦਿਖਾਉਂਦੇ ਹਨ। ਉਹ ਦਾਅਵਾ ਕਰਦੇ ਹਨ ਕਿ ਏਜੰਟ ਕੁਝ ਵੀ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਦਸ ਮਿੰਟਾਂ ਲਈ ਸ਼ਕਤੀਸ਼ਾਲੀ ਲੱਗਦਾ ਹੈ। ਫਿਰ ਮਾਡਲ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਗਲਤ ਟੂਲ ਕਾਲ ਕਰਦਾ ਹੈ। ਇਹ ਗਲਤ ਸ਼ੇਪ (shape) ਵਿੱਚ ਆਰਗੂਮੈਂਟਸ ਪਾਸ ਕਰਦਾ ਹੈ। ਇਹ ਸਰਚ ਐਂਡਪੁਆਇੰਟ ਤੋਂ ਚਾਰਟ ਮੰਗਦਾ ਹੈ। ਇਹ ਕਿਸੇ ਵਿਨਾਸ਼ਕਾਰੀ (destructive) ਐਕਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
ਸਮੱਸਿਆ MCP ਦੀ ਨਹੀਂ ਹੈ। ਸਮੱਸਿਆ MCP ਨੂੰ ਤੁਹਾਡੇ ਬੈਕਐਂਡ (backend) ਲਈ ਇੱਕ ਜਾਦੂਈ ਅਡਾਪਟਰ ਵਾਂਗ ਸਮਝਣ ਵਿੱਚ ਹੈ।
ਇੱਕ MCP ਸਰਵਰ ਸਿਰਫ਼ ਤੁਹਾਡੀ API ਨਹੀਂ ਹੈ ਜੋ ਏਜੰਟਾਂ (agents) ਲਈ ਉਪਲਬਧ ਕਰਵਾਈ ਗਈ ਹੈ। ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਸ਼ਾਬਦਿਕ (literal) ਅਤੇ ਬਹੁਤ ਜਲਦੀ ਭਟਕ ਜਾਣ ਵਾਲੇ ਯੂਜ਼ਰ ਲਈ ਇੱਕ ਪ੍ਰੋਡਕਟ ਸਰਫੇਸ ਹੈ। ਉਹ ਯੂਜ਼ਰ ਇੱਕ ਲੈਂਗੂਏਜ ਮਾਡਲ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਮਾਡਲ ਨੂੰ 40 ਇੱਕੋ ਜਿਹੇ ਟੂਲ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਸਨੂੰ ਸ਼ਕਤੀ ਨਹੀਂ ਦੇ ਰਹੇ। ਤੁਸੀਂ ਉਸਨੂੰ ਲਗਭਗ ਸਹੀ ਹੋਣ ਦੇ 40 ਤਰੀਕੇ ਦੇ ਰਹੇ ਹੋ।
ਆਪਣੇ API ਰੂਟਸ (routes) ਦੀ ਨਕਲ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਇਨਸਾਨ ਡੌਕਯੂਮੈਂਟਸ ਪੜ੍ਹ ਸਕਦੇ ਹਨ ਅਤੇ ਸੰਦਰਭ (context) ਸਮਝ ਸਕਦੇ ਹਨ। ਮਾਡਲ ਨਾਮਾਂ ਅਤੇ ਵੇਰਵਿਆਂ (descriptions) ਦੇ ਪੈਟਰਨ ਮੈਚ ਕਰਦੇ ਹਨ।
ਆਪਣੀ MCP ਲੇਅਰ ਨੂੰ ਯੂਜ਼ਰ ਦੇ ਇਰਾਦੇ (intent) ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਓ।
ਹਰ ਰੂਟ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਵਿੱਚ ਸਮੂਹਬੱਧ ਕਰੋ:
- ਮਾਰਕੀਟ ਸਮਰੀਆਂ ਲਈ ਇੱਕ ਟੂਲ
- ਰਿਲੀਜ਼ ਕੈਲੰਡਰਾਂ ਲਈ ਇੱਕ ਟੂਲ
- ਖਾਸ ਡੇਟਾ ਸਨੈਪਸ਼ਾਟਸ ਲਈ ਇੱਕ ਟੂਲ
- ਇਤਿਹਾਸਕ ਸੰਕੇਤਾਂ (historical indicators) ਲਈ ਇੱਕ ਟੂਲ
ਇੱਕ API ਰੂਟ ਕਹਿੰਦਾ ਹੈ: ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਰਿਕਵੈਸਟ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਸਰਵਰ ਜਵਾਬ ਦੇਵੇਗਾ। ਇੱਕ MCP ਟੂਲ ਨੂੰ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ: ਇਸ ਬਿਲਕੁਲ ਇਸੇ ਕੰਮ ਲਈ, ਇਹਨਾਂ ਬਿਲਕੁਲ ਇਸੇ ਇਨਪੁੱਟਸ ਦੇ ਨਾਲ ਮੇਰਾ ਇਸਤੇਮਾਲ ਕਰੋ, ਅਤੇ ਇਸ ਖਾਸ ਨਤੀਜੇ ਦੀ ਉਮੀਦ ਰੱਖੋ।
ਚੰਗੇ ਟੂਲ ਵੇਰਵੇ (descriptions) ਰੂਟਿੰਗ ਲੌਜਿਕ ਹੁੰਦੇ ਹਨ, ਮਾਰਕੀਟਿੰਗ ਕਾਪੀ ਨਹੀਂ।
ਗਲਤ: name: get_data description: Gets data from the API.
ਬਿਹਤਰ: name: lookup_release_calendar description: Return scheduled economic events for one currency and date range. Use this before answering questions about upcoming macro events.
ਬਿਹਤਰ ਏਜੰਟਾਂ ਲਈ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ:
ਬੋਰਿੰਗ ਨਾਮ ਵਰਤੋ। ਡਿਵੈਲਪਰ fetch ਜਾਂ query ਵਰਗੇ ਸੰਖੇਪ ਨਾਮ ਪਸੰਦ ਕਰਦੇ ਹਨ। ਮਾਡਲਾਂ ਨੂੰ search_docs ਜਾਂ check_deployment_status ਵਰਗੇ ਖਾਸ ਨਾਮਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਸਪਸ਼ਟ ਨਾਮ ਮਹਿੰਗੇ ਪੈਂਦੇ ਹਨ।
ਰਿਸਪਾਂਸ ਸ਼ੇਪ (response shape) ਨੂੰ ਕੰਟਰੋਲ ਕਰੋ। ਵਿਸ਼ਾਲ ਨੇਸਟਡ (nested) ਆਬਜੈਕਟਸ ਵਾਪਸ ਨਾ ਕਰੋ। ਉਹ ਸਭ ਤੋਂ ਛੋਟੀ ਸ਼ੇਪ ਵਾਪਸ ਕਰੋ ਜੋ ਕੰਮ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੋਵੇ। ਜੇਕਰ ਮਾਡਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਡੇਟਾ ਦੇਖਦਾ ਹੈ, ਤਾਂ ਇਹ ਗਲਤ ਫੀਲਡ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ ਜਾਂ ਵੇਰਵਿਆਂ ਬਾਰੇ ਭਰਮ (hallucinate) ਕਰੇਗਾ।
ਅਸਫਲਤਾ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਪ੍ਰੋਡਕ