MCP ಆರ್ಕಿಟೆಕ್ಚರ್: ರೇಖಾಚಿತ್ರಗಳೊಂದಿಗೆ ಸಂಪೂರ್ಣ ತಾಂತ್ರಿಕ ವಿಶ್ಲೇಷಣೆ

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂದರೆ MCP (Model Context Protocol) ಅನ್ನು ಸಾಧ್ಯವಾಗಿಸುವ ಮೂಲಭೂತ ಘಟಕಗಳು ಮತ್ತು ಸಂವಹನ ನಿಯಮಗಳ ಸಮೂಹ. MCP ಒಂದು ಓಪನ್-ಸೋರ್ಸ್ ಮಾನದಂಡವಾಗಿದ್ದು, MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಆಧಾರ ಮೂಲಸೌಕರ್ಯವಾಗಿದೆ.

ಯಾವುದೇ MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಮೂರು ಪ್ರಮುಖ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಸುತ್ತಲೇ ನಿರ್ಮಿತವಾಗಿರುತ್ತದೆ: ಹೋಸ್ಟ್, ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್. MCP ಯ ಸಂವಹನ ಚೌಕಟ್ಟನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾ ಲೇಯರ್ ಮತ್ತು ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಲೇಯರ್‌ಗಳಿಂದ ರೂಪುಗೊಂಡಿದೆ ಎಂದು ವಿವರಿಸಲಾಗುತ್ತದೆ. ಡೇಟಾ ಲೇಯರ್ ಎಂದರೆ ಸಂದೇಶಗಳನ್ನು ಹೇಗೆ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಬೇಕು ಎಂಬುದರ ನಿಯಮಗಳ ಸಮೂಹ (MCP ವಿನಂತಿಗಳನ್ನು JSON-RPC 2.0 ನಲ್ಲಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ). ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಲೇಯರ್ ಆ ಸಂದೇಶಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಬಾಹ್ಯ ಸಂಪರ್ಕಗಳಿಗಾಗಿ Streaming HTTP ಅನ್ನು ಬಳಸುತ್ತದೆ.

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂಬುದು Model Context Protocol ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಸರ್ವರ್ ಚೌಕಟ್ಟು. Model Context Protocol ಎಂಬುದು AI ಮಾದರಿಗಳನ್ನು ಟೂಲ್‌ಗಳಿಗೆ, ಡೇಟಾಬೇಸ್‌ಗಳಂತಹ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಮತ್ತು ಇನ್‌ಪುಟ್ ಸಂದರ್ಭವನ್ನು ವಿಸ್ತರಿಸುವ ಪ್ರಾಂಪ್ಟ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುವ ಮುಕ್ತ ಮಾನದಂಡವಾಗಿದೆ. ಇವುಗಳನ್ನು ಒಟ್ಟಾರೆಯಾಗಿ “ಪ್ರಿಮಿಟಿವ್‌ಗಳು” ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ನಿಯಮಿತ ಅಪ್‌ಡೇಟ್‌ಗಳ ಅಗತ್ಯವಿಲ್ಲದೆಯೇ, ಯಾವ ಟೂಲ್‌ಗಳು ಲಭ್ಯವಿವೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಮತ್ತು ಕಾರ್ಯಪ್ರವಾಹಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು MCP ಆರ್ಕಿಟೆಕ್ಚರ್ LLM ಗಳಿಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

MCP ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ರೇಖಾಚಿತ್ರ: AI ಅಪ್ಲಿಕೇಶನ್ ಒಂದು MCP ಸರ್ವರ್‌ನೊಂದಿಗೆ ವಿನಂತಿಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಆ ಸರ್ವರ್ ಟೂಲ್‌ಗಳು, ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

