← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

या कोर्समधील प्रत्येक निवडीने कशाची तरी वाईट गोष्टीची जागा घेतली — आणि तीच निवड कुठेतरी चुकीचीही ठरते. प्रत्येकीसाठी: आधी आयुष्य कसे होते, प्रामाणिक गुण ✅ / दोष ❌, आणि कुठे वापरावी 👍 आणि कुठे नाही 👎.

🔌 MCP विरुद्ध हाताने जोडलेली tool integrations — धडे 01, 08

⏮️ MCP च्या आधी (2025 पूर्वी)

प्रत्येक AI app प्रत्येक tool हाताने जोडत असे: IDE साठी एक GitHub integration, chatbot साठी दुसरे, agent साठी तिसरे — N apps × M tools = N×M adapters, एकही पुन्हा वापरता येणारे नाही. एखादी क्षमता म्हणजे एका product च्या आतली खाजगी जोडणी होती, दुसऱ्याच्या हातात देता येईल असा भाग नव्हे.

✅ फायदे

  • उपकरण (server) एकदा लिहा → ते प्रत्येक MCP खोलीत (host) चालते (N+M)
  • जोडणीच्या वेळी model कपाट स्वतः शोधते: tool जोडायला redeploy लागत नाही
  • plug in करण्यासाठी तयार उपकरणांची वाढती यादी
  • तुमची integrations पुन्हा न जोडता AI app बदला

❌ तोटे

  • नवे standard: उपकरणांचा दर्जा खूप कमी-जास्त असतो
  • local उपकरण म्हणजे तुमच्या permissions सह install केलेले software (धोरण 1)
  • tool च्या निकालांमध्ये prompt injection असू शकते (धोरण 2)
  • paths, env vars आणि versions: local config चा त्रास खरा आहे

👍 वापरा जेव्हा

  • आज आणि उद्या अनेक tools लागणारा agent किंवा app
  • तुमची क्षमता अनेक AI apps मधून वापरता यायला हवी
  • अनेक assistants मध्ये अंतर्गत tools वाटून घेणारी team

👎 दोनदा विचार करा जेव्हा

  • एकाच app मध्ये एकच hard-coded tool — साधे function calling सोपे आहे
  • संवेदनशील मशीनवर अविश्वसनीय तृतीय-पक्ष servers
  • तुमच्या स्वतःच्या code मधून साधा REST call काम करतो — model ची गरज नाही

🧰📁📜 Tools विरुद्ध resources विरुद्ध prompts — धडे 03, 09

⏮️ तीन कपाटांच्या आधी

Model ला पोहोचता येणारी प्रत्येक गोष्ट 'एक function' होती. कागदपत्रे हाताने prompt मध्ये कोंबली जात, कृती (recipes) wiki पानांवर असत ज्या लोक paste करत, आणि कोण — model, app की वापरकर्ता — ठरवू शकतो हे सांगायचा मार्गच नव्हता. प्रत्येक integration ने ही विभागणी नव्याने शोधली.

✅ फायदे

  • tools: model स्वतःच्या निर्णयाने कृती करते (खोलीच्या परवानगीने)
  • resources: app जाणीवपूर्वक context जोडते — tool call नाही, धक्का नाही
  • prompts: वापरकर्ता तपासलेली कृती निवडतो — नेहमी चालणाऱ्या slash commands
  • प्रत्येक कपाटाची स्वतःची क्रियापदे आणि स्वतःचा निर्णय घेणारा असतो, म्हणून खोल्या योग्य UI बांधू शकतात

❌ तोटे

  • तीन कपाटे = design, document आणि test करायच्या तीन गोष्टी
  • अनेक खोल्या अजूनही फक्त tools दाखवतात; resources आणि prompts वापरलेच जाणार नाहीत असे होऊ शकते
  • model ला tool मधून वाचावा लागणारा resource हा design चा दोष आहे — तो resource च्या कपाटात ठेवा
  • prompts म्हणजे templates आहेत, जादू नाही: वाईट कृती सगळीकडे वाईटच

👍 वापरा जेव्हा

  • app ने नेहमी डेस्कवर ठेवावी अशी माहिती → resource
  • ज्याचे inputs model ने निवडावेत अशी कृती → tool
  • वापरकर्ते पुन्हा पुन्हा करतात असा workflow → prompt

👎 दोनदा विचार करा जेव्हा

  • सगळे काही tool आहे कारण ते सर्वात सोपे होते — मग model static files वाचायला tools call करते
  • दर सेकंदाला बदलणारा resource — तो खरे तर वेषांतर केलेला tool call आहे
  • दहा arguments लागणारा prompt — वापरकर्ते तो भरणार नाहीत

