If you have spent years maintaining business logic inside PHP applications, watching Model Context Protocol tutorials ca

ನೀವು ವರ್ಷಗಳ ಕಾಲ PHP ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, Model Context Protocol ಟ್ಯುಟೋರಿಯಲ್‌ಗಳನ್ನು ನೋಡುವುದು ಬೀಗ ಹಾಕಿದ ಬಾಗಿಲಿನ ಹೊರಗೆ ನಿಂತಿರುವಂತೆ ಅನಿಸಬಹುದು. ಬಹುತೇಕ ಎಲ್ಲಾ ಮಾರ್ಗದರ್ಶಿಗಳು TypeScript ಅಥವಾ Python ಅನ್ನು ಬಳಸುತ್ತವೆ ಎಂದು ಭಾವಿಸುತ್ತವೆ. ಅವು ಅಧಿಕೃತ SDKಗಳು, npm ಇನ್‌ಸ್ಟಾಲ್‌ಗಳು ಮತ್ತು pip ಪ್ಯಾಕೇಜ್‌ಗಳ ಬಗ್ಗೆ ವಿವರಿಸುತ್ತವೆ. ಇದರಿಂದಾಗಿ ಗ್ರಾಹಕರ ದಾಖಲೆಗಳು, ಆರ್ಡರ್ ಇತಿಹಾಸಗಳು, ಇನ್ವೆಂಟರಿ ಸಿಸ್ಟಮ್‌ಗಳಂತಹ ಅಪಾರ ಪ್ರಮಾಣದ ಬಿಸಿನೆಸ್ ಡೇಟಾ PHP ಕೋಡ್‌ಬೇಸ್‌ಗಳಲ್ಲಿ ಉಳಿದುಬಿಡುತ್ತದೆ, ಇದು ಪ್ರಸ್ತುತ AI ಟೂಲಿಂಗ್ ಅಲೆಗೆ ಅದೃಶ್ಯವಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಒಳ್ಳೆಯ ವಿಷಯವೆಂದರೆ MCP ಗೆ ಅಂತಹ SDKಗಳ ಅಗತ್ಯವಿಲ್ಲ. MCP ಎಂಬುದು ಒಂದು ಲೈಬ್ರರಿ ಅಲ್ಲ. ಅದು ಒಂದು ವೈರ್ ಪ್ರೊಟೊಕಾಲ (wire protocol). ನಿಮ್ಮ ರನ್‌ಟೈಮ್ (runtime) ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಇನ್‌ಪುಟ್‌ನಿಂದ ಒಂದು ಸಾಲಿನ ಪಠ್ಯವನ್ನು ಓದಬಲ್ಲದೆ, JSON ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಬಲ್ಲದೆ ಮತ್ತು ಮತ್ತೆ JSON ಅನ್ನು ಬರೆಯಬಲ್ಲದೆ, ಅದು ಈ ಪ್ರೊಟೊಕಾಲವನ್ನು ಬಳಸಬಹುದು. LLMಗಳು ಅಸ್ತಿತ್ವಕ್ಕೆ ಬರುವ ಮೊದಲೇ PHP ಇದನ್ನೇ ಮಾಡುತ್ತಾ ಬಂದಿದೆ.

MCP ಅಸಲಿಗೆ ಎಂದರೇನು