Anthropic ಇದನ್ನು ಪರಿಚಯಿಸಿದಾಗಿನಿಂದ, MCP ಆರ್ಕಿಟೆಕ್ಚರ್ AI ಕಾರ್ಯಪ್ರವಾಹಗಳಲ್ಲಿ ವ್ಯಾಪಕವಾಗಿ ಬಳಕೆಯಾಗುತ್ತಿದೆ. ಇದಕ್ಕೆ ಮುಖ್ಯ ಕಾರಣ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತ್ಯಾಗ ಮಾಡದೆಯೇ, ಬಹು API ಸಂಪರ್ಕಗಳ ಸುತ್ತ ನಿರ್ಮಿಸಲಾದ ವ್ಯವಸ್ಥೆಗಳಂತಹ ಹೆಚ್ಚಿನ ನಿರ್ವಹಣೆ ಬೇಡುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಇದು ಬದಲಾಯಿಸುತ್ತದೆ. ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳು MCP ಸರ್ವರ್‌ನ ಹಿಂದೆ ಇರುವುದರಿಂದ, ಕೇವಲ ಒಂದು ಸಂಪರ್ಕ ಸಾಕಾಗುತ್ತದೆ, ಮತ್ತು ಅಪ್‌ಡೇಟ್‌ಗಳು ಹಾಗೂ ಸೇರ್ಪಡೆಗಳು ಕ್ಲೈಂಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತಕ್ಷಣವೇ ಲಭ್ಯವಾಗುತ್ತವೆ.

ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ಥಳೀಯ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಅಥವಾ ಬಾಹ್ಯ ಪೂರೈಕೆದಾರರಿಂದ ತಮಗೆ ಲಭ್ಯವಿರುವ ಟೂಲ್‌ಗಳು, ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಮತ್ತು ಕರೆಯಲು MCP, LLM ಗಳಿಗೆ ಒಂದು ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಬಾಹ್ಯ ಕಾರ್ಯಚಟುವಟಿಕೆಗೆ ಪ್ರವೇಶ ಒದಗಿಸುವ ಟೂಲ್‌ಗಳ ವಿಷಯದಲ್ಲಿ, ಅನ್ವೇಷಣೆ ಎಂದರೆ ಯಾವ ಟೂಲ್‌ಗಳು ಲಭ್ಯವಿವೆ ಎಂದು ತಿಳಿಯಲು ಹೋಸ್ಟ್ MCP ಸರ್ವರ್‌ಗೆ tools/list ಕರೆಯನ್ನು ಮಾಡುವುದು. ನಂತರ LLM (ಅಥವಾ ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಹೋಸ್ಟ್) ಲಭ್ಯವಿರುವ ಟೂಲ್‌ಗಳ ವಿವರಣೆಗಳನ್ನು ಓದಿ, ಅಗತ್ಯಕ್ಕೆ ತಕ್ಕಂತೆ ಅವುಗಳನ್ನು ವಿನಂತಿಸಬಹುದು. ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳು ಇದೇ ರೀತಿಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಳಸುತ್ತವೆ.

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಘಟಕಗಳ ರೇಖಾಚಿತ್ರ: LLM, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಹೋಸ್ಟ್, ಮೊದಲು ಅನ್ವೇಷಣೆ ಮತ್ತು ನಂತರ ವಿನಂತಿಗಳು ಎಂಬ ಎರಡು ಹಂತಗಳಲ್ಲಿ MCP ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು MCP ಸರ್ವರ್ ಟೂಲ್‌ಗಳು, ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಇದು ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ರೂಢಿಯಾಗಿದ್ದ ಕಸ್ಟಮ್ API-ಆಧಾರಿತ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ವ್ಯತಿರಿಕ್ತವಾಗಿದೆ. ಅಂತಹ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊರಗಿನ ಕಾರ್ಯಚಟುವಟಿಕೆಯನ್ನು ನಿಖರವಾಗಿ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಿದ ವಿನಂತಿಗಳೊಂದಿಗೆ ಮೀಸಲಾದ ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸಿ ಕರೆಯಬೇಕಾಗಿತ್ತು.

ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ ಕೇಂದ್ರೀಯ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಗಿದ್ದು, LLM ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. Perplexity ಮತ್ತು Claude Desktop ನಂತಹ ಪ್ರಸಿದ್ಧ ಟೂಲ್‌ಗಳು MCP ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್‌ಗಳಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು.

ಸರಳ ಕಾರ್ಯಪ್ರವಾಹದಲ್ಲಿ, ಬಳಕೆದಾರರು ಚಾಟ್ ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಪ್ರಶ್ನೆ ಕೇಳುತ್ತಾರೆ. ನಂತರ ಹೋಸ್ಟ್‌ನ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಘಟಕವು ಪ್ರಶ್ನೆಗೆ ಸಂದರ್ಭವನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ MCP ಪ್ರಿಮಿಟಿವ್‌ಗಳು ಲಭ್ಯವಿವೆ ಎಂಬುದನ್ನು ಅವುಗಳ ಸಾಮರ್ಥ್ಯಗಳ ವಿವರಣೆಯೊಂದಿಗೆ LLM ಗೆ ತಿಳಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಎಂಬುದು AI ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿರುವ ಒಂದು ಸಾಫ್ಟ್‌ವೇರ್ ಘಟಕ. ಹೋಸ್ಟ್ ಅಥವಾ LLM ನ ಸೂಚನೆಗಳ ಆಧಾರದ ಮೇಲೆ ಆಂತರಿಕ ಮತ್ತು ಬಾಹ್ಯ MCP ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು MCP ಕ್ಲೈಂಟ್‌ಗೆ ಪ್ರಮಾಣಿತ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವುದು, JSON-RPC ಸಂದೇಶಗಳನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುವುದು, ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವುದು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು ಇದರ ಕೆಲಸ.

“MCP ಹೋಸ್ಟ್” ಮತ್ತು “MCP ಕ್ಲೈಂಟ್” ಎಂಬ ಪದಗಳನ್ನು ಕೆಲವೊಮ್ಮೆ ಪರಸ್ಪರ ಬದಲಿಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಆದರೂ, ಇದು ಉಪಯುಕ್ತ ವ್ಯತ್ಯಾಸವಾಗಿದೆ, ಏಕೆಂದರೆ Perplexity ನಂತಹ ಹೋಸ್ಟ್ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಬಹು MCP ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಬಹುದು. ಸಂಕೀರ್ಣವಾದ AI ಕಾರ್ಯಪ್ರವಾಹಕ್ಕೆ ಡಜನ್‌ಗಟ್ಟಲೆ ಅಥವಾ ನೂರಾರು ಪ್ರತ್ಯೇಕ MCP ಸರ್ವರ್‌ಗಳಿಗೆ ಪ್ರವೇಶ ಬೇಕಾಗಬಹುದು, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಪ್ರತ್ಯೇಕ ಸಂಪರ್ಕವನ್ನು ಬಳಸುತ್ತದೆ.

