🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🌍 धडा 08 — पाच खऱ्या जगातील use cases (sequence आकृत्यांसह)

📍 तुम्ही इथे आहात: 8 पैकी धडा 08 — शेवटचा धडा!

📦 या ब्रँचमध्ये काय आहे

संपूर्ण कोर्स, आणि त्याचे फळ: production सारख्या पाच रचना. Site वर प्रत्येक दोनदा काढलेली आहे — एक क्रमांकित flow आकृती आणि एक पायरी-पायरीची sequence आकृती: 🌐 सचित्र use-cases पान ← हा धडा वाचताना ते शेजारी उघडा.

🧒 पाच रचना, शाळेच्या शब्दांत

1. 🐙 Coding assistant (IDE + GitHub server + filesystem server) "Issue #42 दुरुस्त कर." विद्यार्थिनी तक्रार वाचते (get_issue), code वाचते (read_file), दुरुस्ती लिहिते, tests चालवते (run_tests), PR चा मसुदा बनवते — create_pr तुमच्या click ची वाट पाहतो (L05 धोरण 3). MCP का: तोच GitHub server प्रत्येक IDE आणि agent मध्ये चालतो — एकदा लिहा, सगळीकडे जोडा.

2. 🎧 Support desk (support app + orders-DB server + docs server) ग्राहक: "माझा refund कुठे आहे?" → order शोधा (read-only!), refund policy आणा → पुराव्यांसह आधारलेले उत्तर — RAG ची खुल्या पुस्तकाची परीक्षा (AI कोर्स L10) MCP plugs घालून. DB tool मर्यादित account द्वारे फक्त SELECT करतो (AWS कोर्स L03 चा least privilege, शब्दशः).

3. 📊 Data analyst (chat app + SQL server + chart server) "मागच्या महिन्यात प्रत्येक region मध्ये कोणते product सर्वात जास्त विकले गेले?" → query_db → make_chart → चित्रासह आकडे. Schema ची enum/read-only रचना (L06) हीच "analyst" ला "DROP TABLE" बनण्यापासून रोखते. 😅

4. 📅 Meeting-prep butler (assistant + calendar + CRM + email) "3 pm च्या बैठकीसाठी माझी तयारी कर" → get_event → crm_lookup(company) → recent_threads(attendees) → एक नीटनेटका brief. तीन servers, एक खोली, एक बाक — एकाच request मध्ये N+M चे फळ.

5. 📁 Report robot (agent + filesystem + Slack server) "या folder मधील साप्ताहिक reports चा सारांश करून #team वर post कर" → list_dir → read_file ×N → summarize → slack_post तुमच्या click ची वाट पाहतो — पुन्हा write-gate, कारण फाटकाशिवायचे automation म्हणजे L05 चा incident report.

🗺️ आकृती (use case 1, सगळ्यांचा आकार)

sequenceDiagram
    participant U as 🧑 user
    participant H as 🏫 IDE host
    participant M as 🧠 model
    participant G as 🐙 GitHub server
    participant F as 📁 files server
    U->>H: 1 "fix issue #42"
    H->>M: 2 goal + tool shelves
    M->>G: 3 get_issue(42) — via host
    G-->>M: 4 the bug report → desk
    M->>F: 5 read_file(buggy.py)
    F-->>M: 6 code → desk
    M->>H: 7 proposes create_pr(fix)
    H->>U: 8 🚧 "allow PR?" — the human gate
    U->>H: 9 click ✓ → PR exists

❓ पाचही मध्ये सामायिक काय (पुन्हा वापरायची यादी)

Reads वाहतात, writes ना फाटक — प्रत्येक case जग बदलणारे tools चिन्हांकित करते, आणि त्यांना click मिळतो (L05).
Least-privilege plumbing — मर्यादित DB accounts, फक्त-repo tokens (AWS कोर्सच्या IAM प्रवृत्ती, आता AI साठी).
तेच servers, अनेक खोल्या — या कथांमधील प्रत्येक server अनेक apps मध्ये पुन्हा वापरता येतो; teams त्रास घेतात ते यासाठीच (L01 चे N+M).
बाक मर्यादा समजावतो — प्रचंड folders / अवाढव्य queries context मर्यादांवर आदळतात (AI कोर्स L08); production आवृत्त्या server बाजूला pagination आणि सारांश जोडतात.
सगळे सहा messages च आहेत — वरचा प्रत्येक क्रम म्हणजे L04 चे badge-discover-call, पुन्हा पुन्हा. एक wire वाचा, सगळे वाचले.

तीन धोरणे, पुन्हा (L05 — क्रमांक पाठ करा): 1 local server त्या process च्या परवानग्यांनी चालतो (remote server ची स्वतःची ओळख असते); 2 tool results म्हणजे data, कधीच आज्ञा नव्हे; 3 writes ना माणसाचे फाटक. प्रत्येक case मध्ये फाटक कुठे आहे:

