The obvious ways, and where each one dies

Lesson 5 of 30, Module 1: The Whole Idea. You understand what MCP is, why it exists, and you have FELT the problem it solves.

What you can do after this lesson

A point-to-point integration you write by hand is glue: it fits exactly one tool talking to exactly one application. The moment a second application needs the same capability, that glue has to be rewritten from scratch, and every new job you add multiplies against every application you own instead of adding to it. Count that multiplication (M jobs times N applications) before building bespoke glue for anything, in or out of this course.

Code in this lesson

Every block the lesson shows on screen, in the order it appears.

from google.oauth2 import service_account
from googleapiclient.discovery import build
FOLDER = "paste your folder id here"

creds = service_account.Credentials.from_service_account_file(
    "key.json", scopes=["https://www.googleapis.com/auth/drive"])
drive = build("drive", "v3", credentials=creds)

def read_draft(name):
    q = f"name = '{name}' and '{FOLDER}' in parents and trashed = false"
    hits = drive.files().list(q=q, fields="files(id)").execute()["files"]
    return drive.files().get_media(fileId=hits[0]["id"]).execute().decode()

print(read_draft("draft.md"))

python3 draft.py

Downloads

Module 1 checkpoint (scribe-checkpoint-m1.zip): working code as the module leaves it, so a broken session costs you nothing
The course GitHub repo: every checkpoint, the README and the full lesson list

Prefer to read?

The written version of this part of the course is on Substack: https://genaiunplugged.substack.com/p/why-mcp-was-created-full-course-lesson.

Lesson transcript

The script that stops working

Today you write a script that works perfectly, and then you watch it become useless one application away.

Hello, and welcome to lesson 5 of the MCP Masterclass. Last lesson you gave your AI a key to your Drive. Today we try the obvious ways to use it, and we watch each one fall over. And we start with our map, as always.

6 lit boxes on the diagram. You, 2 apps, the client, the pipe, and the Google Drive folder you set up last lesson.

Well, today we do not learn the correct way to do anything. Instead we try the obvious ways, in order, and we watch each one of them let us down.

Do this lesson with your hands, because reading it is worth very little.

Way one: paste it in

So let us start with the first obvious way, which is to simply paste it in.

You have a draft in Drive with a typo in it. You want Claude to fix it.

So you open the document, select everything, and paste it into a chat. You ask Claude to fix the typo, and Claude fixes it. Then you copy the answer and paste it back into the document.

And here is the awkward part. That approach works.

It genuinely works, the edit is good, and for one document on one afternoon it is the correct answer. Do not let anybody tell you otherwise.

The trouble starts on the second day, when you do the whole dance again. Then again on the third. Every round trip happens by hand, and the copy in the chat goes stale the moment somebody edits the real document.

You are a technical person, so you do the obvious technical thing.

Way two: write a script

Which brings us to the second obvious way. You write a script.

Put this in your scribe folder, and call it draft.py.

from google.oauth2 import service_account
from googleapiclient.discovery import build
FOLDER = "paste your folder id here"

creds = service_account.Credentials.from_service_account_file(
    "key.json", scopes=["https://www.googleapis.com/auth/drive"])
drive = build("drive", "v3", credentials=creds)

def read_draft(name):
    q = f"name = '{name}' and '{FOLDER}' in parents and trashed = false"
    hits = drive.files().list(q=q, fields="files(id)").execute()["files"]
    return drive.files().get_media(fileId=hits[0]["id"]).execute().decode()

print(read_draft("draft.md"))

Now run it.

python3 draft.py

Your draft prints out. There is no copying, no pasting, and the content is never stale.

Notice the folder in that search. Leave it out and you get nothing back, even though the file is sitting right there. That is trap number 4 from the last lesson.

Now sit with this for a second, because it matters. The script works.

It is 14 lines, you wrote it in 5 minutes, and it does the job properly.

And if a course tells you that scripts are bad, that course is lying to you. This one is good.

The app that cannot see your machine

Now open Claude Desktop, and ask it to run that script and tell you what the draft says.

It cannot.

Now look closely at what it does instead, because this surprised me the first time I watched it.

It runs a command. Claude Desktop really does have a shell.

But look at which folder it looks in. You will see a path like /mnt/user-data. That path belongs to a small sandbox out in the cloud, and your machine is nowhere near it.

So it looks around inside its own sandbox, finds no scribe folder, and tells you the folder does not exist. From where it is standing, that is perfectly true.

Your script is 40 centimetres away from Claude, and it might as well be on the moon.

That is reason number 1, and you just felt it. A script only runs where the shell is. Claude Code's shell is on your machine. Claude Desktop's shell is somewhere else entirely.

Glue for every app

Fine. You are not beaten yet, and you will connect that script to Claude Desktop somehow.

Whatever you write to do that is glue. It is code whose only job is to let one app reach one tool. It is shaped by that app, and it knows how that app expects to be spoken to.

So you write the glue, and it works, and you are quietly pleased with yourself.

And then you open a second app.

Two weeks later you start using a second app, which might be VS Code, or Cursor, or Claude Code.

You want your draft reader in that app as well. So you go to attach it, and you discover that the glue you wrote does not fit. It is a different app, with a different shape and different expectations.

So you sit down and write the glue a second time.

Counting the glue

Now count along with me, because this arithmetic is the whole lesson.

You have 2 jobs so far, which are reading a draft and saving a draft. You also have 2 apps.

	Claude Desktop	Second app
Read a draft	glue	glue
Save a draft	glue	glue

Reading a draft needs glue for the first app, and glue for the second. Saving a draft needs glue for the first app, and glue for the second.

That is 4 pieces of glue, for 2 jobs.

Add a third job and the number becomes 6. Add a third app and it becomes 9. Every new job multiplies against every app you happen to own.

That shape has a name. People call it the M×N problem. M jobs, N apps, and you write M×N pieces of glue.

That is reason number 2, and you just felt that one too.

The script was not the mistake

And I want to be very clear about one thing here. I am not saying the script was a mistake.

Go back and look at it again. It is 14 lines, it works perfectly, and it took 5 minutes to write.

The script is a fine answer for a job that lives in your terminal and belongs only to you today.

The trouble arrives when the work has to happen somewhere your shell is not, or in a second app, or on somebody else's machine.

So what do we want instead?

Look at that table again and imagine a better version of it. You write the 2 jobs a single time, and every app picks them up without any new code from you.

2 jobs plus 2 apps. So 4 becomes 4, which is not very exciting yet. Now try 5 jobs and 4 apps, where 20 pieces of glue collapses into 9.

Multiplying turns into adding. That is the promise, and in the next lesson you watch it happen with your own hands and no code at all.

Where the map stands

So where does our map stand at the end of this lesson?

Still 6 boxes, and still that same hole sitting in the middle.

You should be starting to feel the shape of what belongs in it.

Next lesson we will take 2 servers and 2 apps, write no code at all, and watch M×N become M+N.

Bye now, and I will see you in the next lesson.