Perplexity ನಂತಹ MCP ಹೋಸ್ಟ್ ಮೂರು MCP ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡುತ್ತಿರುವ ರೇಖಾಚಿತ್ರ; ಪ್ರತಿಯೊಂದು ಕ್ಲೈಂಟ್ ಡೇಟಾಬೇಸ್, ಫೈಲ್‌ಗಳು ಅಥವಾ ಬಾಹ್ಯ API ನಂತಹ ತನ್ನದೇ ಆದ MCP ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದೆ.

AI-ಆಧಾರಿತ ಟೂಲ್ ಬಳಸಬಹುದಾದ ಎಲ್ಲಾ ಟೂಲ್‌ಗಳನ್ನು ಸರ್ವರ್ ಒದಗಿಸುತ್ತದೆ. ಆರ್ಕಿಟೆಕ್ಚರ್ ದೃಷ್ಟಿಕೋನದಿಂದ, MCP ಸರ್ವರ್ ಒಳಬರುವ ವಿನಂತಿಯನ್ನು ಅರ್ಥೈಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ, ವಿನಂತಿಸಿದ ಪ್ರಿಮಿಟಿವ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ.

MCP ಸರ್ವರ್‌ಗಳು ಮೂರು ವರ್ಗಗಳ ಪ್ರಿಮಿಟಿವ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಬಹುದು:

ಟೂಲ್‌ಗಳು: ಇವು ಮೂಲತಃ ಬಾಹ್ಯ ಸಾಫ್ಟ್‌ವೇರ್ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳು. ಸಾಂಪ್ರದಾಯಿಕ API-ಆಧಾರಿತ ವಿಧಾನವನ್ನು ಪರಿಗಣಿಸಿದರೆ, ವೆಬ್ ಅನಾಲಿಟಿಕ್ಸ್ ಅಪ್ಲಿಕೇಶನ್ ಬಾಹ್ಯ ಸರ್ವರ್‌ಗೆ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಿದ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿ ಡೇಟಾವನ್ನು ಪಡೆಯಬಹುದು. MCP ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ, ಪೂರೈಕೆದಾರರ ಎಲ್ಲಾ ಥರ್ಡ್-ಪಾರ್ಟಿ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳು ಒಂದೇ ಸಂಪರ್ಕದ ಮೂಲಕ ಲಭ್ಯವಿರುತ್ತವೆ, ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ಪ್ರಮಾಣಿತ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ನಿಯಮಗಳ ಪ್ರಕಾರ ರಚಿಸಲಾಗುತ್ತದೆ.
ಸಂಪನ್ಮೂಲಗಳು: ಸಂಪನ್ಮೂಲಗಳು ಓದಲು-ಮಾತ್ರ ಸಂದರ್ಭವನ್ನು ಒದಗಿಸುವ ಡೇಟಾ ಮೂಲಗಳಾಗಿವೆ. ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾಗಳು ಇದಕ್ಕೆ ಉತ್ತಮ ಉದಾಹರಣೆ. ಹೋಸ್ಟ್‌ಗೆ ಲಭ್ಯವಿರುವ ವಿವಿಧ ಮಾಹಿತಿ ಮೂಲಗಳನ್ನು MCP ಸರ್ವರ್ ಒದಗಿಸುತ್ತದೆ. LLM-ರಚಿತ SQL ಹುಡುಕಾಟದಂತಹದರ ಮೂಲಕ ಹೋಸ್ಟ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕ್ವೆರಿ ಮಾಡಿದರೆ, ಅದನ್ನು ಟೂಲ್ ವಿನಂತಿ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
ಪ್ರಾಂಪ್ಟ್‌ಗಳು: ಇವು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು LLM ಗಳಿಗೆ ಸಹಾಯ ಮಾಡುವ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಪ್ರಾಂಪ್ಟ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳು. ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಸಿದ್ಧ ಸೂಚನೆಗಳು ಬೇಕಾಗಿರುವುದರಿಂದ, ಬಳಕೆದಾರರು ಅಥವಾ ಹೋಸ್ಟ್ ಟೂಲ್ ಬದಲಿಗೆ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಕರೆಯುತ್ತಾರೆ. ಸಾಮಾನ್ಯವಾಗಿ, “ಕೋಡ್ ಪರಿಶೀಲಿಸಿ” ಅಥವಾ “ಡೇಟಾ ವಿಶ್ಲೇಷಿಸಿ” ಆಯ್ಕೆಯಂತಹ ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿನ ಪೂರ್ವನಿಗದಿತ ಕಾರ್ಯಗಳನ್ನು, ಬಳಕೆದಾರರು ಆಯ್ಕೆ ಮಾಡಬಹುದಾದ ಪ್ರಾಂಪ್ಟ್‌ಗಳಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.

MCP ಮತ್ತು API ಒಂದನ್ನೊಂದು ಹೊರಗಿಡುವ ತಂತ್ರಜ್ಞಾನಗಳಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಸಹ ಮುಖ್ಯ. ಅನ್ವೇಷಣೆ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಲಭ್ಯವಿರುವ API ಕರೆಗಳನ್ನು MCP ಸರ್ವರ್ ಒದಗಿಸಬಹುದು. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ, ಇವುಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಜವಾಬ್ದಾರಿ ಕ್ಲೈಂಟ್‌ನದ್ದಲ್ಲ, MCP ಪೂರೈಕೆದಾರರದ್ದು.

