← Back to the course home

🌍 Five real-world use cases

Production-shaped MCP setups, each drawn twice: the numbered flow (what happens) and the sequence diagram (who says what to whom, in order). Every one is lesson 04's seven messages, repeated — read one wire, read them all. Companion to lesson 08.

1 🐙 The coding assistant — IDE + GitHub + files

“Fix issue #42.” Read the complaint, read the code, run the tests, draft the PR — and the PR waits for a human click.

The flow, numbered:

🧑 'fix issue #42'1🐙 get_issuethe complaint2📁 read_filethe code3🧪 run_tests4🚧 'allow PR?'the human gate5✅ PR created6one goal, three servers, one gate — the shape of every coding-agent story

The sequence, message by message:

🏫 IDE host🧠 model🐙 GitHub srv📁 files srvgoal + tool shelves1get_issue(42) — via host2bug report → desk3read_file(buggy.py)4code → desk5proposes create_pr(fix)6🚧 host asks the human: 'allow PR?' — click ✓create_pr → PR exists7

💡 Why MCP here: the same GitHub server works in every IDE and agent — write once, plug in everywhere (L01's N+M).

2 🎧 The support desk — orders DB + docs

“Where's my refund?” Look up the order (read-only), fetch the policy, answer with receipts.

The flow, numbered:

🧑 'where's my refund?'1🗄️ orders DBSELECT-only!2📚 docs serverrefund policy3✅ grounded answer + receipts 🧾open-book, MCP-style4RAG's open-book exam (AI course L10) wearing standard plugs

The sequence, message by message:

🎧 support app🧠 model🗄️ orders srv📚 docs srvthe DB account behind the server can ONLY read — AWS course L03's least privilegecustomer question + shelves1lookup_order(#8412) — read-only2order status → desk3get_policy('refunds')4policy text → desk5answer citing order + policy 🧾6

💡 Why MCP here: grounding beats guessing (AI course L09) — and the read-only scoped account makes the worst case boring.

3 📊 The data analyst — SQL + charts

“Which product sold best last month, per region?” Query, chart, explain — in the chat.

The flow, numbered:

🧑 'best product last month?'1🗄️ query_dbscoped account2📈 make_chart3✅ numbers + picturein the chat4rich inputSchema (enums, read-only) is what keeps 'analyst' from becoming 'DROP TABLE' 😅

The sequence, message by message:

💬 chat app🧠 model🗄️ SQL srv📈 chart srvquestion + shelves1query_db(SELECT top products…)2rows → desk3make_chart(rows, 'bar by region')4chart image → desk5summary + chart6

💡 Why MCP here: one SQL server serves every team's AI app; schema design (L06) is the guardrail.

4 📅 The meeting-prep butler — calendar + CRM + email

“Prep me for the 3 pm.” Event, company, threads — three servers braided into one brief.

The flow, numbered:

🧑 'prep me for the 3pm'1📅 get_eventwho + what2🏢 crm_lookupthe company3✉️ recent_threadsthe history4📋 one tidy brief5THREE servers, one room, one desk — the N+M payoff in a single request

The sequence, message by message:

🤖 assistant🧠 model📅 calendar🏢 CRM✉️ email'prep me' + shelves1get_event(3pm)2attendees, agenda → desk3crm_lookup(Acme)4account notes → desk5recent_threads(attendees)6last emails → desk7the brief 📋8

💡 Why MCP here: three integrations that used to be three custom projects are now three config lines.

5 📁 The report robot — files + Slack

“Summarize this folder's weekly reports and post to #team.” Reads flow; the one write gates.

The flow, numbered:

🧑 'summarize + post'1📁 list_dir2📄 read_file ×N3🧠 summarizeon the desk4🚧 'post to #team?'the gate5💬 posted6reads flowed freely; the ONE write waited for a click — L05's rule 3 in production

The sequence, message by message:

🤖 agent host🧠 model📁 files srv💬 Slack srvgoal + shelves1list_dir(reports/)27 files → desk3read_file(each) — loop4contents → desk5writes the summary6proposes slack_post(#team, summary)7🚧 human gate: 'post this?' — shown in full, click ✓slack_post → 💬 posted8

💡 Why MCP here: automation with a human gate on the only irreversible step — L05 rule 3, shipped.