MCP ಎಂದರೆ Model Context Protocol. ಇದರ ಮೂಲತಃ, AI ಅಸಿಸ್ಟೆಂಟ್‌ಗಳನ್ನು ಡೇಟಾ, ಟೂಲ್ಸ್ ಮತ್ತು ಎಕ್ಸ್‌ಟರ್ನಲ್ APIಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು ಇದು ಒಂದು ಓಪನ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಆಗಿದೆ. ಪ್ರತಿಯೊಂದು ಅಸಿಸ್ಟೆಂಟ್ ಅಥವಾ ಮಾಡೆಲ್‌ಗಾಗಿ ಪ್ರತ್ಯೇಕ ಇಂಟಿಗ್ರೇಶನ್ ಮಾಡುವ ಬದಲು, ನೀವು ಒಂದೇ ಕಂಪ್ಲೈಯೆಂಟ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು. MCP ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಯಾವುದೇ ಕ್ಲೈಂಟ್, PHP, Laravel ಅಥವಾ ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾ ಬಗ್ಗೆ ಏನೂ ತಿಳಿಯದೆಯೇ ನಿಮ್ಮ ಸರ್ವರ್ ಜೊತೆ ಮಾತನಾಡಬಹುದು.

ಒಳಗಿನ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, MCP JSON-RPC 2.0 ಅನ್ನು ಬಳಸುತ್ತದೆ. ಅಂದರೆ ಪ್ರತಿಯೊಂದು ರಿಕ್ವೆಸ್ಟ್ (request) ಒಂದು ಸರಳ JSON ಆಬ್ಜೆಕ್ಟ್ ಆಗಿದ್ದು, ಅದರಲ್ಲಿ ಮೆಥಡ್ ಹೆಸರು, ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಮತ್ತು ಒಂದು ID ಇರುತ್ತದೆ. ಸರ್ವರ್ ಮತ್ತೊಂದು JSON ಆಬ್ಜೆಕ್ಟ್ ಮೂಲಕ ಫಲಿತಾಂಶ ಅಥವಾ ದೋಷವನ್ನು (error) ನೀಡುತ್ತದೆ.

ಒಂದು ಸರ್ವರ್ ಮೂರು ಪ್ರಿಮಿಟಿವ್‌ಗಳನ್ನು (primitives) ಎಕ್ಸ್‌ಪೋಸ್ ಮಾಡುತ್ತದೆ:

• Tools: ಮಾಡೆಲ್ ಬಳಸಬಹುದಾದ ಕ್ರಮಗಳು (Actions). ಒಂದು ಟೂಲ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕ್ವೆರಿ ಮಾಡಬಹುದು, ಸ್ಟೇಟಸ್ ಅಪ್‌ಡೇಟ್ ಮಾಡಬಹುದು ಅಥವಾ ಥರ್ಡ್-ಪಾರ್ಟಿ API ಅನ್ನು ಕರೆಯಬಹುದು.
• Resources: URI ಮೂಲಕ ಮಾಡೆಲ್ ಉಲ್ಲೇಖಿಸಬಹುದಾದ ಸ್ಟ್ಯಾಟಿಕ್ ಅಥವಾ ಸೆಮಿ-ಸ್ಟ್ಯಾಟಿಕ್ ಡೇಟಾ. ಫೈಲ್‌ಗಳು, ಕಾನ್ಫಿಗರೇಶನ್ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು ಅಥವಾ ರೆಫರೆನ್ಸ್ ಡೇಟಾಸೆಟ್‌ಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಿ.
• Prompts: ಬಳಕೆದಾರರು ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಸಹಾಯ ಮಾಡುವ ಮೊದಲೇ ನಿರ್ಧರಿಸಿದ ಟೆಂಪ್ಲೇಟ್‌ಗಳು.