MCP ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿನ ಡೇಟಾ ಲೇಯರ್ ಎಂದರೆ ವಿನಂತಿಗಳು, ಪ್ರತಿಕ್ರಿಯೆಗಳು ಮತ್ತು ಅಧಿಸೂಚನೆಗಳನ್ನು ಹೇಗೆ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ನಿಯಮಗಳ ಸಮೂಹ. ಸಂದೇಶಗಳ ಪ್ರಮಾಣಿತ ಭಾಷೆ JSON-RPC ಆಗಿದೆ.

ಎಲ್ಲಾ MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಒಂದು ಮೂಲ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ: (1) ಹೋಸ್ಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸುವಿಕೆ ಮತ್ತು ಅನ್ವೇಷಣೆ, (2) MCP ಸರ್ವರ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆ, ಮತ್ತು (3) ಹೋಸ್ಟ್‌ನಿಂದ ಕರೆ (ಕೆಲವೊಮ್ಮೆ ಇದನ್ನು LLM ನಿರ್ಧರಿಸುತ್ತದೆ); ಪ್ರತಿಯೊಂದು ಹಂತವೂ ಪ್ರತ್ಯೇಕ JSON ಸಂದೇಶವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.

MCP ಡೇಟಾ ಲೇಯರ್‌ನ ರೇಖಾಚಿತ್ರ: ಬಳಕೆದಾರರು ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಪ್ರಾಂಪ್ಟ್ ಕಳುಹಿಸುತ್ತಾರೆ, ಅಲ್ಲಿ LLM, MCP ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ; ಕ್ಲೈಂಟ್ MCP ಸರ್ವರ್‌ಗೆ (ಟೂಲ್‌ಗಳು, ಸಂಪನ್ಮೂಲಗಳು, ಪ್ರಾಂಪ್ಟ್‌ಗಳು) ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಹೋಸ್ಟ್ ಬಳಕೆದಾರರಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಟೂಲ್ ಅನ್ವೇಷಣೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಎರಡು ಉದಾಹರಣೆಗಳ ಮೂಲಕ ನೋಡೋಣ (ಇವು ಸಂಪನ್ಮೂಲಗಳು ಅಥವಾ ಪ್ರಾಂಪ್ಟ್‌ಗಳಿಗೂ ಅನ್ವಯಿಸಬಹುದು):

LLM ಉತ್ಪಾದನೆಗೆ ಮೊದಲು ಟೂಲ್‌ಗಳನ್ನು ಅನ್ವೇಷಿಸಿ: ಹೋಸ್ಟ್ MCP ಕ್ಲೈಂಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಅದು tools/list ವಿನಂತಿಯನ್ನು (MCP ಸರ್ವರ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಟೂಲ್‌ಗಳ ಪಟ್ಟಿ) ಕಳುಹಿಸುತ್ತದೆ. ಉತ್ಪಾದನಾ ಪ್ರಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ LLM ಇದನ್ನು ಪರಿಶೀಲಿಸಿ, ನಿರ್ದಿಷ್ಟ ಟೂಲ್, ಸಂಪನ್ಮೂಲ ಅಥವಾ ಪ್ರಾಂಪ್ಟ್ ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಹುಡುಕಾಟ ನಡೆಸುವ ಆಯ್ಕೆಯನ್ನು LLM ಗೆ ಒದಗಿಸಿ: ಏಜೆಂಟಿಕ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ, ಹೋಸ್ಟ್ search-tools ನಂತಹ ಅನ್ವೇಷಣೆ ಆಯ್ಕೆಯನ್ನು ಸಂದರ್ಭ ಇನ್‌ಪುಟ್‌ಗೆ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ LLM ಹುಡುಕಾಟವನ್ನು ವಿನಂತಿಸಬಹುದು.

ಹೆಚ್ಚಾಗಿ ಬಾಹ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳಾಗಿರುವ ಟೂಲ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ LLM ಅಥವಾ ಹೋಸ್ಟ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಕೆದಾರರ ಕೋರಿಕೆಯ ಮೇರೆಗೆ ಅಥವಾ ಹೋಸ್ಟ್‌ನಿಂದ ವಿನಂತಿಸಲಾಗುತ್ತದೆ.

ಕಾಲ್ಪನಿಕ ನೋಟ್ಸ್ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ MCP ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುವ tools/list ವಿನಂತಿ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ “id”:101 ಒಂದು ID ಬಳಸಿ ವಿನಂತಿಯನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು “params” ಫೀಲ್ಡ್ ಕ್ಲೈಂಟ್‌ನ ಹೆಸರು (notes-app-client) ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳಂತಹ ಕ್ಲೈಂಟ್ ಕುರಿತ ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, MCP ಸರ್ವರ್ ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಇವುಗಳಲ್ಲಿ ಲಭ್ಯವಿರುವ ಟೂಲ್‌ಗಳ ಹೆಸರುಗಳು ಮತ್ತು ಅವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ವಿವರಗಳು ಸೇರಿರುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಈ ಪಟ್ಟಿಯಲ್ಲಿ add-task ಟೂಲ್ ಇರಬಹುದು. ಇದು ಸಂಪರ್ಕಿತ ಕಾರ್ಯ ನಿರ್ವಹಣಾ ಅಥವಾ ಕ್ಯಾಲೆಂಡರ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೂ ಶೀರ್ಷಿಕೆ ಮತ್ತು ಆದ್ಯತೆಯನ್ನು ನಿಗದಿಪಡಿಸುತ್ತಾ ಕಾರ್ಯಗಳನ್ನು ರಚಿಸಲು ನೋಟ್ಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ವಿನಂತಿ ಹೇಗಿರಬಹುದು ಎಂಬುದು ಇಲ್ಲಿದೆ:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

