MCP — Model Context Protocol interview questions & answers

Ek electrician ko socho jo har baar ek naya appliance aane par uske liye bilkul naya socket wire karta hai -- toaster ke liye ek shape, lamp ke liye alag shape, fridge ke liye teesri shape. Har appliance banane wali company apna khud ka plug banati hai, isliye har wall me us ek appliance ke liye ek khaas socket carve karna padta hai. Ab ek doosra electrician le aao (ek doosra ghar) aur poora kaam zero se dobara hota hai, wire by wire, aise kaam ke liye jo pichle hafte khatam hue kaam se functionally identical hai.

Production me, ye baar-baar rewiring wahi cheez hai jise engineers M×N problem kehte hain. Maan lo aapke paas teen AI applications hain -- ek customer-support chatbot, ek internal Slack bot, aur ek mobile app -- aur inme se har ek ko ek get_weather tool chahiye. MCP se pehle, get_weather teen alag baar likha jaata hai: ek baar chatbot ke apne SDK-specific tool format me registered function ki tarah, ek baar Slack-bot ke handler ki tarah jo us bot ke particular event loop me wired hai, ek baar mobile backend endpoint ki tarah jise ek aur alag client library se call kiya jaata hai. Tool ka asli logic -- weather API call karo, response parse karo, summary return karo -- teenon baar identical hai. Sirf wiring alag hai: teen alag formats, teen alag jagah jahaan code rehta hai, teen jagah jahaan ek bug ek jagah fix hoke baaki do jagah reh jaata hai. Ab ek doosra tool send_email aur ek chautha application add karo. Teen tools cross four applications matlab barah integrations, har ek hand-written, har ek hamesha ke liye alag maintain hota hua. Yehi hai M applications times N tools: M×N integrations, aur ye number kisi bhi side ke badhne par better nahi, worse hota jaata hai.

MCP ka jawab ye hai ki har pair ke liye wiring likhna band karo, aur har side ke liye ek baar likho. Weather tool ko ek MCP server ki tarah banao, aur wo khud ko ek single standard protocol ke through expose karta hai. Jis bhi application ko wo chahiye, use ab sirf wo ek protocol bolna hai -- ek baar -- taaki wo protocol bolne wale har server tak pahunch sake. M applications me se har ek client side ek baar implement karta hai, N tools me se har ek server side ek baar implement karta hai: M+N, M×N nahi. Barah hand-wired integrations teen servers plus chaar clients ban jaate hain, aur agle mahine aane wali paanchvi application sirf ek client add karti hai, chaar naye integrations nahi.

Official MCP documentation isko apni khud ki analogy se describe karti hai, aur ye use karna worth hai kyunki ye wahi standard framing hai jo har learner ko dobara milegi: MCP AI applications ke liye USB-C jaisa hai. USB-C se pehle, har device ko apna khud ka cable shape chahiye hota tha -- charging ke liye ek, monitor ke liye ek, storage drive ke liye ek -- aur har manufacturer apne hardware ke liye wahi wiring problem dobara duplicate karta tha. USB-C ne devices ko smart nahi banaya; usne har device aur har accessory ko ek connector diya jise sab bolne par agree ho sakte the, isliye teen alag companies ka laptop, phone aur monitor bina cable ka shape dobara negotiate kiye usi port me plug ho jaate hain. MCP software ke liye wahi kaam karta hai: ye kisi model ko smart nahi banata, ye har AI application aur har tool ko ek protocol deta hai jo sab bolne par agree ho sakte hain.

MCP ko kaun govern karta hai ye khud bhi precisely bolne wali baat hai, kyunki ye galat bolna MCP ki origin ke baare me sabse common interview mistake hai. Anthropic ne MCP ko Agentic AI Foundation ko donate kiya -- ek Linux Foundation directed fund jise Anthropic, Block aur OpenAI ne mil kar co-found kiya -- ye 2025-12-09 ko announce hua. MCP ki specification ab kisi ek company ka product nahi hai; ise us foundation dwara govern kiya jaata hai, aur uska ecosystem support already Claude, ChatGPT, VS Code aur Cursor tak phaila hua hai. Founding date guess karne ki jagah yahi fact use karo: ye dated hai, verifiable hai, aur seedha "MCP sirf Anthropic ki cheez hai" wali misconception ko khatam kar deta hai.

MCP kya NAHI hai, kyunki inme se har ek ek real misconception hai jo learner ko interview me milegi:

• Model nahi hai. MCP me koi weights nahi hote, ye koi inference nahi karta, aur koi text generate nahi karta. Model wahi LLM hai jise host application already use kar rahi hai; MCP sirf ye badalta hai ki us model ka chuna hua tool kaise reach hota hai.
• Agent framework nahi hai. MCP ye decide nahi karta ki kaunsa tool call karna hai, multi-step tasks plan nahi karta, aur koi loop own nahi karta. Wo decision ab bhi ordinary function calling hai, jo model host application ke andar leta hai -- MCP sirf ye standardise karta hai ki model ne jo tool choose kiya wo actually kahan rehta hai.
• Aapke API ka replacement nahi hai. Agar aapke paas already ek REST ya GraphQL API hai, toh MCP use delete nahi karta ya usse compete nahi karta. Ek MCP server typically ek thin layer hoti hai jo tool ke behalf par aapke existing API ko call karti hai -- aapka API har non-AI client ko bilkul pehle jaisa serve karta rehta hai, aur MCP server sirf ek aur, AI-shaped, tarika hai use tak pahunchne ka.

🌍 Real-world example: ek company ki internal ticketing API already uske web dashboard aur mobile app ko serve karti hai. Jab company chahti hai ki ek AI assistant "ek ticket open kar sake," toh wo ticketing API dobara nahi likhti -- wo existing create_ticket endpoint ko ek MCP server me wrap kar deti hai. Ab wo single server company ke internal AI assistant se reach ho sakta hai, aur mahino baad, ek partner ke AI tool se bhi, bina original ticketing API ki ek bhi line change kiye.

💡 M×N problem = M applications ki integration cost jinme se har ek ko N tools chahiye, jab har (application, tool) pair alag se hand-wired ho -- cost ek sum ki tarah nahi, ek product ki tarah badhti hai. 💡 M+N = ek shared protocol hone ke baad ki integration cost: har application client side ek baar implement karti hai, har tool server side ek baar implement karta hai. 💡 Standardisation layer = ek shared format jo independently-built pieces ko ek doosre ke internals jaane bina interoperate karne deta hai -- MCP tools ke liye ek standardisation layer hai, kisi ek tool ko banane ka smarter tarika nahi. 💡 Agentic AI Foundation = wo Linux Foundation directed fund jo ab MCP ki specification ko govern karta hai, donation se bana hai, kisi ek company ke product ki tarah rakha hua nahi hai.

Standard definition (interview me bolo): MCP (Model Context Protocol) is an open standard that solves the M×N integration problem -- M AI applications each needing N tools -- by giving both sides one shared protocol to speak, turning M×N hand-written integrations into M+N; it standardises where a tool lives and how it is reached, not how the model decides to call it, and it is not a model, not an agent framework, and not a replacement for the API doing the underlying work.

Kab use karein: aap ek tool, ya ek data source, bana rahe hain jise genuinely ek se zyada AI application reach karna chahegi -- ek company-wide ticketing tool jise multiple internal bots call karenge, ya ek tool jise aap doosre developers ki AI apps ke use karne ke liye publish karna chahte hain. Independent clients ke across reuse hi wo poora value hai jo MCP khareed raha hai.

Kab NAHI use karein / Trade-off: ek single tool jise sirf aapki apni app kabhi call karegi. Ek MCP server khada karne ka matlab hai ek alag process, ek protocol handshake, aur maintain karne ke liye ek deployment -- real cost, zero reuse benefit ke liye agar koi doosra kabhi ek doosra client use se connect hi nahi karega. Us case me, model ko seedha diya gaya ek in-process function (Ch5 ki function calling) simpler hai, faster hai, aur chalate rehne ke liye ek kam moving part rakhta hai. Server tab banao jab actually ek doosra caller aa jaaye, uske pehle nahi.

Ek skilled translator ko socho jo aapke office ke andar ek desk se kaam karta hai. Jab aapke assistant ki desk par ek document aata hai jo unki samajh na aane wali language mein hai, aapka assistant use dekhta hai, pehchanta hai "ise translate karna hoga", aur use translator ke paas le jaata hai. Ye notice-karna-aur-decide-karna wala step -- zaroorat pehchanna, sahi banda choose karna, sahi document hand over karna -- ek skill hai jo aapke assistant ke paas already hai; ye tab bhi nahi badalti jab translator ki desk kahin aur move ho jaaye.

Ab socho ki wahi translator office chhod kar sadak ke us paar apni khud ki independent agency khol leta hai, ek phone line ke saath jise building mein koi bhi call kar sakta hai. Koi bhi doosra office -- jise pehle translator ke exist karne ka pata bhi nahi tha -- ab wo number dial kar sakta hai, apni zaroorat batao sakta hai, aur wahi translation karwa sakta hai, bina ye jaane ya care kiye ki agency ke andar translator ki desk kaise arrange hai. Translator ki actual skill ek bhi bit nahi badli. Jo badla wo ye hai ki wo kahan baitha hai aur use kaun reach kar sakta hai.