ನೆನಪಿಡಬೇಕಾದ ಒಂದು ಪ್ರಮುಖ ನಿಯಂತ್ರಣ ವ್ಯತ್ಯಾಸವಿದೆ. Tools ಮಾಡೆಲ್‌ನ ನಿಯಂತ್ರಣದಲ್ಲಿರುತ್ತವೆ. ಅಸಿಸ್ಟೆಂಟ್ ಯಾವಾಗ ಅದನ್ನು ಕರೆಯಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. Resources ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿಯಂತ್ರಣದಲ್ಲಿರುತ್ತವೆ. ಯಾವ ಡೇಟಾ ಲಭ್ಯವಿದೆ ಎಂಬುದನ್ನು ಸರ್ವರ್ ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ಮಾಡೆಲ್ ಕೇವಲ ನೀಡಲಾದದ್ದನ್ನು ಓದುತ್ತದೆ. ಇದನ್ನು ಸರಿಯಾಗಿ ಮಾಡುವುದು ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಿರೀಕ್ಷಿತವಾಗಿರುವಂತೆ (predictable) ಇರಿಸುತ್ತದೆ. ಟೂಲ್ ಆಗಿರಬೇಕಾದ ವಿಷಯಕ್ಕಾಗಿ ಮಾಡೆಲ್ ರಿಸೋರ್ಸ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತಾ ಇರಬಾರದು ಅಥವಾ ಅದರ ವಿರುದ್ಧವಾಗಿಯೂ ಆಗಬಾರದು.

ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

MCP ಎರಡು ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ವಿಧಾನಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಆಯ್ಕೆಯು ನೀವು PHP ಭಾಗವನ್ನು ಹೇಗೆ ಬರೆಯುತ್ತೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

stdio ಅತ್ಯಂತ ಸರಳವಾಗಿದೆ. MCP ಕ್ಲೈಂಟ್ ನಿಮ್ಮ PHP ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಬ್‌ಪ್ರೊಸೆಸ್ (subprocess) ಆಗಿ ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ನಿಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಇನ್‌ಪುಟ್‌ಗೆ JSON-RPC ಸಂದೇಶಗಳನ್ನು ಬರೆಯುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಔಟ್‌ಪುಟ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಬರೆಯುತ್ತದೆ. ಇಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಯಾವುದೇ ಸಾಕೆಟ್‌ಗಳು (sockets), ತೆರೆಯಲು ಯಾವುದೇ ಪೋರ್ಟ್‌ಗಳು ಅಥವಾ ಪಾರ್ಸ್ ಮಾಡಲು ಯಾವುದೇ ಅಥೆಂಟಿಕೇಶನ್ ಹೆಡರ್‌ಗಳಿಲ್ಲ. ನಿಮ್ಮ ಟೂಲ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಒಂದೇ ಮಷೀನ್‌ನಲ್ಲಿ ಇದ್ದರೆ, ಇದು ಪ್ರಾರಂಭಿಸಲು ಸರಿಯಾದ ಸ್ಥಳವಾಗಿದೆ.

stdio ಮೂಲಕ ರನ್ ಮಾಡುವುದು ನಿಮ್ಮ PHP ಪ್ರಕ್ರಿಯೆಯ ಮೇಲೆ ಎರಡು ಕಟ್ಟುನಿಟ್ಟಿನ ನಿಯಮಗಳನ್ನು ಹೇರುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಎಂದಿಗೂ non-protocol ಡೇಟಾವನ್ನು stdout ಗೆ ಬರೆಯಬಾರದು. ನೀವು ಯಾವುದಾದರೂ ಡಿಬಗ್ ಸ್ಟೇಟ್‌ಮೆಂಟ್ ಅನ್ನು echo ಮಾಡಿದರೆ ಅಥವಾ PHP ನೋಟಿಸ್ ಸೋರಿಕೆಯಾದರೆ, ಅದು ಕ್ಲೈಂಟ್‌ನ ಪಾರ್ಸರ್ ಅನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ಎಲ್ಲಾ ಲಾಗಿಂಗ್ ಮತ್ತು ಡಯಾಗ್ನೋಸ್ಟಿಕ್ಸ್ ಅನ್ನು stderr ಗೆ ಕಳುಹಿಸಿ. ಎರಡನೆಯದಾಗಿ, ಔಟ್‌ಪುಟ್ ಬಫರಿಂಗ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ರದ್ದುಗೊಳಿಸಿ. PHP ជាពិសេស CGI ಅಥವಾ ವೆಬ್ ಸಂದರ್ಭಗಳಲ್ಲಿ stdout ಅನ್ನು ಬಫರ್ ಮಾಡಲು ಇಷ್ಟಪಡುತ್ತದೆ, ಆದರೆ CLI ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಕೂಡ ಡೇಟಾವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದು. ಪ್ರತಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತಕ್ಷಣವೇ ಫ್ಲಶ್ (flush) ಮಾಡಿ. ನೀವು ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, stream_set_write_buffer(STDOUT, 0) ಅನ್ನು ಸೆಟ್ ಮಾಡಿ ಅಥವಾ ಇಂಪ್ಲಿಸಿಟ್ ಬಫರಿಂಗ್ ಅನ್ನು ಆಫ್ ಮಾಡಿ, ಇದರಿಂದ ನೀವು ಕಳುಹಿಸಿದ ತಕ್ಷಣ ಕ್ಲೈಂಟ್‌ಗೆ ನ್ಯೂ ಲೈನ್ (newline) ಸಿಗುತ್ತದೆ.