“method” ಫೀಲ್ಡ್ ಇದು ಟೂಲ್ ಕರೆ ಎಂದು MCP ಸರ್ವರ್‌ಗೆ ತಿಳಿಸುತ್ತದೆ, “name” ಯಾವ ಟೂಲ್ ಅನ್ನು ಕರೆಯಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಮತ್ತು “arguments” ಅಗತ್ಯವಿರುವ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಮತ್ತು MCP ಸರ್ವರ್ ನಡುವಿನ ಸಂಪರ್ಕದಲ್ಲಿ ಡೇಟಾ ಲೇಯರ್ ಏನು ಎಂಬುದಾದರೆ, ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಲೇಯರ್ ಹೇಗೆ ಎಂಬುದಾಗಿದೆ. ಸಂದೇಶಗಳು ಸಾಗುವ ವಿಧಾನವನ್ನು ಇದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ: ನಿರ್ದಿಷ್ಟ ಚಾನಲ್ ಮತ್ತು ವಿನಂತಿಗಳು ಹಾಗೂ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಹೇಗೆ ತಲುಪಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುವ ನಿಯಮಗಳು.

MCP ಎರಡು ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದೆ:

ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಇನ್‌ಪುಟ್/ಔಟ್‌ಪುಟ್: MCP ಸರ್ವರ್ ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ ಇರುವ ಅದೇ ಸ್ಥಳೀಯ ಪರಿಸರದಲ್ಲಿ ಚಾಲನೆಯಾಗುವಾಗ ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ JSON ವಿನಂತಿಯನ್ನು ಸರ್ವರ್‌ನ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಇನ್‌ಪುಟ್‌ಗೆ ಬರೆಯುತ್ತದೆ. ಸರ್ವರ್ ಅದನ್ನು ಓದಿ, ವಿನಂತಿಸಿದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸಿ, ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಔಟ್‌ಪುಟ್‌ಗೆ ಬರೆಯುತ್ತದೆ.
Streamable HTTP: MCP ಸರ್ವರ್ ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊರಗೆ ಚಾಲನೆಯಾಗುವಾಗ, MCP ಕ್ಲೈಂಟ್ HTTP POST ಬಳಸಿ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಸರ್ವರ್ ಒಂದೇ JSON ಸಂದೇಶದೊಂದಿಗೆ ಅಥವಾ Server-Sent Events (SSE) ಸ್ಟ್ರೀಮ್‌ನೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಇದು ನಿರಂತರ “ಆಲಿಸುವ” ಚಾನಲ್ ಆಗಿದ್ದು, ಕಾಲಕ್ರಮೇಣ ಬಹು ಸಂದೇಶಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲು ಸರ್ವರ್‌ಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

MCP ಮಲ್ಟಿ-ಟೆನೆಂಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂಬುದು ಏಕಕಾಲದಲ್ಲಿ ಬಹು ಬಳಕೆದಾರರಿಗೆ (ಟೆನೆಂಟ್‌ಗಳಿಗೆ) ಸೇವೆ ಒದಗಿಸಬಲ್ಲ ಒಂದು ರೀತಿಯ ಅನುಷ್ಠಾನವಾಗಿದೆ.

ಇಲ್ಲಿ, ಟೆನೆಂಟ್ ಎಂದರೆ ಒಬ್ಬ ವ್ಯಕ್ತಿ, ವ್ಯಕ್ತಿಗಳ ಗುಂಪು ಅಥವಾ ಒಂದು ಸಂಸ್ಥೆ ಆಗಿರಬಹುದು. ಅನುಷ್ಠಾನವು ಪ್ರತಿ ಟೆನೆಂಟ್‌ಗೂ ಪ್ರತ್ಯೇಕ MCP ಸರ್ವರ್ ಅನ್ನು ಚಲಾಯಿಸುವುದು, ಒಂದೇ ಹಂಚಿಕೆಯ ಸರ್ವರ್‌ಗೆ ಪ್ರವೇಶ ಒದಗಿಸುವುದು ಅಥವಾ ಸರ್ವರ್‌ಗಳ ಸಮೂಹವನ್ನು ಕೇಂದ್ರೀಯ ಗೇಟ್‌ವೇ ಹಿಂದೆ ಇರಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಗೇಟ್‌ವೇ ಬಳಸಿದಾಗ, ಅದು ಬಳಕೆದಾರರ ಗುರುತು ಅಥವಾ ವಿನಂತಿಯ ಸ್ವರೂಪದ ಆಧಾರದ ಮೇಲೆ ವಿನಂತಿಗಳನ್ನು ಸರಿಯಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಿಗೆ ರವಾನಿಸುತ್ತದೆ.