Production me, aapke assistant ka notice-karna-aur-decide-karna wala step wahi hai jise Ch5 ne function calling kaha tha: model ek user ki request dekhta hai, use diye gaye tools ki ek list dekhta hai, aur decide karta hai kaunsa call karna hai aur kaunse arguments ke saath. Ye decision-making MCP me nahi rehti -- MCP is picture ka doosra half own karta hai, translator ka apni khud ki agency me move ho jaana. Tool aapki app ke apne code se nikal kar apne khud ke standalone program (ek MCP server) me chala jaata hai, ek protocol (JSON-RPC) ke through reachable, ek plain function call ki jagah, taaki koi bhi app jiske paas ek MCP client ho -- na ki sirf aapki apni app -- use use kar sake.

Wahi tool, do baar dikhaya gaya. Maan lo aapne ek tool likha hai jo ek resume ko ek job description ke against score karta hai. Ye raha wo Ch5 wale tarike se, aapki app ke andar directly define kiya hua:

# Ch5-style: tool aapki app ke apne code ke ANDAR rehta hai
def score_resume(resume_text: str, job_description: str) -> int:
    """Score how well a resume matches a job description, 0-100."""
    ...

tools = [score_resume]   # aapka code ye list banata hai aur model ko de deta hai
# model docstring + function ka signature padhta hai aur DECIDE karta hai
# ki is request ke liye score_resume call karna hai ya nahi -- yehi step function calling hai

Ab wahi tool, ek MCP server ke peeche move kiya hua:

# MCP-style: WAHI tool ab apne OWN program me rehta hai
from mcp.server import MCPServer

mcp = MCPServer("resume-tools")

@mcp.tool()
def score_resume(resume_text: str, job_description: str) -> int:
    """Score how well a resume matches a job description, 0-100."""
    ...

Exact naam do ki kya badla aur kya nahi badla. Function ka body nahi badla. Docstring nahi badli. Jo badla: ek decorator ne ek plain list membership ki jagah le li, ye file ab ek standalone program hai jise koi doosra process import karne ki jagah ek protocol ke through connect karta hai, aur koi bhi app jo MCP bolti hai -- na ki sirf wo jisne aapne likhi -- ab score_resume ko reach kar sakti hai, ek mock-interview app samet jisne kabhi aapke resume builder ke saath codebase share nahi ki. Jab dono pictures me se kisi ek me model score_resume call karne ka decide karta hai, wo neeche bilkul wahi kaam kar raha hota hai: ek description padhna, use request se match karna, arguments banana. Ye step dono pictures me abhi bhi function calling hai -- MCP ne ise touch hi nahi kiya.

🌍 Real-world example: Hirenix ke resume builder me ek score_resume tool hai. Ek alag mock-interview feature bhi candidate ka resume score karna chahta hai questions generate karne se pehle. MCP ke bina, mock-interview app ya toh scoring logic dobara implement karega ya resume builder ka internal code import karega -- dono tarike fragile hain. score_resume ko ek MCP server ke peeche rakhne se, dono apps ke models apne-apne MCP client ke through wahi identical tool call karte hain; scoring logic sirf ek jagah likha aur fix hota hai.

💡 Function calling = model ki apni skill jisme wo ek request aur available tools ki list dekh kar decide karta hai kaunsa call karna hai aur kaunse arguments ke saath. Ch5 iski mechanics own karta hai; is chapter me ismein kuch nahi badalta. 💡 MCP = ek standard protocol jo ek tool ko uske apne program me daal deta hai taaki koi bhi app, na ki sirf wo jisne use likha, use reach kar sake. Ye ek distribution mechanism hai, decision-making mechanism nahi.

"MCP function calling replace kar deta hai" galat jawab hai, aur ye is protocol ke baare me sabse common mistake hai. Ye galat isliye hai kyunki dono ek doosre ke alternatives nahi hain -- dono alag alag questions ka jawab dete hain. Function calling jawab deta hai "is request aur in tools ko dekhte hue, kaunsa call karna chahiye?" MCP jawab deta hai "ye tool kahan rehta hai, aur mere alawa aur kaun ise call kar sakta hai?" Ek MCP-connected model har single call par abhi bhi function calling hi karta hai; MCP ne bas ye badla hai ki jo tool wo call kar raha hai wo kahan run ho raha hai. "MCP function calling replace kar deta hai" kehna waisa hi hai jaise kehna ek phone line translator ki skill ko replace kar deti hai -- jo number aap dial karte ho aur khud translation, ye dono bilkul alag cheezein hain.