Streamable HTTP ವಿಭಿನ್ನವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ PHP ಅಪ್ಲಿಕೇಶನ್ ಒಂದು ಪರ್ಸಿಸ್ಟೆಂಟ್ (persistent) HTTP ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆಗಿ ರನ್ ಆಗುತ್ತದೆ, ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ POST ರಿಕ್ವೆಸ್ಟ್‌ಗಳ ಮೂಲಕ ತಲುಪಬಹುದು. ಸರ್ವರ್ ಬೇರೆ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಇದ್ದಾಗ ಅಥವಾ ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ತಲುಪಬಹುದಾದ ಲಾಂಗ್-ರನ್ನಿಂಗ್ ಡಾಮನ್ (daemon) ಅನ್ನು ನೀವು ಬಯಸಿದಾಗ ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ. PHP ಯಲ್ಲಿ, ಇದರರ್ಥ ಸಾಂಪ್ರದಾಯಿಕ ರಿಕ್ವೆಸ್ಟ್-ರೆಸ್ಪಾನ್ಸ್ ಸೈಕಲ್ ಬದಲಿಗೆ RoadRunner, FrankenPHP ಅಥವಾ ಅಂತಹ ಪ್ರೊಸೆಸ್ ಮ್ಯಾನೇಜರ್ ಅಡಿಯಲ್ಲಿ ರನ್ ಮಾಡುವುದು.

PHP ಯಲ್ಲಿ ಇದನ್ನು ನಿರ್ಮಿಸುವುದು

ಪ್ರಾರಂಭಿಸಲು ನಿಮಗೆ ಯಾವುದೇ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅಗತ್ಯವಿಲ್ಲ. PHP ಯಲ್ಲಿ ಕನಿಷ್ಠ MCP ಸರ್ವರ್ ಎಂದರೆ STDIN ನಿಂದ ಓದುವ, JSON ಅನ್ನು ಡಿಕೋಡ್ ಮಾಡುವ, ಹ್ಯಾಂಡ್ಲರ್‌ಗೆ ಡಿಸ್ಪ್ಯಾಚ್ ಮಾಡುವ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಎನ್‌ಕೋಡ್ ಮಾಡುವ ಒಂದು ಲೂಪ್ ಆಗಿದೆ.

while ($line = fgets(STDIN)) {
    $request = json_decode($line, true);
    // route to tool or resource handler
    // write JSON-RPC response to STDOUT
}

ಆ ಲೂಪ್‌ನ ಒಳಗೆ, ಮಾಡೆಲ್‌ಗೆ ಅರ್ಥವಾಗುವಂತಹ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದೇ ನಿಜವಾದ ಕೆಲಸ.