Case	Reads (वाहतात)	Writes (फाटक)
🐙 coding assistant	get_issue, read_file, run_tests	`create_pr` → IDE मधील click
🎧 support desk	order lookup (फक्त-SELECT account), policy docs	आज काही नाही — `refund_issue` tool ला फाटक लागेल
📊 data analyst	query_db (फक्त-SELECT), make_chart	काही नाही — कोणत्याही write tool ला, किंवा मर्यादित नसलेल्या account ला, click लागेल
📅 meeting-prep butler	get_event, crm_lookup, recent_threads	काही नाही — "follow-up पाठव" जोडले त्या क्षणी email server च्या send tool ला click मिळतो
📁 report robot	list_dir, read_file ×N	`slack_post` → "post to #team?" पूर्ण दाखवलेले

⛔ Anti-pattern: write करू शकणारा database tool (INSERT/UPDATE/DELETE — किंवा तसे करू शकणारे DB account) host बाजूच्या खात्रीशिवाय model च्या हाती देणे. आणलेल्या ticket मधील एक घुसवलेले वाक्य (धोरण 2) म्हणजे dropped table (धोरण 3 वगळले). Account मर्यादित करा, tool ला लेबल लावा, write ला फाटक लावा.

🧪 करून पाहा — तुमचा सहावा use case

तुमच्या आठवड्यातील एक खरा workflow निवडा (expense report? standup notes? ticket triage?). कागदावर: कोणते servers (अस्तित्वात असलेले किंवा बांधायचे)? प्रत्येक server वर कोणते tools — आणि त्यांपैकी writes कोणते (फाटक!)? वरच्या शैलीत, क्रमांकांसह sequence आकृती काढा. तुम्ही ती काढू शकलात, तर बांधूही शकता — L06 आणि L07 हेच संपूर्ण साहित्य होते.

✅ तपासा — तुम्हाला काय दिसायला हवे

तुमच्या सहाव्या use case साठी तुम्ही प्रत्येक server वर कोणते tools read करतात आणि कोणते write करतात ते सांगू शकता — आणि प्रत्येक write ला नाव असलेले फाटक आहे (एक click, एक policy, एक मर्यादित account). एखाद्या write ला फाटक नसेल, तर रचना पूर्ण झालेली नाही.

🏁 तुम्ही आत्ताच काय सिद्ध केले

तुम्ही कोणतेही MCP deployment धडा 04 चे सहा messages आणि धडा 05 ची तीन धोरणे म्हणून वाचू शकता — आणि code लिहिण्यापूर्वी कागदावर त्याची रचना करू शकता.

⚠️ नेहमीच्या चुका

host बाजूच्या खात्रीशिवाय write करू शकणारा DB tool (किंवा write करू शकणारे DB account) — ठरलेला anti-pattern
reads लाही फाटक लावणे — त्रासामुळे लोक "always allow" toggle करतात, आणि तुम्हाला खरोखर हवे असलेले फाटकच निघून जाते
सगळ्यासाठी एकच अवाढव्य server — servers हेच पुनर्वापराचे आणि परवानगीचे एकक आहेत; ते अरुंद ठेवा

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: पाचही cases चा आकार एकच आहे: reads वाहतात, writes ना फाटक, least-privilege plumbing, अनेक खोल्यांमध्ये तेच servers. Tools नव्हे, आकार copy करा.

🎓 Socket आता तुमचे आहे

ड्रॉवरची समस्या → तीन भूमिका → तीन कप्पे → wire वरील सहा messages → विश्वासाची तीन धोरणे → खरा server → खरा host → पाच खरी deployments. तुम्ही फक्त MCP शिकला नाहीत — त्याचे चालणारे implementation आता तुमच्या मालकीचे आहे. 🔌🎓

git checkout main
python3 client/mini_client.py --drive    # one last spin, for fun

🌍 Lesson 08 — Five real-world use cases (with sequence diagrams)

📍 You are here: Lesson 08 of 8 — the final lesson!

📦 What's in this branch

The complete course, plus the payoff: five production-shaped setups. Each is drawn twice on the site — a numbered flow diagram AND a step-by-step sequence diagram: 🌐 the illustrated use-cases page ← open it beside this lesson.

🧒 The five, in school words

1. 🐙 The coding assistant (IDE + GitHub server + filesystem server) "Fix issue #42." The student reads the complaint (get_issue), reads the code (read_file), writes a fix, runs the tests (run_tests), drafts the PR — create_pr waits for your click (L05 policy 3). Why MCP: the same GitHub server works in every IDE and agent — write once, plug everywhere.