Kab use karein: ek MCP server tab lo jab wahi tool genuinely ek se zyada application ya process dwara reusable hona zaroori ho -- ek resume-scoring tool jo aapke web app aur ek alag CLI dono use karte hain, ek database tool jise aap chahte ho Claude Desktop, Cursor, aur aapka apna product sab ek hi maintained implementation ke through call karein, ya ek tool jiski logic ek jagah update karni ho bina har us app ko redeploy kiye jo use use karti hai.

Kab NAHI use karein / Trade-off: agar sirf ek app kabhi bhi us tool ko call karegi aur wo us app ke apne code aur data se tightly coupled hai, toh ek plain Ch5-style in-process function hi sahi choice hai. MCP server khada karne ka matlab hai ek alag program chalana, ek client connection manage karna, aur har call par ek protocol handshake aur JSON-RPC round trip ki cost dena -- ye overhead hai jiske badle single-consumer tool ko kuch nahi milta. MCP tabhi lo jab reuse asli ho, na ki isliye ki ye zyada modern lagta hai.

Standard definition (interview me bolo): MCP does not replace function calling -- the model still performs function calling, deciding which tool to call and with what arguments, exactly as it does without MCP; MCP standardises tool distribution, moving a tool out of an app's own code into its own standalone server so that any MCP-compatible application can reach the same tool through a common protocol, instead of every app re-implementing it.

Kya bana rahe hain: is chapter ke har pehle topic ne apna MCP server ek chhote, invented demo ke around banaya -- word counts, ek divider, ek resource, ek prompt. Ye capstone ek server us actual product ke around banata hai jiske andar ye course khud hai: ek resume-analyzer, wahi kaam jo ek resume builder aur ATS scorer pehle se ek user ke liye karte hain, ab teen MCP tools ki tarah expose hua hai jinhe ek AI host call kar sake. Ye project FREE hai, aur apne ideas zero se dobara derive karta hai -- aapko is chapter ka har pehla topic padha hona zaroori nahi hai isse follow karne ke liye.

Ek college ki placement cell socho jisme teen desks ek line me hain. Pehla desk resume skim karta hai aur ek known list se har skill circle karta hai jo use pehchan aati hai. Doosra desk us resume ko ek job posting ke saath rakhta hai aur count karta hai ki posting ki kitni required skills pehle se circle hui thi. Teesra desk wapas ek chhota, capped note deta hai ki resubmit karne se pehle kya add karein -- poori missing list kabhi nahi, kyunki koi bhi chalis-line ka to-do note nahi padhta, aur ek desk jo sab kuch wapas dene ki koshish kare wo bas poori line ko dheema kar dega. Har desk exactly ek kaam karta hai, ek fixed order me, aur koi bhi doosre ka kaam dobara check nahi karta.

Production me, ye directly Hirenix ke apne resume builder aur ATS scorer pe map hota hai: ek user ka resume text aur ek target job description do strings hain jo ek backend ke paas pehle se ek database row me baithi hoti hain, aur is project ke teen tools wahi shape hain jisme un existing features ko Hirenix ke apne backend me re-expose kiya ja sakta hai, kisi bhi MCP-speaking AI host se callable, na ki sirf Hirenix ke apne frontend code se.

🌍 Real-world example: ek user Hirenix ke chat me ek job posting paste karta hai aur poochta hai "kya main is role ke liye ready hoon?" Is server se connected ek AI host score_resume call karta hai, ek kam number dekhta hai, suggest_improvements call karta hai ye jaanne ke liye ki kyun, aur ek hi turn me jawab deta hai -- teen tool calls model ne chain kiye, koi bhi ek bade function ki tarah insaan ne nahi likha.

💡 Keyword overlap = do pieces of text ko compare karna is baat se ki dono me kaunse known terms aate hain, meaning ki koi understanding nahi -- ye heuristic hai jo is project ka har tool model call ke bajaye use karta hai.

💡 Bounded result = ek tool result jiski size khud tool ne cap ki hui hai, input ke saath badhne nahi di gayi -- errors-and-tool-design (topic 15) me ek general rule ki tarah cover hua; ye project us rule ko apply karta hai, dobara explain nahi karta.

Standard definition (interview me bolo): A resume-analyzer MCP server is an ordinary MCP server -- built with MCPServer, @mcp.tool() and mcp.run(), no different from any other server in this chapter -- whose tools happen to implement a real product feature (skill extraction, resume-to-job scoring, and improvement suggestions) using plain-Python heuristics instead of a model call, so the whole pipeline is runnable and testable with no API key, while still leaving an explicit, documented seam for where a model call would slot in if richer, non-keyword analysis were wanted later.