ಕೋಡ್‌ನಿಂದ ಟೂಲ್ ಸ್ಕೀಮಾಗಳನ್ನು (tool schemas) ತಯಾರಿಸಿ. ನಿಮ್ಮ ಟೂಲ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳಿಗಾಗಿ JSON Schemas ಅನ್ನು ಕೈಯಾರೆ ಬರೆಯುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ನಿಮ್ಮ ವಾಸ್ತವ ವ್ಯಾಲಿಡೇಶನ್ ಲಾಜಿಕ್‌ನಿಂದ (validation logic) ಹೊರಗುಳಿಯುವಂತೆ ಬಿಡುವುದು ತೊಂದರೆ ಉಂಟುಮಾಡಲು ಅತ್ಯಂತ ವೇಗದ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. PHPು ಶ್ರೀಮಂತ ರಿಫ್ಲೆಕ್ಷನ್ (reflection) ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದೆ. ನಿಮ್ಮ ಮೆಥಡ್ ಸಿಗ್ನೇಚರ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಿಮ್ಮ ಫಾರ್ಮ್‌ಗಳು ಅಥವಾ ಕಮಾಂಡ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವ್ಯಾಲಿಡೇಶನ್ ನಿಯಮಗಳನ್ನು ಓದಿ ಮತ್ತು ಆ ನಿರ್ಬಂಧಗಳಿಂದ (constraints) ಸ್ಕೀಮಾವನ್ನು ತಯಾರಿಸಿ. ನಿಮ್ಮ ಆಂತರಿಕ ಕೋಡ್‌ಗೆ ಮಾನ್ಯವಾದ ಇಮೇಲ್ ಫಾರ್ಮ್ಯಾಟ್ ಅಗತ್ಯವಿದ್ದರೆ, ನಿಮ್ಮ MCP ಸ್ಕೀಮಾ ಕೂಡ ಅದನ್ನೇ ಹೇಳಬೇಕು. ವ್ಯಾಲಿಡೇಶನ್ ನಿಯಮಗಳು ಬದಲಾದಾಗ, ಸ್ಕೀಮಾ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಪ್‌ಡೇಟ್ ಆಗುತ್ತದೆ. ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ (No drift), ಯಾವುದೇ ಮೌನ ವೈಫಲ್ಯಗಳಿಲ್ಲ (no silent failures).

ಪ್ರೋಟೋಕಾಲ್ ದೋಷಗಳನ್ನು ಟೂಲ್ ದೋಷಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ. JSON-RPC ತನ್ನದೇ ಆದ ಎರರ್ ಸ್ಪೇಸ್ ಅನ್ನು ಹೊಂದಿದೆ. ದೋಷಪೂರಿತ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗಾಗಿ ಇದನ್ನು ಬಳಸಿ: ಮಲ್ಫಾರ್ಮ್ಡ್ JSON, ಅಜ್ಞಾತ ಮೆಥಡ್‌ಗಳು ಅಥವಾ ಕಾಣೆಯಾದ ರಿಕ್ವೆಸ್ಟ್ ಐಡಿಗಳು. ಒಂದು ಟೂಲ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದರೂ ವ್ಯವಹಾರದ ಸಮಸ್ಯೆಯನ್ನು (business problem) ಎದುರಿಸಿದಾಗ, ಪೇಲೋಡ್‌ನೊಳಗೆ (payload) ಎರರ್ ಫ್ಲಾಗ್‌ನೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಫಲಿತಾಂಶವನ್ನು ಹಿಂತಿರುಗಿಸಿ. ಗ್ರಾಹಕರನ್ನು ಹುಡುಕುವ ಟೂಲ್ ಯಾವುದೇ ಹೊಂದಿಕೆಯಾಗುವ ದಾಖಲೆಯನ್ನು ಕಂಡುಕೊಳ್ಳದಿದ್ದರೆ, ಅದು ಪ್ರೋಟೋಕಾಲ್ ಕ್ರ್ಯಾಶ್ ಅಲ್ಲ. {"found": false} ನಂತಹ ರಚನಾತ್ಮಕ ಫಲಿತಾಂಶವನ್ನು ಹಿಂತಿರುಗಿಸುವುದರಿಂದ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಮಾಡೆಲ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಮುಂದಿನ ಹಂತವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಅದು ವ್ಯಾಪಕವಾದ ಹುಡುಕಾಟವನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು ಅಥವಾ ಬಳಕೆದಾರರಿಂದ ಸ್ಪಷ್ಟೀಕರಣವನ್ನು ಕೇಳಬಹುದು. ಬದಲಾಗಿ ನೀವು JSON-RPC ಎರರ್ ಅನ್ನು ಎಸೆದರೆ, ಮಾಡೆಲ್ ಹೆಚ್ಚಾಗಿ ಸಂದರ್ಭವನ್ನು (context) ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

