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

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

🧰 धडा 03 — तीन primitives: tools, resources, prompts

📍 तुम्ही इथे आहात: 8 पैकी धडा 03 · मागे: lesson-02-architecture · पुढे: lesson-04-the-wire

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

धडे 01–02, आणि server देऊ शकतो अशा तीन प्रकारच्या गोष्टी — आणि प्रत्येक केव्हा वापरायची ते कोण ठरवते.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

उपकरण आपल्या देणग्या तीन लेबल लावलेल्या कप्प्यांवर जाहीर करते:

🧰 Tools — "विद्यार्थिनीसाठी मी ज्या गोष्टी करू शकतो." Inputs असलेल्या कृती: lookup_grade(student), query_db(sql), send_email(...). त्या केव्हा call करायच्या ते MODEL ठरवतो (host च्या परवानगीने — L02!). आजचे 90% servers याच कप्प्याने सुरुवात करतात, आणि आपला school server फक्त हाच कप्पा भरतो.
📁 Resources — "माझ्याकडून तुम्ही वाचू शकता अशा गोष्टी." पत्ते असलेला context: एक file, database मधील एक record, एक log. बाकावर काय जोडायचे ते HOST/APP ठरवते (AI कोर्स L08) — जसे वर्ग सुरू होण्यापूर्वी विद्यार्थिनीच्या बाकावर कोणती handouts ठेवायची ते शिक्षिका निवडते.
📜 Prompts — "मी सुचवतो त्या कृती-पद्धती." Server सोबत येणारे आधीच लिहिलेले prompt templates: "ticket चा सारांश असा करा". ते USER निवडतो (slash-commands, menu items) — जसे उपकरणाच्या निर्मात्याने डब्यात ठेवलेल्या worksheets.

प्रत्येकी एक निर्णय: model→tools, app→resources, user→prompts. हेच संपूर्ण वर्गीकरण — दोनदा म्हणा आणि servers बनवणाऱ्या बहुतेक लोकांपेक्षा तुम्हाला MCP जास्त कळेल. 😄

🗺️ आकृती

flowchart TB
    subgraph server["🔬 what a server offers"]
        tools["🧰 TOOLS - actions with inputs<br/>lookup_grade · add_homework"]
        res["📁 RESOURCES - readable context<br/>file://report.pdf · db://students/3A"]
        prompts["📜 PROMPTS - suggested recipes<br/>'/summarize-ticket'"]
    end
    m["🧠 model decides<br/>(host permitting)"]
    a["🏫 app decides<br/>what's on the desk"]
    u["🧑 user picks<br/>from a menu"]
    tools --- m
    res --- a
    prompts --- u

❓ काय

Tool = नाव + वर्णन + inputSchema (JSON Schema). वर्णन MODEL साठी असते — त्यावरूनच विद्यार्थिनीला कळते की उपकरण केव्हा वापरायचे. ते चांगल्या docstring सारखे लिहा; अस्पष्ट वर्णन = कधीच call न होणारे tools (किंवा त्याहून वाईट, चुकीचे call होणारे).
Resource = URI + content. Hosts बदलांसाठी subscribe करू शकतात. "कृती" नव्हे, "जोडता येणारा context" असा विचार करा.
Prompt = arguments असलेले नाव दिलेले template, messages मध्ये रूपांतरित होणारे. Team चे workflows एकसारखे करण्यासाठी त्याची किंमत कमी लेखली जाते.
Servers आपण कोणते कप्पे भरतो ते त्यांच्या capabilities मध्ये जाहीर करतात, ज्यांचे उत्तर server/discover देतो (धडा 04) — आपला server {"tools": {}} म्हणतो आणि बाकी काही नाही, जे प्रामाणिक आणि योग्य आहे.

कोण सुरू करतो, कोण वापरतो — तीन कप्प्यांसाठी एक तक्ता:

कप्पा	कोण सुरू करतो	कोण वापरतो	Wire verbs
🧰 tools	model सुचवतो (host च्या परवानगीने)	model — result → बाक	`tools/list`, `tools/call`
📁 resources	host/app जोडते	model — बाकावरचा context	`resources/list`, `resources/read`
📜 prompts	user निवडतो (menu, slash-command)	model / app	`prompts/list`, `prompts/get`

🤔 का

Teams सगळेच tools मध्ये कोंबून servers ची रचना चुकवतात ("read_file हा tool!" — कधी कधी बरोबर, पण context चे नियंत्रण APP कडे असायला हवे असेल, तर तो resource आहे). प्रत्येक कप्प्यासाठी कोण ठरवतो — model/app/user — हे जाणणे म्हणजे रचनेचा होकायंत्र. तो security चाही होकायंत्र आहे: tools कृती करतात, म्हणून tools ना guardrails मिळतात (L05); resources वाचतात, म्हणून त्यांची privacy review होते.

🧪 करून पाहा

python3 client/mini_client.py    # part 2 prints the tools shelf

तीन tool वर्णने मोठ्याने वाचा. मग कागदावर, आपल्या school server ची नीट भरलेली रचना करा: यांपैकी कोणते कोणत्या कप्प्यावर जाते? 3A चे grade report card (resource — app ते जोडते), "grades बद्दल पालकांना email लिहा" template (prompt — user ते निवडतो), add_homework (tool — model कृती करतो, host खात्री करतो). आता school_server.py ची TOOLS यादी तपासा — ती वाढवली तर resources/list म्हणून तुम्ही काय जोडाल? (धडा 06 तुम्हाला हे करून दाखवायचे आव्हान देतो.)

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

Scripted run चा भाग 2 त्यांच्या वर्णनांसह नेमके तीन tools दाखवतो; भाग 1 (server/discover) ने stocks: tools सांगितले — resources किंवा prompts नाहीत, server च्या capabilities शी जुळणारे.

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

कोण ठरवतो यावरून तुम्ही कोणत्याही क्षमतेचे वर्गीकरण करू शकता — model → tool, app → resource, user → prompt — आणि काहीही call करण्यापूर्वी server चे कप्पे त्याच्या capabilities वरून वाचू शकता.

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

सगळेच tool बनवणे — बाकावर काय जाते याचे नियंत्रण app कडे असायला हवे असेल, तर तो resource आहे
tool वर्णने माणसांसाठी लिहिणे — ती model वाचतो; अस्पष्ट वर्णन म्हणजे कधीच call न होणारे tools
capabilities हे वचन आहे हे विसरणे: tools जाहीर करून tools/list ला उत्तर न देणे प्रत्येक host ला मोडते

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: धारदार वर्णने आणि समृद्ध inputSchema (enums, required fields) असलेले servers बरोबर call होतात; model ला दिशा देण्याचा हा कोणत्याही prompt engineering पेक्षा स्वस्त मार्ग आहे. रचनेचा वेळ plumbing वर नव्हे, कप्प्यावर खर्च करा.

⏭️ पुढे

आता खरे bytes वाचायची वेळ: badge, discovery आणि calls — wire, एका sequence आकृतीच्या रूपात जी तुम्ही कायम ओळखाल.

git checkout lesson-04-the-wire

🧰 Lesson 03 — The three primitives: tools, resources, prompts

📍 You are here: Lesson 03 of 8 · Previous: lesson-02-architecture · Next: lesson-04-the-wire

📦 What's in this branch

Lessons 01–02, plus the three kinds of things a server can offer — and who gets to decide when each is used.

🧒 Explain like I'm 5

An instrument announces its offerings on three labeled shelves:

🧰 Tools — "things I can DO for the student." Actions with inputs: lookup_grade(student), query_db(sql), send_email(...). The MODEL decides when to call them (with the host's permission — L02!). This is the shelf 90% of today's servers lead with, and the only one our school server stocks.
📁 Resources — "things you may READ from me." Context with addresses: a file, a database record, a log. The HOST/APP decides what to attach to the desk (AI course L08) — like the teacher choosing which handouts go on the student's desk before class.
📜 Prompts — "recipes I suggest." Pre-written prompt templates the server ships: "summarize a ticket like THIS". The USER picks them (slash-commands, menu items) — like worksheets the instrument's manufacturer includes in the box.

One decision each: model→tools, app→resources, user→prompts. That's the whole taxonomy — say it twice and you know more MCP than most people shipping servers. 😄

🗺️ Diagram

flowchart TB
    subgraph server["🔬 what a server offers"]
        tools["🧰 TOOLS - actions with inputs<br/>lookup_grade · add_homework"]
        res["📁 RESOURCES - readable context<br/>file://report.pdf · db://students/3A"]
        prompts["📜 PROMPTS - suggested recipes<br/>'/summarize-ticket'"]
    end
    m["🧠 model decides<br/>(host permitting)"]
    a["🏫 app decides<br/>what's on the desk"]
    u["🧑 user picks<br/>from a menu"]
    tools --- m
    res --- a
    prompts --- u

❓ What

Tool = name + description + inputSchema (JSON Schema). The description is FOR THE MODEL — it's how the student knows when to reach for the instrument. Write it like a good docstring; vague descriptions = tools that never get called (or worse, get called wrong).
Resource = URI + content. Hosts can subscribe to changes. Think "attachable context", not "action".
Prompt = named template with arguments, rendered into messages. Underrated for standardizing team workflows.
Servers declare which shelves they stock in their capabilities, answered by server/discover (lesson 04) — our server says {"tools": {}} and nothing else, which is honest and fine.

Who initiates, who consumes — one table for the three shelves:

Shelf	Who initiates	Who consumes	Wire verbs
🧰 tools	the model proposes (host permitting)	the model — result → desk	`tools/list`, `tools/call`
📁 resources	the host/app attaches	the model — context on the desk	`resources/list`, `resources/read`
📜 prompts	the user picks (menu, slash-command)	the model / the app	`prompts/list`, `prompts/get`

🤔 Why

Teams misdesign servers by shoving everything into tools ("read_file as a tool!" — sometimes right, but if the APP should control context, it's a resource). Knowing WHO decides per shelf — model/app/user — is the design compass. It's also a security compass: tools act, so tools get the guardrails (L05); resources read, so they get the privacy review.

🧪 Try it

python3 client/mini_client.py    # part 2 prints the tools shelf

Read the three tool descriptions aloud. Then, on paper, redesign our school server properly stocked: which of these belong on which shelf? grade report card for 3A (resource — the app attaches it), "write a parent email about grades" template (prompt — the user picks it), add_homework (tool — the model acts, host confirms). Now check school_server.py's TOOLS list — what would you add as resources/list if you extended it? (Lesson 06 dares you to.)

✅ Verify — what you should see

Part 2 of the scripted run lists exactly three tools with their descriptions; part 1 (server/discover) reported stocks: tools — no resources or prompts, matching the server's capabilities.

🏁 What you just proved

You can classify any capability by who decides — model → tool, app → resource, user → prompt — and read a server's shelves from its capabilities before calling anything.

⚠️ Common mistakes

making everything a tool — if the app should control what goes on the desk, it is a resource
writing tool descriptions for humans — the model reads them; vague descriptions mean tools that never get called
forgetting that capabilities is a promise: declaring tools and not answering tools/list breaks every host

🏭 Why this matters in production: servers with sharp descriptions and rich inputSchema (enums, required fields) get called correctly; that is cheaper model-steering than any prompt engineering. Spend design time on the shelf, not the plumbing.

⏭️ Next

Time to read the actual bytes: the badge, discovery and calls — the wire, as a sequence diagram you'll recognize forever.

git checkout lesson-04-the-wire

← Previousarchitecture Next →the wire

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