🪪 प्रत्येक request वर बिल्ला (2026-07-28) विरुद्ध handshake चा काळ (≤ 2025-11-25) — धडा 04

⏮️ आवृत्ती 2026-07-28 च्या आधी

प्रत्येक जोडणी एका विधीने सुरू होई: initialize → notifications/initialized, आणि उपकरण तुम्हाला लक्षात ठेवत असे — एक session, HTTP वर Mcp-Session-Id header, उपकरणाला तुम्हाला पाठवायच्या संदेशांसाठी एक GET stream. Load balancer मागच्या प्रत्येक instance ला तुमचे session माहीत असावे लागे, आणि उपकरण स्वतःच्या requests ने तुम्हाला मध्येच थांबवू शकत असे.

✅ फायदे

  • stateless: उपकरणाचा कोणताही instance कोणत्याही request ला उत्तर देऊ शकतो — प्रती वाढवून scale करा
  • handshake ची फेरी नाही; server/discover ही ऐच्छिक ओळख आहे
  • एक error (-32022) भिंतीतील सॉकेटला नेमके सांगते की उपकरण कोणत्या आवृत्त्या बोलते
  • उपकरणाचे प्रश्न निकालांच्या आतून प्रवास करतात (input_required) — उघडा ठेवायला back-channel नाही

❌ तोटे

  • प्रत्येक request बिल्ला पुन्हा दाखवते: दर वेळी काहीशे bytes
  • जुनी भिंतीतील सॉकेट्स फक्त-आधुनिक उपकरणाशी बोलू शकत नाहीत (त्यांच्याकडे fall-forward नाही)
  • दोन्ही काळांतील उपकरणांना दोन्ही जगे implement करावी लागतात
  • subscriptions आपोआप मिळण्याऐवजी त्यांना स्पष्टपणे दीर्घकाळ चालणारा stream लागतो

👍 वापरा जेव्हा

  • नवे काहीही: आधुनिक आवृत्ती हीच सध्याची आहे
  • load balancers मागची remote उपकरणे — stateless असणे हाच मुद्दा आहे

👎 दोनदा विचार करा जेव्हा

  • तुम्हाला जुन्या भिंतीतील सॉकेट्सना सेवा द्यावीच लागते — मग जुना handshake सुद्धा implement करा, जाणीवपूर्वक
  • calls मध्ये state ठेवायला session असते असे तुम्ही गृहीत धरले — त्याऐवजी स्पष्ट handle परत द्या

🔌 stdio विरुद्ध 📡 Streamable HTTP — धडे 05, 11

⏮️ दोन transports च्या आधी

सुरुवातीची tool उपकरणे खास हाताने बनवलेली होती: import करायचे एक Python module, स्वतःचे auth असलेले REST API, एखादी shell script. Local काहीही remote वापरता येत नसे आणि remote काहीही offline चालत नसे. MCP ने सारखेच संदेश वाहून नेणाऱ्या दोन जोडण्यांवर निर्णय घेतला: तुमच्या machine वरची child process, किंवा कुठेही असलेले एक HTTP दार (endpoint).

✅ फायदे

  • stdio: network नाही, auth नाही, रचनेनेच खाजगी; process चे आयुष्य खोली नियंत्रित करते
  • stdio: milliseconds मध्ये सुरू होते; files, git आणि laptop apps साठी अगदी योग्य
  • Streamable HTTP: अनेक खोल्या आणि वापरकर्त्यांसाठी एक उपकरण; कोणत्याही web service सारखे scale होते
  • Streamable HTTP: प्रत्येक request ला खरी ओळख (Bearer tokens), routers साठी प्रतिबिंबित headers

❌ तोटे

  • stdio: ते तुमच्या permissions सह install केलेले software च आहे; secrets environment मधून येतात
  • stdio: प्रत्येक process ला एक खोली — वाटून घेणे म्हणजे प्रती चालवणे
  • HTTP: authorization हे खरेखुरे engineering आहे (OAuth 2.1, PKCE, audience, scopes)
  • HTTP: Origin validation आणि localhost binding तुमच्यावर आहे — DNS rebinding हा खरा हल्ला आहे

👍 वापरा जेव्हा

  • stdio: तुमच्या स्वतःच्या machine वरच्या files, tools आणि dev workflow — आणि हा कोर्स
  • HTTP: team चा database, एखादे SaaS integration, अनेक खोल्या वाटून घेतात असे काहीही

👎 दोनदा विचार करा जेव्हा

  • अनेक लोकांना एकाच वेळी लागणाऱ्या गोष्टीसाठी stdio — तुम्ही वीस प्रती चालवाल
  • auth शिवाय 0.0.0.0 वर HTTP 'कारण ते अंतर्गत आहे' — ते तसे नाही