ದೀರ್ಘಾವಧಿಯ ಕೆಲಸಗಳಿಗಾಗಿ ಯೋಜಿಸಿ. PHP ಅನ್ನು ಅಲ್ಪಾವಧಿಯ ರಿಕ್ವೆಸ್ಟ್‌ಗಳಿಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ವೆಬ್ ರಿಕ್ವೆಸ್ಟ್ ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಟೈಮ್ ಔಟ್ ಆಗಬಹುದು ಮತ್ತು CLI ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಸಹ ಮೆಮೊರಿ ಅಥವಾ ತಾಳ್ಮೆಯನ್ನು ಖಾಲಿ ಮಾಡಬಹುದು. ಒಂದು ಟೂಲ್ ಮುಗಿಯಲು ನಿಮಿಷಗಳು ಬೇಕಾಗಿದ್ದರೆ—ಬಹುಶಃ ಅದು ದೊಡ್ಡ ವರದಿಯನ್ನು ಸಂಕಲಿಸುತ್ತದೆ ಅಥವಾ ಸಿಸ್ಟಮ್‌ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಸಿಂಕ್ ಮಾಡುತ್ತದೆ—ಮಾಡೆಲ್ ಅನ್ನು ಕಾಯುವಂತೆ ಮಾಡಬೇಡಿ. ತಕ್ಷಣವೇ ಜಾಬ್ ಐಡಂಟಿಫೈಯರ್ (job identifier) ಅನ್ನು ಹಿಂತಿರುಗಿಸಿ. ನಂತರ ಆ ಐಡಿ ಮೂಲಕ ಸ್ಥಿತಿಯನ್ನು (status) ಪರಿಶೀಲಿಸಲು ಎರಡನೇ ಟೂಲ್ ಅನ್ನು ಒದಗಿಸಿ. ನೀವು ಪ್ರಗತಿಯನ್ನು Redis, ಡೇಟಾಬೇಸ್ ಟೇಬಲ್ ಅಥವಾ ಪ್ರಮಾಣ ಕಡಿಮೆ ಇದ್ದರೆ ಫ್ಲಾಟ್ ಫೈಲ್‌ನಲ್ಲೇ ಸಂಗ್ರಹಿಸಬಹುದು. ಮಾಡೆಲ್ ಐಡಿಯನ್ನು ಪಡೆಯುತ್ತದೆ, ನಂತರ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಪೂರ್ಣಗೊಂಡ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತದೆ.

ಮಾಡೆಲ್ ಬಳಿ ಕೀಲಿಗಳು (Keys) ಇದ್ದಾಗ ಸುರಕ್ಷತೆ

AI ಮಾಡೆಲ್‌ಗೆ ಟೂಲ್ ಪ್ರವೇಶವನ್ನು ನೀಡುವುದು ಮಾನವ ಬಳಕೆದಾರರಿಗೆ ನೀಡುವುದರಂತಲ್ಲ. ಮಾಡೆಲ್ ಅಕ್ಷರಶಃ ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದು ವಿವರಣೆಗಳನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳಬಹುದು. ಪ್ರತಿಯೊಂದು ಎಕ್ಸ್‌ಪೋಸ್ ಮಾಡಲಾದ ಟೂಲ್ ಅನ್ನು ಪ್ರಿವિલેಜ್ ಎಸ್ಕಲೇಷನ್ ರಿಸ್ಕ್ (privilege escalation risk) ಎಂದು ಪರಿಗಣಿಸಿ.