ಇದು ಪ್ರಮಾಣಿತ MCP ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಅದೇ ಮೂಲ ತತ್ವದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತ್ಯೇಕ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳು ತಮ್ಮದೇ ಆದ ವರ್ಕ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ (ಅದು ಹಂಚಿಕೆಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒಳಗೊಂಡಿದ್ದರೂ ಸಹ) ಮತ್ತು ಪ್ರತ್ಯೇಕವಾಗಿ ದೃಢೀಕರಿಸಲ್ಪಡುತ್ತವೆ. ಇದು ಎಂಟರ್‌ಪ್ರೈಸ್ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿದೆ, ಮತ್ತು ಬಹು MCP ಸರ್ವರ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಅನಗತ್ಯವಾಗಿ ದುಬಾರಿಯಾಗುವುದರಿಂದ ಹಂಚಿಕೆಯ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಹೆಚ್ಚಾಗಿ ಆದ್ಯತೆ ನೀಡಲಾಗುತ್ತದೆ.

ಆರಂಭದಿಂದ ಅಂತ್ಯದವರೆಗಿನ MCP ವಿನಂತಿ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಹೇಗಿರುತ್ತದೆ? ಇದರಲ್ಲಿ ಎಂಟು ಪ್ರಮುಖ ಹಂತಗಳಿವೆ, ಪ್ರತಿಯೊಂದೂ ವಿಭಿನ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಘಟಕವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಆರಂಭದಿಂದ ಅಂತ್ಯದವರೆಗಿನ MCP ವಿನಂತಿಯ ಎಂಟು ಹಂತಗಳ ಫ್ಲೋಚಾರ್ಟ್: ಟೂಲ್ ಅನ್ವೇಷಣೆ, ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್, ಮಾದರಿ ಪ್ರಕ್ರಿಯೆ, ಟೂಲ್ ಆಯ್ಕೆ, ವಿನಂತಿ, ಟೂಲ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ, ಫಲಿತಾಂಶ ಮತ್ತು ಉತ್ತರ ರಚನೆ.

ಹಿಂದಿನ ಉದಾಹರಣೆಯಾದ, ಕಾರ್ಯ ನಿರ್ವಹಣಾ ಸೇವೆಗೆ ಸಂಪರ್ಕಿತವಾದ ನೋಟ್ಸ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, MCP ಟೂಲ್ ಕರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:

ಟೂಲ್ ಅನ್ವೇಷಣೆ: ನೋಟ್ಸ್ ಅಪ್ಲಿಕೇಶನ್ (ಹೋಸ್ಟ್) ತನ್ನ MCP ಕ್ಲೈಂಟ್ ಬಳಸಿ tools/list ವಿನಂತಿಯ ಮೂಲಕ ಸರ್ವರ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಟೂಲ್‌ಗಳನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಸರ್ವರ್ ಅವುಗಳ ಹೆಸರುಗಳು, ವಿವರಣೆಗಳು ಮತ್ತು ನಿರೀಕ್ಷಿತ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಇದರಲ್ಲಿ add-task ಟೂಲ್‌ನ ವಿವರಗಳೂ ಸೇರಿವೆ. ನೀವು ಪ್ರಾಂಪ್ಟ್ ಸಲ್ಲಿಸುವ ಮೊದಲೇ ಇದು ನಡೆಯಬಹುದು.
ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್: ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿರುವ ಚಾಟ್‌ಬಾಟ್ ಮೂಲಕ ನೀವು LLM-ಆಧಾರಿತ ನೋಟ್ಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸುತ್ತೀರಿ, ಉದಾಹರಣೆಗೆ, “ನನ್ನ ಹೊಸ ಡ್ರಾಫ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ನನ್ನ ಕ್ಯಾಲೆಂಡರ್‌ನಲ್ಲಿ ಮಧ್ಯಮ ಆದ್ಯತೆಯೊಂದಿಗೆ ಒಂದು ಕಾರ್ಯವನ್ನು ರಚಿಸಿ.”
ಮಾದರಿ ಪ್ರಕ್ರಿಯೆ: ಹೋಸ್ಟ್ ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ಮತ್ತು ಸಂಬಂಧಿತ ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು LLM ಗೆ ಕಳುಹಿಸುತ್ತದೆ.
ಟೂಲ್ ಆಯ್ಕೆ: LLM ಟೂಲ್ ಮತ್ತು ಅದರ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ರಚನಾತ್ಮಕ ಟೂಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತದೆ: add-task, ಜೊತೆಗೆ title: Review the draft ಮತ್ತು priority: Medium. ಕ್ರಿಯೆಗೆ ಅನುಮತಿ ಇದೆಯೇ ಎಂದು ಹೋಸ್ಟ್ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು MCP ಕ್ಲೈಂಟ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ, ಅದು JSON-RPC ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
ವಿನಂತಿ: MCP ಕ್ಲೈಂಟ್ ತನ್ನ MCP ಸರ್ವರ್‌ಗೆ tools/call ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
ಟೂಲ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ: ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಶೀರ್ಷಿಕೆ ಮತ್ತು ಆದ್ಯತೆಯೊಂದಿಗೆ ಹೊಸ ಕಾರ್ಯವನ್ನು ರಚಿಸಲು MCP ಸರ್ವರ್ ಕಾರ್ಯ ನಿರ್ವಹಣಾ ಅಪ್ಲಿಕೇಶನ್‌ನ API ಅನ್ನು ಕರೆಯುತ್ತದೆ.
ಫಲಿತಾಂಶ ಹಿಂತಿರುಗಿಸುವಿಕೆ: ಸರ್ವರ್ ಫಲಿತಾಂಶವನ್ನು MCP ಕ್ಲೈಂಟ್‌ಗೆ ಹಿಂದಿರುಗಿಸುತ್ತದೆ, ಅದು ಅದನ್ನು ಹೋಸ್ಟ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ ಅದನ್ನು LLM ಗೆ ಒದಗಿಸುವ ಮಾಹಿತಿಗೆ ಸೇರಿಸುತ್ತದೆ.
ಉತ್ತರ ರಚನೆ: LLM ಫಲಿತಾಂಶವನ್ನು ಬಳಸಿ ಬಳಕೆದಾರರಿಗೆ ಉತ್ತರವನ್ನು ರಚಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ “ಡ್ರಾಫ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಮಧ್ಯಮ ಆದ್ಯತೆಯೊಂದಿಗೆ ಒಂದು ಕಾರ್ಯವನ್ನು ನಾನು ರಚಿಸಿದ್ದೇನೆ.”