⚠ Ek plain sentence ki kya chala aur kya nahi: neeche ka har tool real me chala, do baar, ek real client ke against stdio pe, dono runs me byte-identical output ke saath -- is file me kahin bhi koi illustrative banner nahi hai, aur code me kahin bhi koi model ya provider call exist nahi karti.

Step 1 -- Teen tools, ek client, zero API keys

Apne shape tak simplify karein toh, ye project hai: ek MCPServer pe teen @mcp.tool() functions, aur ek client jo teeno ko sequence me call karta hai. extract_skills(resume_text) ek resume padhta hai aur batata hai kaunsi skills pehchani. score_resume(resume_text, job_description) us resume ko ek job description se compare karta hai aur 0-100 score return karta hai. suggest_improvements(resume_text, job_description) hardened tool hai: ye apna khud ka input validate karta hai aur hamesha ek capped list return karta hai, kabhi unbounded nahi, chaahe actual gap kitna bhi bada ho.

Teeno ek shared idea pe baithe hain: ek fixed skill vocabulary -- lagbhag teen dozen technical aur soft skills ki ek plain Python list. Neeche ka har tool isi ek list ko text ke alag combinations ke against match karke banaya gaya hai. Is file me kahin bhi koi LLM call nahi hai; ek string ke against ek known word match karna wo cheez hai jo plain Python pehle se kar sakta hai, aur is topic ka apna accuracy rule explicit hai ki sirf isliye model call mat lo kyunki wo exist karti hai.

Step 2 -- extract_skills: shared matching logic, pehle tool ki tarah expose

def _find_skills(text: str) -> set:
    lowered = text.lower()
    return {skill for skill in SKILL_VOCAB if skill in lowered}

@mcp.tool()
def extract_skills(resume_text: str) -> str:
    """Extract known technical and soft skills from resume text by matching
    against a fixed skill vocabulary. Returns a comma-separated list."""
    if not resume_text or not resume_text.strip():
        return "Error: resume_text is empty. Provide the resume's plain text."
    skills = sorted(_find_skills(resume_text))
    if not skills:
        return "No known skills found in this resume text."
    return ", ".join(skills)

_find_skills ek private helper hai, tool nahi -- ye @mcp.tool() se decorate nahi hai, isliye model ise kabhi nahi dekhta aur directly kabhi call nahi kar sakta. Ye wahi ek logic hai jo is file ka har tool reuse karta hai, isiliye ye teen functions me copy-paste karne ke bajaye ek hi jagah likha gaya hai. extract_skills khud usi failure-handling lesson ko follow karta hai jo errors-and-tool-design (topic 15) pehle establish kar chuka hai: ek empty resume_text ek descriptive string return karta hai, raise nahi karta, isliye ek model jo real resume text pass karna bhool gaya, exactly ye padh sakta hai ki kya galat hua aur usi turn me sahi argument ke saath retry kar sakta hai. Verified real run, ek sample backend-developer resume pe: extract_skills ne return kiya aws, communication, django, docker, git, postgresql, python, rest api, sql -- nau matches. sql note karein: ye PostgreSQL ke andar match hua, ek standalone word ki tarah nahi -- substring matching ko koi idea nahi hota ki word kahan se shuru hota hai. Ye dono taraf apply hota hai aur Step 5 ki limitations dono naam leti hain.

Step 3 -- score_resume: set intersection, model ka judgement nahi

@mcp.tool()
def score_resume(resume_text: str, job_description: str) -> str:
    """Score a resume against a job description, 0-100. The score is the
    percentage of the job description's skills that also appear in the
    resume -- a keyword-overlap heuristic, not a semantic judgement."""
    resume_skills = _find_skills(resume_text)
    job_skills = _find_skills(job_description)
    overlap = resume_skills & job_skills
    score = round(100 * len(overlap) / len(job_skills))
    ...

Score sirf len(overlap) / len(job_skills) ka percentage hai -- resume_skills & job_skills Python ka apna set-intersection operator hai, jo poore "ye resume is job se match karta hai ya nahi" comparison ko ek line me kar deta hai. Ye genuinely ek model se weaker signal hai jo dono texts ko meaning ke liye padhta: ye ye nahi bata sakta ki "built REST APIs" ka matlab hai rest api skill jo pehle se match hui, aur ye ek related-but-not-identical skill ko partial credit nahi de sakta. Docstring khud plain words me ye bolti hai -- "a keyword-overlap heuristic, not a semantic judgement" -- kyunki ek tool description jo apni accuracy overstate kare, model ko galat direction me le jaayegi, ye exactly wahi tool-design lesson hai jo topic 15 pehle cover kar chuka hai. Verified real run: usi sample resume aur ek matching backend job description ke against, score_resume ne return kiya score=64/100 matched=7/11 matched_skills=aws, communication, django, docker, postgresql, python, sql -- ek real division, hardcoded number nahi, aur agar koi bhi input text badle toh ye badalta hai.

