ਇੱਕ ਡਿਵੈਲਪਰ ਗਾਈਡ ਇੱਕ ਵਰਕਸਟੇਸ਼ਨ 'ਤੇ Model Context Protocol (MCP) ਸਰਵਰ ਚਲਾਉਣ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਸਾਂਝੀ HTTP ਸੇਵਾ ਵਜੋਂ ਹੋਸਟ ਕਰਨ ਦੇ ਵਿਚਕਾਰ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨਾਂ (trade-offs) ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਲੇਖਕ ਦਾ ਤਰਕ ਹੈ ਕਿ ਇਹ ਚੋਣ ਲੇਟੈਂਸੀ (latency), ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਐਕਸਪੋਜ਼ਰ (credential exposure) ਅਤੇ ਇੱਕ ਟੀਮ AI-ਡਰਾਈਵਨ ਡੇਟਾ-ਐਕਸੈਸ ਲੇਅਰ ਨੂੰ ਕਿੰਨੀ ਆਸਾਨੀ ਨਾਲ ਸਕੇਲ ਕਰ ਸਕਦੀ ਹੈ, ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।
ਇਹ ਫੈਸਲਾ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
MCP ਉਹ ਪੁਲ ਹੈ ਜੋ Claude ਜਾਂ Cursor ਵਰਗੇ large-language-model assistants ਨੂੰ ਪਾਸਵਰਡ ਦੇਖੇ ਬਿਨਾਂ ਡੇਟਾਬੇਸ ਵਿਰੁੱਧ SQL ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਸਿਸਟੈਂਟ ਇੱਕ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਟੂਲ ਰਿਕਵੈਸਟ ਨੂੰ MCP ਸਰਵਰ ਨੂੰ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਕੁਐਰੀ ਚਲਾਉਂਦਾ ਹੈ। ਜੇਕਰ ਸਰਵਰ ਕਿਸੇ ਡਿਵੈਲਪਰ ਦੇ ਲੈਪਟਾਪ 'ਤੇ ਹੈ, ਤਾਂ round-trip ਅਸਲ ਵਿੱਚ ਇੱਕ local function call ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਇਹ ਇੱਕ ਕੇਂਦਰੀ ਹੋਸਟ 'ਤੇ ਹੈ, ਤਾਂ ਹਰ ਰਿਕਵੈਸਟ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹੋਸਟ ਦੇ authentication ਅਤੇ logging ਮਕੈਨਿਜ਼ਮਾਂ ਦੇ ਅਧੀਨ ਹੁੰਦੀ ਹੈ। ਉਹ ਟੀਮਾਂ ਜੋ ਸਿੰਗਲ-ਡਿਵੈਲਪਰ ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਜਾ ਰਹੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਮਾਡਲ ਉਹਨਾਂ ਦੀ ਸੁਰੱਖਿਆ ਸਥਿਤੀ, ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਉਮੀਦਾਂ ਅਤੇ ਆਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ (operational overhead) ਦੇ ਅਨੁਕੂਲ ਹੈ।
ਦੋ ਡਿਪਲਾਈਮੈਂਟ ਮਾਡਲ
Local (stdio)
ਕਲਾਇੰਟ MCP ਸਰਵਰ ਨੂੰ ਇੱਕ child process ਵਜੋਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ standard input / output ਰਾਹੀਂ ਇਸ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਕੋਈ ਨੈੱਟਵਰਕ ਸਟੈਕ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ।
- ਆਦਰਸ਼ ਹੈ: ਵਿਅਕਤੀਗਤ ਡਿਵੈਲਪਰਾਂ, ਤੇਜ਼ ਪ੍ਰਯੋਗਾਂ, ਅਤੇ ਸਿਰਫ਼ ਲੋਕਲ ਟੈਸਟ ਡੇਟਾਬੇਸਾਂ ਲਈ।
- ਫਾਇਦੇ: ਲੇਟੈਂਸੀ (latency) ਲਗਭਗ ਜ਼ੀਰੋ ਹੈ; ਪ੍ਰੋਸੈਸ ਉਪਭੋਗਤਾ ਦੇ ਵਾਤਾਵਰਣ ਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪਾਸਵਰਡ ਕਦੇ ਵੀ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦੇ।
- ਨੁਕਸਾਨ: ਹਰੇਕ ਉਪਭੋਗਤਾ ਨੂੰ ਆਪਣੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਜਾਂ environment variables ਨੂੰ ਬਣਾਈ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ; ਕੋਈ ਕੇਂਦਰੀ audit trail ਨਹੀਂ ਹੈ; ਕਈ ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਸਕੇਲ ਕਰਨ ਲਈ ਹਰ ਵਰਕਸਟੇਸ਼ਨ 'ਤੇ ਸੈੱਟਅੱਪ ਨੂੰ ਦੁਹਰਾਉਣਾ ਪੈਂਦਾ ਹੈ।
Remote (HTTP)
ਸਰਵਰ HTTP ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੋਸਟ 'ਤੇ ਲਗਾਤਾਰ ਚੱਲਦਾ ਹੈ। ਕਲਾਇੰਟ, ਆਮ ਤੌਰ 'ਤੇ OAuth-ਸਟਾਈਲ ਫਲੋਅ ਨਾਲ, ਪ੍ਰਮਾਣਿਕਤਾ (authenticate) ਕਰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ endpoint ਨੂੰ ਰਿਕਵੈਸਟ ਭੇਜਦੇ ਹਨ।
- ਆਦਰਸ਼ ਹੈ: ਟੀਮਾਂ, CI pipelines, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਲਈ ਜਿਸ ਤੱਕ ਕਈ ਲੋਕਾਂ ਜਾਂ ਸੇਵਾਵਾਂ ਦੁਆਰਾ ਪਹੁੰਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
- ਫਾਇਦੇ: audit logs, role-based access control, ਅਤੇ connection pooling ਲਈ ਇੱਕ ਸਿੰਗਲ ਪੁਆਇੰਟ; ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਇੱਕ ਵਾਰ ਇੱਕ ਨਿਯੰਤਰਿਤ vault ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
- ਨੁਕਸਾਨ: ਪ੍ਰੋਵੀਜ਼ਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਲਈ ਵਾਧੂ ਬੁਨਿਆਦੀ ਢਾਂਚਾ; ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ ਹਰ round-trip ਵਿੱਚ ਕੁਝ ਮਿਲੀਸੈਕਿੰਡ ਵਧਾ ਦਿੰਦੀ ਹੈ।
ਆਹਮੋ-ਸਾਹਮਣੇ ਤੁਲਨਾ
| ਪਹਿਲੂ | Local | Remote |
|---|---|---|
| ਉਦੇਸ਼ ਅਨੁਸਾਰ ਵਰਤੋਂ | ਇੱਕ ਉਪਭੋਗਤਾ | ਕਈ ਉਪਭੋਗਤਾ |
| Authentication | Environment variables ਜਾਂ local config | OAuth-ਅਨੁਕੂਲ token flow |
| Auditing | ਕੋਈ ਇਨ-ਬਿਲਟ ਨਹੀਂ | ਕੇਂਦਰੀ log ਹਰ ਰਿਕਵੈਸਟ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ |
| ਸੈੱਟਅੱਪ ਦੀ ਗੁੰਝਲਤਾ | ਘੱਟ ਤੋਂ ਘੱਟ | ਸਰਵਰ provisioning, TLS, token management ਦੀ ਲੋੜ ਹੈ |
| ਲੇਟੈਂਸੀ (Latency) | ਲਗਭਗ ਜ਼ੀਰੋ | ਨੈੱਟਵਰਕ ਹੌਪ ਕਾਰਨ ਵਧੇਰੇ |
| ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਐਕਸਪੋਜ਼ਰ | ਡਿਵੈਲਪਰ ਦੀ ਮਸ਼ੀਨ ਤੱਕ ਸੀਮਤ | ਕੇਂਦਰੀਕ੍ਰਿਤ, ਪਰ ਬ੍ਰੀਚ ਤੋਂ ਬਚਾਅ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ |
ਇੱਕ ਵਿਹਾਰਕ ਹਾਈਬ੍ਰਿਡ ਪਹੁੰਚ
ਜ਼ਿਆਦਾਤਰ ਸੰਸਥਾਵਾਂ ਇੱਕ ਮਾਡਲ ਨਹੀਂ ਚੁਣਦੀਆਂ ਅਤੇ ਹਮੇਸ਼ਾ ਲਈ ਉਸੇ ਨਾਲ ਜੁੜੀਆਂ ਨਹੀਂ ਰਹਿੰਦੀਆਂ। ਗਾਈਡ ਇੱਕ ਪੜਾਅਵਾਰ ਰੋਲਆਊਟ (staged rollout) ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੀ ਹੈ:
- ਲੋਕਲ ਵਿਕਾਸ (Develop locally) – ਇੱਕ sandbox ਡੇਟਾਬੇਸ ਵਿਰੁੱਧ ਇੱਕ ਲੋਕਲ MCP ਸਰਵਰ ਸ਼ੁਰੂ ਕਰੋ। ਇਸਦੀ ਰਫਤਾਰ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ (iteration) ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ ਅਤੇ secrets ਨੂੰ version control ਤੋਂ ਦੂਰ ਰੱਖਦੀ ਹੈ।
- ਰਿਮੋਟ ਵੱਲ ਵਧੋ (Graduate to remote) – ਇੱਕ ਵਾਰ ਜਦੋਂ codebase ਸਾਂਝਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਇੱਕ ਕੇਂਦਰੀ ਹੋਸਟ 'ਤੇ ਲੈ ਜਾਓ। ਕਲਾਇੰਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ HTTP endpoint ਵੱਲ ਮੋੜਨ ਲਈ ਬਦਲੋ ਅਤੇ OAuth ਨੂੰ ਸਮਰੱਥ ਕਰੋ।
- ਪ੍ਰੋਡਕਸ਼ਨ ਦੀ ਰੱਖਿਆ ਕਰੋ (Guard production) – ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਰਿਮੋਟ, ਆਡਿਟੇਬਲ ਗੇਟਵੇ ਦੇ ਪਿੱਛੇ ਰੱਖੋ। AI ਅਸਿਸਟੈਂਟ ਲਈ read-only ਰੋਲ ਲਾਗੂ ਕਰੋ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਪਾਸਵਰਡ ਸਿਰਫ਼ ਇੱਕ secrets manager ਵਿੱਚ ਸਟੋਰ ਕਰੋ ਜਿਸ ਤੱਕ ਰਿਮੋਟ ਸਰਵਰ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।
ਬਚਣ ਲਈ ਆਮ ਗਲਤੀਆਂ
- ਡਿਵੈਲਪਰ ਦੀ
.envਫਾਈਲ ਜਾਂ ਹੋਰ ਲੋਕਲ ਕੌਂਫਿਗ ਵਿੱਚ ਪ੍ਰੋਡਕਸ਼ਨ ਪਾਸਵਰਡ ਸਟੋਰ ਕਰਨਾ। ਜੇਕਰ ਮਸ਼ੀਨ ਨਾਲ ਛੇੜਛਾੜ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਡੇਟਾਬੇਸ ਖੁੱਲ੍ਹਾ ਰਹਿ ਜਾਂਦਾ ਹੈ। - OAuth ਜਾਂ ਤੁਲਨਾਯੋਗ token ਸਿਸਟਮ ਤੋਂ ਬਿਨਾਂ ਰਿਮੋਟ MCP ਸਰਵਰ ਨੂੰ ਡਿਪਲੋਏ ਕਰਨਾ। Plain-text basic auth ਜਾਂ ਸਟੈਟਿਕ API keys ਲੀਕ ਹੋਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
- AI ਅਸਿਸਟੈਂਟ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਟੇਬਲ 'ਤੇ write permissions ਦੇਣਾ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਗਲਤੀ ਨਾਲ
DELETEਸਟੇਟਮੈਂਟਾਂ ਵੀ ਡੇਟਾ ਨੁਕਸਾਨ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀਆਂ ਹਨ; ਇੱਕ read-only ਰੋਲ ਉਸ ਜੋਖਮ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।
ਜਦੋਂ ਲੋਕਲ ਅਜੇ ਵੀ ਸਹੀ ਲੱ
ਜੇਕਰ ਤੁਹਾਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਰਫ਼ਤਾਰ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਕਲੌਤੇ ਉਪਭੋਗਤਾ ਹੋ, ਤਾਂ ਇੱਕ local MCP server ਸਭ ਤੋਂ ਸਿੱਧਾ ਵਿਕਲਪ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ auditability, shared access ਜਾਂ production-grade security ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇੱਕ remote HTTP server ਹੀ ਇੱਕੋ ਇੱਕ ਵਿਹਾਰਕ ਰਸਤਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਸਹੂਲਤ ਲਈ local ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ production data ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ remote, token-protected gateway ਵੱਲ ਤਬਦੀਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਆਪਣੇ deployment model ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਪੜਾਅ ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਪ੍ਰਗਟ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਡੇਟਾ ਦੇ risk profile ਦੇ ਅਨੁਕੂਲ ਰੱਖੋ।