2. 🎧 The support desk (support app + orders-DB server + docs server) Customer: "where's my refund?" → look up the order (read-only!), fetch the refund policy → grounded answer with receipts — RAG's open-book exam (AI course L10) wearing MCP plugs. The DB tool is SELECT-only via a scoped account (AWS course L03's least privilege, verbatim).

3. 📊 The data analyst (chat app + SQL server + chart server) "Which product sold best last month, per region?" → query_db → make_chart → numbers with a picture. The schema's enum/read-only design (L06) is what keeps "analyst" from becoming "DROP TABLE". 😅

4. 📅 The meeting-prep butler (assistant + calendar + CRM + email) "Prep me for the 3 pm" → get_event → crm_lookup(company) → recent_threads(attendees) → one tidy brief. THREE servers, one room, one desk — the N+M payoff in a single request.

5. 📁 The report robot (agent + filesystem + Slack server) "Summarize this folder's weekly reports and post to #team" → list_dir → read_file ×N → summarize → slack_post waits for your click — the write-gate again, because automation without gates is L05's incident report.

🗺️ Diagram (use case 1, the shape of them all)

sequenceDiagram
    participant U as 🧑 user
    participant H as 🏫 IDE host
    participant M as 🧠 model
    participant G as 🐙 GitHub server
    participant F as 📁 files server
    U->>H: 1 "fix issue #42"
    H->>M: 2 goal + tool shelves
    M->>G: 3 get_issue(42) — via host
    G-->>M: 4 the bug report → desk
    M->>F: 5 read_file(buggy.py)
    F-->>M: 6 code → desk
    M->>H: 7 proposes create_pr(fix)
    H->>U: 8 🚧 "allow PR?" — the human gate
    U->>H: 9 click ✓ → PR exists

❓ What the five have in common (the checklist you'll reuse)

Reads flow, writes gate — every case marks which tools change the world, and those get the click (L05).
Least-privilege plumbing — scoped DB accounts, repo-only tokens (the AWS course's IAM instincts, now for AI).
Same servers, many rooms — each server in these stories is reusable across apps; that's WHY teams bother (L01's N+M).
The desk explains the limits — huge folders / giant queries hit context limits (AI course L08); production versions add pagination and summaries server-side.
It's all six messages — every sequence above is L04's badge-discover-call, repeated. Read one wire, read them all.

The three policies, again (L05 — memorise the numbers): 1 a local server runs with that process's permissions (a remote one has its own identity); 2 tool results are data, never commands; 3 writes get a human gate. Where the gate sits in each case:

Case	Reads (flow)	Writes (gate)
🐙 coding assistant	get_issue, read_file, run_tests	`create_pr` → the click in the IDE
🎧 support desk	order lookup (SELECT-only account), policy docs	none today — a `refund_issue` tool would need one
📊 data analyst	query_db (SELECT-only), make_chart	none — any write tool, or a non-scoped account, would need the click
📅 meeting-prep butler	get_event, crm_lookup, recent_threads	none — the moment "send the follow-up" is added, the email server's send tool gets the click
📁 report robot	list_dir, read_file ×N	`slack_post` → "post to #team?" shown in full

⛔ The anti-pattern: a write-capable database tool (INSERT/UPDATE/DELETE — or a DB account that can) handed to the model with no host-side confirmation. One injected sentence in a fetched ticket (policy 2) becomes a dropped table (policy 3 skipped). Scope the account, label the tool, gate the write.

🧪 Try it — your sixth use case

Pick a REAL workflow from your week (expense report? standup notes? ticket triage?). On paper: which servers (existing or to-build)? which tools per server — and which are writes (gates!)? Draw the sequence diagram in the style above, numbered. If you can draw it, you can build it — L06 and L07 were the whole toolkit.

✅ Verify — what you should see

For your sixth use case you can list, per server, which tools read and which write — and every write has a named gate (a click, a policy, a scoped account). If a write has no gate, the design is not done.

🏁 What you just proved

You can read any MCP deployment as lesson 04's six messages plus lesson 05's three policies — and design one on paper before writing code.

⚠️ Common mistakes

a write-capable DB tool (or a DB account that can write) with no host-side confirmation — the canonical anti-pattern
gating reads too — friction makes people toggle "always allow", which removes the gate you actually needed
one giant server for everything — servers are the unit of reuse and of permission; keep them narrow

🏭 Why this matters in production: the five cases share one shape: reads flow, writes gate, least-privilege plumbing, same servers in many rooms. Copy the shape, not the tools.

🎓 The socket is yours

The drawer problem → the three roles → the three shelves → six wire messages → the three trust policies → a real server → a real host → five real deployments. You didn't just learn MCP — you own a working implementation of it. 🔌🎓

git checkout main
python3 client/mini_client.py --drive    # one last spin, for fun

← Previousbuild a client Finished! Take the quiz →check what stuck

This page is the lesson's README from the lesson-08-use-cases branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.