Step 4 -- suggest_improvements: hardened tool

@mcp.tool()
def suggest_improvements(resume_text: str, job_description: str) -> str:
    """Suggest up to 5 concrete skills to add to a resume ..."""
    if not isinstance(resume_text, str) or not isinstance(job_description, str):
        return "Error: resume_text and job_description must both be strings."
    if not resume_text.strip() or not job_description.strip():
        return "Error: resume_text and job_description must both be non-empty."
    if len(resume_text) > MAX_TEXT_CHARS or len(job_description) > MAX_TEXT_CHARS:
        return (f"Error: input too large (limit {MAX_TEXT_CHARS} characters each). "
                "Trim to the relevant section and retry.")
    ...
    bounded = missing[:MAX_SUGGESTIONS]

Ye jaan-boojh kar hardened tool hai, aur ye do alag jagah, do alag wajah se hardened hai. Pehle input validation: ek empty-string check aur ek length check, dono ek descriptive string return karti hain, Python ko AttributeError raise karne dene ke bajaye jo model act nahi kar sakta. Inke upar wali isinstance line sirf direct Python callers ke liye ek belt-and-braces guard hai -- MCP ke against ye kabhi fire hi nahi hoti, kyunki str type hints se generate hui JSON Schema SDK ko pehle hi ek non-string reject karne deti hai, is_error=True aur ek pydantic validation message ke saath. Measured: resume_text=12345 pass karne pe return hota hai is_error=True | Error executing tool suggest_improvements: 1 validation error ... Input should be a valid string. Ye jaanna zaroori hai: aapke type hints pehle se ek validation layer hain, aur aap haath se jo checks likhte hain wo sirf utna cover karte hain jo schema express nahi kar sakti. Length check specifically isliye hai kyunki is tool ka apna logic O(vocab size) hai har input ke liye, length se independent, isliye ek paste kiya hua 500-page document computation ko dheema nahi karega -- lekin ye request aur eventual result me baithega, aur uska har character ek character hai jo ek AI host ko is ek tool call karne ke liye context me hold karna padta hai, wahi "results context window ke against charge hote hain" lesson topic 15 se, yahaan output side ke bajaye input side pe apply hua. Doosra, bounded result: missing[:MAX_SUGGESTIONS] suggestion list ko 5 pe cap karta hai chaahe actually kitni bhi skills missing hon, aur returned string explicitly batati hai kitni chhodi gayin, chupke se drop nahi ki gayin -- isliye model ko ek chhoti, actionable list plus ek honest count milta hai, kabhi ek unbounded dump nahi jo baaki conversation ki jagah le le.

Verified real run, teen alag calls: ek normal resume aur job description ke saath, tool ne char missing skills return kiye (agile, ci/cd, graphql, kubernetes) uncapped kyunki char limit se kam hai. resume_text ko ek whitespace-only string set karne pe, ye return hua Error: resume_text and job_description must both be non-empty. -- koi exception nahi, koi crash nahi. resume_text ko "python " repeat karke 28,000 characters (20,000-character limit se zyada) set karne pe, ye return hua Error: input too large (limit 20000 characters each). Trim to the relevant section and retry. -- kisi bhi matching logic chalne se pehle reject ho gaya. Aur unnees skills naam lene wali ek job description aur ek-skill resume ke saath jiski wo ek skill un unnees me se koi bhi nahi hai (isliye saari 19 missing hain), tool ne exactly 5 suggestions plus line (14 more missing skill(s) not shown -- result capped at 5) return ki -- cap real me fire hui, ek aise case ke against jo specifically use test karne ke liye banaya gaya tha, sirf claim nahi kiya gaya.

Step 5 -- Client: teen tools, chhe calls, ek server process

Client upar snippet me poora dikhaya gaya hai; ye exactly wahi stdio_client + ClientSession shape hai jo writing-a-client (topic 9) ne establish ki: ek subprocess, ek handshake, list_tools() discovery ke liye kuch bhi invoke hone se pehle, phir har call ke liye call_tool(name, arguments), har reply result.content[0].text se padhi gayi. Is project ka client ek chalte hue server process ke against total chhe calls karta hai: teeno tools realistic input ke saath ek-ek baar, phir teen aur calls specifically suggest_improvements ke hardening ko exercise karne ke liye banayi gayi -- ek empty-input call, ek oversized-input call, aur ek many-missing-skills call. Yahaan koi naya client shape nahi hai; ye topic 9 ki wahi teen lines hain, chhe baar alag arguments ke saath call ki gayin, kyunki ek capstone ka kaam hai jo chapter ne pehle sikhaya use use karna, ek naya tareeka invent karna nahi.