MCP ಮತ್ತು ಸಾಂಪ್ರದಾಯಿಕ API ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೆಚ್ಚಾಗಿ ಒಂದಕ್ಕೊಂದು ಗೊಂದಲಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅವು ಪರಸ್ಪರ ಪೂರಕ ತಂತ್ರಜ್ಞಾನಗಳಾಗಿವೆ. MCP ಅನ್ನು ವಿಶೇಷವಾಗಿ AI-ಆಧಾರಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಬಹು ಹಾರ್ಡ್-ಕೋಡೆಡ್ API ಸಂಪರ್ಕಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಭಾರೀ ನಿರ್ವಹಣಾ ಹೊರೆಯನ್ನು ಇದು ನಿವಾರಿಸುತ್ತದೆ.

ಪ್ರತಿ ಕಾರ್ಯಚಟುವಟಿಕೆ ಪೂರೈಕೆದಾರ ಅಥವಾ ಆಂತರಿಕ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಒಂದೇ ಸಂಪರ್ಕವನ್ನು ಒದಗಿಸುವ ಮೂಲಕ, ಅತಿಯಾಗಿ ಉಬ್ಬಿದ ಸಂದರ್ಭ ಇನ್‌ಪುಟ್ (ಎಲ್ಲಾ API ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದು) ಅಥವಾ ಸೀಮಿತ API-ಆಧಾರಿತ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು MCP ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಬದಲಿಗೆ, MCP ಗಳು ತಮ್ಮ ಟೂಲ್ ಪಟ್ಟಿಯ ಭಾಗವಾಗಿ API ಗಳನ್ನು (ಅಥವಾ, ಹೆಚ್ಚು ನಿಖರವಾಗಿ, API ಗಳನ್ನು ಕರೆಯುವ ಕಾರ್ಯಚಟುವಟಿಕೆಯನ್ನು) ಒದಗಿಸಬಹುದು. ಪೂರೈಕೆದಾರರು ತಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಿ ಹೊಸ API ಬಂದಾಗಲೆಲ್ಲಾ, ಅಥವಾ ದಸ್ತಾವೇಜು ಬದಲಾದರೆ, ಅವರು ಕೇವಲ MCP ಸರ್ವರ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುತ್ತಾರೆ. ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬದಿಯಲ್ಲಿ ಯಾವುದೇ ಕೋಡ್ ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿಲ್ಲ.

MCP ಪರಿಚಯವಾದಾಗಿನಿಂದ ಅದರ ಭದ್ರತೆಯು ಹೆಚ್ಚು ಚರ್ಚೆಯ ವಿಷಯವಾಗಿದೆ. ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸುರಕ್ಷಿತ ತಂತ್ರಜ್ಞಾನವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದ್ದರೂ, ಹಲವಾರು ಭದ್ರತಾ ಅಪಾಯಗಳಿವೆ, ಅವುಗಳಲ್ಲಿ ಹಲವು ಸಂಕೀರ್ಣ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನುಷ್ಠಾನಗಳಲ್ಲಿ ಹೆಚ್ಚು ಎದ್ದು ಕಾಣುತ್ತವೆ.

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಈ ಕೆಳಗಿನ ಸಂಭಾವ್ಯ ದೌರ್ಬಲ್ಯಗಳನ್ನು ಹೊಂದಿದೆ:

ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್: ಬಳಕೆದಾರರು ಬಾಹ್ಯ ಡೇಟಾದೊಳಗೆ ದುರುದ್ದೇಶಪೂರಿತ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಸೇರಿಸುತ್ತಾರೆ, ಅದನ್ನು AI ಮಾದರಿ ತಪ್ಪಾಗಿ ಸೂಚನೆ ಎಂದು ಅರ್ಥೈಸಿಕೊಳ್ಳುತ್ತದೆ.
ಅತಿಯಾದ ಸವಲತ್ತುಗಳ ಪ್ರವೇಶ: MCP ಸರ್ವರ್‌ಗಳು AI ಮಾದರಿಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಟೂಲ್‌ಗಳನ್ನು ಒದಗಿಸುವ ಸಾಧ್ಯತೆಯಿದೆ, ಇದು ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳ ಸಾಧ್ಯತೆಯನ್ನು (ಬ್ಲಾಸ್ಟ್ ರೇಡಿಯಸ್) ಹೆಚ್ಚಿಸಬಹುದು.
ಆಕಸ್ಮಿಕ ಡೇಟಾ ಸೋರಿಕೆಗಳು: ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡದ ಅನುಷ್ಠಾನಗಳಿಂದಾಗಿ API ಕೀಗಳು ಅಥವಾ ಡೇಟಾಬೇಸ್ ರುಜುವಾತುಗಳಂತಹ ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿ LLM ಗೆ ರವಾನೆಯಾಗುವ ಸಾಧ್ಯತೆಯಿದೆ.
ಸ್ಥಳೀಯ ಸಿಸ್ಟಮ್‌ನ ದುರುಪಯೋಗ: ಸ್ಥಳೀಯ MCP ಸರ್ವರ್‌ಗಳು ಇತರ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಂತೆಯೇ ದುರುದ್ದೇಶಪೂರಿತ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಂತಹ ಸ್ಥಳೀಯ ಸಿಸ್ಟಮ್ ಸಮಸ್ಯೆಗಳಿಗೆ ಗುರಿಯಾಗಬಹುದು, ಜೊತೆಗೆ ಅವು ಏಜೆಂಟಿಕ್ AI ಸಿಸ್ಟಮ್‌ಗಳ ಮೇಲೆ ಮುಂದಿನ ಹಂತಗಳಲ್ಲಿ ಹಾನಿಕಾರಕ ಪರಿಣಾಮಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು ಎಂಬ ಹೆಚ್ಚುವರಿ ಸಮಸ್ಯೆಯೂ ಇದೆ.