ವ್ಯಾಪ್ತಿಯನ್ನು (scope) ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಮಿತಿಗೊಳಿಸಿ. ಎಂದಿಗೂ ಸಾಮಾನ್ಯ run_sql ಟೂಲ್ ಅನ್ನು ಎಕ್ಸ್‌ಪೋಸ್ ಮಾಡಬೇಡಿ. find_customer_by_email ಅಥವಾ update_order_status ನಂತಹ ನಿರ್ದಿಷ್ಟವಾದ, ಸೀಮಿತ ಟೂಲ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಿ. ನೀವು ಹೆಸರಿಸಿದ ಕೆಲಸವನ್ನು ಮಾತ್ರ, ನೀವು ವ್ಯಾಖ್ಯಾನಿಸಿದ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳೊಂದಿಗೆ ಮಾಡೆಲ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗಬೇಕು.

ರೀಡ್ (read) ಮತ್ತು ರೈಟ್ (write) ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ರೀಡ್-ಓನ್ಲಿ ಟೂಲ್‌ಗಳು ಕಡಿಮೆ ಅಪಾಯವನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಯಾವುದೇ ವಿನಾಶಕಾರಿ ಕ್ರಿಯೆಯನ್ನು (destructive action) ಸ್ಪಷ್ಟವಾದ ಕನ್ಫರ್ಮೇಶನ್ ಮೆಕ್ಯಾನಿಸಂ ಹಿಂದೆ ಇರಿಸಿ ಅಥವಾ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಎರಡನೇ ಸರ್ವರ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಬೆಂಬಲಿಸಿದರೆ, ರೈಟ್ ಟೂಲ್ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಮೊದಲು ಮಾನವ ಅನುಮೋದನೆಯ ಹಂತವನ್ನು ಅಗತ್ಯವಾಗಿಸಿ.

ಟೂಲ್ ವಿವರಣೆಗಳನ್ನು ಹೆಚ್ಚುವರಿ ಸೂಚನೆಗಳಂತೆ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಅವು ಸೂಚನೆಗಳೇ ಆಗಿವೆ. ಮಾಡೆಲ್ ಯಾವಾಗ ಟೂಲ್ ಅನ್ನು ಕರೆಯಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ ನಿಖರವಾಗಿರಿ. ಒಂದು ಟೂಲ್ ಬೆಲೆಯನ್ನು ಹುಡುಕಿದರೆ, ಹಾಗೆಯೇ ಹೇಳಿ. ಗ್ರಾಹಕರ ಐಡಿಯನ್ನು ಪರಿಶೀಲಿಸಿದ ನಂತರವಷ್ಟೇ ಅದನ್ನು ಬಳಸಬೇಕೆಂದರೆ, ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿಸಿ. ಅಸ್ಪಷ್ಟ ವಿವರಣೆಗಳು ಅಸ್ಪಷ್ಟ ವರ್ತನೆಗೆ ಕಾರಣವಾಗುತ್ತವೆ.