Ye project kya prove karta hai, aur production me main kya alag karta

Prove karta hai: teen tools poori tarah set intersection aur string checks pe bane, sab bina kisi API key ke runnable, sab ek real stdio client se exercise hue, do baar, dono baar byte-identical output ke saath -- including hardened tool ka validation genuinely bad input reject karna aur uska cap genuinely 5 se zyada missing skills wale case pe fire hona.

Nahi karta: ye ek keyword-overlap heuristic hai, resume reviewer nahi -- ye writing quality judge nahi kar sakta, ek aisi description se skill infer nahi kar sakta jo use kabhi naam hi nahi leti, ye false positives fire karta hai kyunki ye words nahi, substrings match karta hai -- java (JavaScript ke andar), git (digital ke andar), react (reactive ke andar) sab measured hain -- aur iski skill list 37 fixed terms hai, real taxonomy nahi. Code me exactly ek comment mark karta hai ki ek real product kahaan model call karta: suggest_improvements ke andar, keyword gaps se aage phrasing-level suggestions ke liye. Production me main kya alag karta: fixed SKILL_VOCAB list ko ek maintained taxonomy se replace karta taaki ye chupke se ek thoda alag spell hui skill ("react.js" vs "react") miss na kare, aur suggest_improvements ko us ek marked seam se hoke ek model call tak route karta un suggestions ke liye jo "ye keyword missing hai" se aage jaate hain -- deterministic keyword pass ko ek fast, free first filter ki tarah rakhte hue, kisi model call pe kharch karne se pehle -- aur word boundaries pe match karta (re.search(rf'\b{re.escape(skill)}\b', lowered)) in ke bajaye, jo akela hi upar ke har false positive ko hata deta hai.

from mcp.server import MCPServer

mcp = MCPServer("resume-analyzer")

# A small, fixed skill vocabulary stands in for a real skills taxonomy.
# In production this list would come from a database and grow from real
# resume data -- a fixed list is enough here to prove the pipeline shape.
SKILL_VOCAB = [
    "python", "javascript", "typescript", "java", "sql", "react", "next.js",
    "node.js", "django", "flask", "fastapi", "docker", "kubernetes", "aws",
    "gcp", "azure", "git", "rest api", "graphql", "postgresql", "mongodb",
    "redis", "html", "css", "tailwind", "pandas", "numpy", "pytorch",
    "tensorflow", "machine learning", "data analysis", "ci/cd", "linux",
    "communication", "leadership", "agile", "scrum",
]

MAX_TEXT_CHARS = 20000  # a resume this large is almost certainly bad input, not a real resume
MAX_SUGGESTIONS = 5     # bounded so the result never floods the model's context window


def _find_skills(text: str) -> set:
    """Case-insensitive substring match of each vocab entry against text."""
    lowered = text.lower()
    return {skill for skill in SKILL_VOCAB if skill in lowered}


@mcp.tool()
def extract_skills(resume_text: str) -> str:
    """Extract known technical and soft skills from resume text by matching
    against a fixed skill vocabulary. Returns a comma-separated list."""
    if not resume_text or not resume_text.strip():
        return "Error: resume_text is empty. Provide the resume's plain text."
    skills = sorted(_find_skills(resume_text))
    if not skills:
        return "No known skills found in this resume text."
    return ", ".join(skills)


@mcp.tool()
def score_resume(resume_text: str, job_description: str) -> str:
    """Score a resume against a job description, 0-100. The score is the
    percentage of the job description's skills that also appear in the
    resume -- a keyword-overlap heuristic, not a semantic judgement."""
    if not resume_text or not resume_text.strip():
        return "Error: resume_text is empty."
    if not job_description or not job_description.strip():
        return "Error: job_description is empty."
    resume_skills = _find_skills(resume_text)
    job_skills = _find_skills(job_description)
    if not job_skills:
        return "Error: no known skills found in job_description -- cannot score against it."
    overlap = resume_skills & job_skills
    score = round(100 * len(overlap) / len(job_skills))
    matched = ", ".join(sorted(overlap)) if overlap else "none"
    return (f"score={score}/100 matched={len(overlap)}/{len(job_skills)} "
            f"matched_skills={matched}")