ಈ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳು ಪರಿಹರಿಸಲಾಗದವಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ, ಸಿಸ್ಟಮ್ ಸುರಕ್ಷತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸ್ಥಾಪಿತ ಕ್ರಮಗಳು ಮಾತ್ರ ಸಾಕು. ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಮಾನವ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಇರಿಸುವುದು, ಸೂಕ್ಷ್ಮ ಡೇಟಾದ ಸುತ್ತ ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಂತ್ರಣಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವುದು ಮತ್ತು ಸರ್ವರ್ ದಾಳಿಗಳಿಂದ ರಕ್ಷಣೆ ಪಡೆಯುವುದು ಇವೆಲ್ಲವೂ ಸಾಮಾನ್ಯ ಅಭ್ಯಾಸಗಳಾಗಿವೆ.

MCP ಡೆವಲಪರ್‌ಗಳಿಗೆ ಉಪಯುಕ್ತ ಮತ್ತು ಜನಪ್ರಿಯ ಮುಕ್ತ ಮಾನದಂಡವೆಂದು ಸಾಬೀತಾಗಿದೆ. ಇದು LLM-ಆಧಾರಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿನ ಹಾರ್ಡ್-ಕೋಡೆಡ್ API ಗಳ ಅನೇಕ ಸಮಸ್ಯೆಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳ ಮೇಲಿನ ಕೋಡಿಂಗ್ ಹೊರೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಮುಂದೆ, MCP ಯ ಆಧಾರವಾಗಿರುವ ಹೋಸ್ಟ್ ಮತ್ತು ಸರ್ವರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಬಹುತೇಕ ಖಚಿತವಾಗಿ ಹಾಗೆಯೇ ಉಳಿಯುತ್ತದೆ. ಭವಿಷ್ಯದ ಆವಿಷ್ಕಾರಗಳು ಬಹು-ಹಂತದ ಕಾರ್ಯಪ್ರವಾಹಗಳಾದ್ಯಂತ ಸುಧಾರಿತ ಏಜೆಂಟಿಕ್ ಸಾಮರ್ಥ್ಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕೃತವಾಗಿರುತ್ತವೆ.

ಇದರ ಜೊತೆಗೆ, ಆ ಏಜೆಂಟಿಕ್ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತಿದ್ದಂತೆ ಬಲವಾದ ಭದ್ರತಾ ರಕ್ಷಣಾ ಕ್ರಮಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ, ಮತ್ತು AI ಸಿಸ್ಟಮ್‌ಗಳು ಹೆಚ್ಚು ವಿಸ್ತಾರವಾದ ಹಾಗೂ ಸಂಕೀರ್ಣವಾದಂತೆ, ವಿಶೇಷವಾಗಿ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಲೇಯರ್‌ನಲ್ಲಿ, ಸ್ಕೇಲೆಬಲ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಅಗತ್ಯವಿರುತ್ತದೆ.

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂದರೇನು?

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಘಟಕಗಳು: ಹೋಸ್ಟ್‌ಗಳು, ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಸರ್ವರ್‌ಗಳು

ಹೋಸ್ಟ್

ಕ್ಲೈಂಟ್

ಸರ್ವರ್

MCP ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಡೇಟಾ ಲೇಯರ್ ಎಂದರೇನು?

MCP ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಲೇಯರ್ ಎಂದರೇನು?

MCP ಮಲ್ಟಿ-ಟೆನೆಂಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂದರೇನು?

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ರೇಖಾಚಿತ್ರ: ಹಂತ-ಹಂತದ ವಿವರಣೆ

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಸಾಂಪ್ರದಾಯಿಕ API ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಿಂತ ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ?

MCP ಆರ್ಕಿಟೆಕ್ಚರ್ ಸುರಕ್ಷಿತವೇ?

MCP ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಮುಂದಿನ ಹೆಜ್ಜೆ ಏನು?