ನಿಮ್ಮ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ. ಇಡೀ Eloquent ಮಾಡೆಲ್ ಅಥವಾ Doctrine ಎಂಟಿಟಿಯನ್ನು ಸೀರಿಯಲೈಸ್ ಮಾಡಿ ಫಲಿತಾಂಶದಲ್ಲಿ ಹಾಕಬೇಡಿ. ಮಾಡೆಲ್‌ಗೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರುವ ಫೀಲ್ಡ್‌ಗಳನ್ನು ಮಾತ್ರ ಹಿಂತಿರುಗಿಸಿ. ಆಂತರಿಕ ಫೀಲ್ಡ್‌ಗಳು—ವೆಚ್ಚದ ಬೆಲೆಗಳು, ಉದ್ಯೋಗಿಗಳ ಟಿಪ್ಪಣಿಗಳು, ಆಂತರಿಕವಾಗಿರಬೇಕಾದ ಡೇಟಾಬೇಸ್ ಐಡಿಗಳು—ಹೊರಗಿನ ಲೋಕಕ್ಕೆ ಹೋಗಬಾರದು. ನಿಮ್ಮ ರಿಟರ್ನ್ ಶೇಪ್ (return shape) ಬಗ್ಗೆ ಸ್ಪಷ್ಟವಾಗಿರಿ.

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

ಎಲ್ಲಿಂದ ಪ್ರಾರಂಭಿಸಬೇಕು

ನಿಮ್ಮ PHP ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು AI ಅಸಿಸ್ಟೆಂಟ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಲು ನಿಮಗೆ SDK ನಿರ್ವಾಹಕರಿಂದ ಅನುಮತಿಯ ಅಗತ್ಯವಿಲ್ಲ. ನಿಮಗೆ JSON-RPC, ಒಂದು ಲೂಪ್ ಮತ್ತು stdout ಸುತ್ತ ಸ್ವಲ್ಪ ಶಿಸ್ತು ಬೇಕು.

ಮೊದಲ ದಿನವೇ ನಿಮ್ಮ ಇಡೀ API ಅನ್ನು MCP ಟೂಲ್‌ಗಳಾಗಿ ಮರುನಿರ್ಮಿಸುವ ಆಸೆಯನ್ನು ತಡೆಯಿರಿ. ನಿಮ್ಮ ಸಂಸ್ಥೆಯಲ್ಲಿ ಯಾರಾದರೂ ಪದೇ ಪದೇ ಕೇಳುವ ಮೂರು ರೀಡ್-ಓನ್ಲಿ ಆಪರೇಷನ್‌ಗಳನ್ನು ಆರಿಸಿ. ಬಹುಶಃ ಅದು ಆರ್ಡರ್ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದು, ಗ್ರಾಹಕರ ಸಾರಾಂಶವನ್ನು ಪಡೆಯುವುದು ಅಥವಾ ಇತ್ತೀಚಿನ ಇನ್‌ವಾಯ್ಸ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯುವುದಾಗಿರಬಹುದು. ಅವುಗಳನ್ನು ಟೂಲ್‌ಗಳಾಗಿ ಸುತ್ತಿ (wrap), ಅವುಗಳನ್ನು stdio ಮೂಲಕ ಒದಗಿಸಿ ಮತ್ತು ಒಬ್ಬ ಸಹೋದ್ಯೋಗಿಯನ್ನು ಅವುಗಳನ್ನು ಬಳಸಲು ಬಿಡಿ. ಮಾಡೆಲ್ ಏನನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಿ ಎಡವುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಮೂವತ್ತು ಟೂಲ್‌ಗಳನ್ನು ಯೋಜಿಸುವುದಕ್ಕಿಂತ ಆ ಮೂರು ಟೂಲ್‌ಗಳಿಂದ ನೀವು ಹೆಚ್ಚು ಕಲಿಯುವಿರಿ.

MCP ಎಂಬುದು ಒಂದು ಸೇತುವೆಯೇ ಹೊರತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬದಲಾವಣೆಯಲ್ಲ. ನಿಮ್ಮ PHP ಕೋಡ್ ಈಗಾಗಲೇ ನಿಮ್ಮ ವ್ಯವಹಾರವನ್ನು ತಿಳಿದಿದೆ. ಪ್ರೋಟೋಕಾಲ್ ಮಾಡೆಲ್ ಅನ್ನು ಅದರ ಮೇಲೆ ದಾಟಲು ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಅನುಮತಿಸುತ್ತದೆ ಅಷ್ಟೆ.