@mcp.tool()
def suggest_improvements(resume_text: str, job_description: str) -> str:
    """Suggest up to 5 concrete skills to add to a resume, based on skills the
    job description names that the resume does not. Hardened tool: rejects
    oversized or empty input instead of processing it, and always caps
    the number of suggestions returned regardless of how many are missing."""
    if not isinstance(resume_text, str) or not isinstance(job_description, str):
        return "Error: resume_text and job_description must both be strings."
    if not resume_text.strip() or not job_description.strip():
        return "Error: resume_text and job_description must both be non-empty."
    if len(resume_text) > MAX_TEXT_CHARS or len(job_description) > MAX_TEXT_CHARS:
        return (f"Error: input too large (limit {MAX_TEXT_CHARS} characters each). "
                "Trim to the relevant section and retry.")
    resume_skills = _find_skills(resume_text)
    job_skills = _find_skills(job_description)
    missing = sorted(job_skills - resume_skills)
    if not missing:
        return "No missing skills found -- resume already covers every skill this job description names."
    bounded = missing[:MAX_SUGGESTIONS]
    omitted = len(missing) - len(bounded)
    lines = [f'- Add "{s}" if you genuinely have this experience' for s in bounded]
    result = "Suggested additions:\n" + "\n".join(lines)
    if omitted > 0:
        result += f"\n({omitted} more missing skill(s) not shown -- result capped at {MAX_SUGGESTIONS})"
    # A real product would send resume_text + job_description to a model here
    # for phrasing-level suggestions beyond keyword gaps -- skipped so this
    # tool needs no API key and stays fully runnable offline.
    return result


if __name__ == "__main__":
    mcp.run()

# ---- client.py -- run this; it launches server.py as a subprocess ----
import asyncio
import sys
from mcp import StdioServerParameters
from mcp.client.stdio import stdio_client
from mcp.client.session import ClientSession

RESUME_TEXT = (
    "Backend developer with 3 years of experience. Built REST API services in "
    "Python using Django. Data stored in PostgreSQL. Deployed with Docker on AWS. "
    "Version control with Git. Strong written communication."
)
JOB_DESCRIPTION = (
    "We are hiring a backend engineer. Required: Python, Django, PostgreSQL, "
    "Docker, Kubernetes, AWS, GraphQL, CI/CD, Agile delivery and clear "
    "communication with the team."
)
BIG = "python " * 4000                      # 28000 characters
MANY_JOB = (
    "Required: aws, azure, docker, gcp, graphql, kubernetes, linux, mongodb, "
    "next.js, node.js, pytorch, react, redis, scrum, tailwind, tensorflow, "
    "typescript, leadership, html."          # 19 skills, none of them pandas
)
SMALL_RESUME = "I know pandas."


async def main() -> None:
    params = StdioServerParameters(command=sys.executable, args=["server.py"])
    async with stdio_client(params) as (read, write):
        async with ClientSession(read, write) as session:
            init = await session.initialize()
            print(f"CONNECTED: {init.server_info.name} | protocol: {init.protocol_version}")

            tools = await session.list_tools()
            names = [t.name for t in tools.tools]
            print(f"TOOLS: {names}")

            r1 = await session.call_tool("extract_skills", {"resume_text": RESUME_TEXT})
            print(f"extract_skills -> is_error={r1.is_error} content={r1.content[0].text}")

            r2 = await session.call_tool(
                "score_resume", {"resume_text": RESUME_TEXT, "job_description": JOB_DESCRIPTION}
            )
            print(f"score_resume -> is_error={r2.is_error} content={r2.content[0].text}")

            r3 = await session.call_tool(
                "suggest_improvements",
                {"resume_text": RESUME_TEXT, "job_description": JOB_DESCRIPTION},
            )
            print(f"suggest_improvements -> is_error={r3.is_error} content={r3.content[0].text}")

            r4 = await session.call_tool(
                "suggest_improvements",
                {"resume_text": "   ", "job_description": JOB_DESCRIPTION},
            )
            print(
                "suggest_improvements (empty resume_text) -> "
                f"is_error={r4.is_error} content={r4.content[0].text}"
            )

            r5 = await session.call_tool(
                "suggest_improvements",
                {"resume_text": BIG, "job_description": JOB_DESCRIPTION},
            )
            print(
                "suggest_improvements (oversized resume_text, 28000 chars) -> "
                f"is_error={r5.is_error} content={r5.content[0].text}"
            )

            r6 = await session.call_tool(
                "suggest_improvements",
                {"resume_text": SMALL_RESUME, "job_description": MANY_JOB},
            )
            print(
                "suggest_improvements (many missing skills) -> "
                f"is_error={r6.is_error} content={r6.content[0].text}"
            )


if __name__ == "__main__":
    asyncio.run(main())