🙋 उलट विचारणे (input_required) विरुद्ध प्रत्येक argument आधीच मागणे — धडा 10

⏮️ अनेक फेऱ्यांच्या आधी

Tool कडे एकतर लागणारे सगळे असे, नाहीतर ते अपयशी ठरे. वापरकर्त्याला काही विचारायचे असलेली उपकरणे back-channel उघडून स्वतःच्या requests पाठवत (sampling, elicitation) — म्हणजे जिवंत जोडणी, उपकरणाच्या बाजूला state, आणि कोणत्याही क्षणी उत्तर द्यायला तयार असावी लागणारी खोली.

✅ फायदे

  • tool ला नेमका जो प्रश्न हवा तो, हवा तेव्हाच विचारते — कमी अपयशी calls
  • stateless: requestState retry सोबत प्रवास करते; कोणताही instance काम पूर्ण करू शकतो
  • खोली नियंत्रणात राहते: ती form दाखवते, वापरकर्ता नकार देऊ शकतो किंवा रद्द करू शकतो
  • form mode रचनाबद्ध आहे (schema, enums, defaults) — parse करायचा मोकळा मजकूर नाही

❌ तोटे

  • एक प्रश्न = एक जादा फेरी; अनेक प्रश्नांना अनेक फेऱ्या लागतात
  • उपकरणाने requestState वर सही करून ती तपासलीच पाहिजे — छेडछाड ही हल्लेखोराची पहिली चाल असते
  • elicitation क्षमता नसलेली खोली हाताळावीच लागते: ती उत्तर देऊ शकत नाही असे कधीही विचारू नका
  • form mode ने कधीही secrets गोळा करू नयेत — त्यासाठी URL mode आणि browser लागतो

👍 वापरा जेव्हा

  • असे write tool जिथे एक तपशील खरोखर वापरकर्त्याची निवड आहे (कोणता वर्ग? कोणते folder?)
  • रचनाबद्ध पर्यायांसह ऐच्छिक पुष्टी

👎 दोनदा विचार करा जेव्हा

  • model context मधून argument देऊ शकले असते — त्याऐवजी ते schema मध्ये ठेवा
  • प्रश्न म्हणजे password किंवा API key आहे — URL mode वापरा
  • प्रश्नांची साखळी — tool ची पुनर्रचना करून छोटी tools बनवा

🚧 प्रत्येक write ला फाटक विरुद्ध मोकळे वाहू देणे — धडे 05, 08, 11

⏮️ write फाटकांच्या आधी

Automation एकतर काहीच करू शकत नसे (फक्त बोलणारे chatbots) किंवा लगेच कृती करत असे (operator च्या पूर्ण permissions असलेल्या scripts). पहिले निरुपयोगी होते, दुसरे एका विषारी input मुळे table उडण्याच्या अंतरावर होते. मधली पातळीच नव्हती.

✅ फायदे

  • reads वाहतात, writes click ची वाट पाहतात: model सुचवते, माणूस ठरवतो (धोरण 3)
  • descriptions आणि readOnlyHint मुळे खोल्या फाटक आपोआप बांधू शकतात
  • scoped tokens फाटकाचे धोरणात रूपांतर करतात: read token ला write tools दिसतही नाहीत (धडा 11)
  • incident review मध्ये 'फाटक टिकले' असे वाचायला मिळते, 'आमच्याकडे फाटकच नव्हते' असे नाही

❌ तोटे

  • त्रास: खूप जास्त विचारणा झाल्या की लोक 'always allow' click करतात — फाटक विरून जाते
  • फाटक खोलीच्या बाजूला असते: निष्काळजी खोली ते पूर्ण वगळू शकते
  • reads मधूनही गळती होऊ शकते (fetch tool मार्फत exfiltration) — फाटके म्हणजे संपूर्ण गोष्ट नव्हे
  • annotations म्हणजे उपकरणाकडून आलेले इशारे: खोलीने त्यांना अविश्वसनीय मानलेच पाहिजे

👍 वापरा जेव्हा

  • जग बदलणारे काहीही: send, post, delete, pay, deploy
  • अविश्वसनीय मजकूर model पर्यंत पोहोचू शकतो (tickets, web pages, email)

👎 दोनदा विचार करा जेव्हा

  • निव्वळ reads ना फाटक लावणे — तुम्ही वापरकर्त्यांना आपोआप मंजुरी द्यायची सवय लावता
  • least privilege ऐवजी फाटकावर अवलंबून राहणे — account चा scope सुद्धा मर्यादित करा