Deploy it, and publish it so others can install it

Lesson 28 of 30, Module 4: Ship It. It publishes to Substack, runs on the web, and anyone can install it.

What you can do after this lesson

A free host and a public web address both have a cost you have to know before you trust them. The nap loses the memory file, and the address works as a password because Scribe has no login. A server that holds your own keys is published as a package other people run themselves, never as your address.

The problem we inherited

The draft is finished in Drive and still goes nowhere. You copy it into Substack by hand, which is exactly where you came in.

Code in this lesson

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

mcp>=2.1,<3
google-api-python-client>=2.0,<3
google-auth>=2.0,<3
requests>=2,<3

key.json
memory.json
.venv/

Use scribe to read draft.md.

Downloads

• Module 4 checkpoint (scribe-checkpoint-m4.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

Lesson transcript

Scribe running in the cloud

Today Scribe runs on a computer that is not mine, and Claude reaches it from the cloud. My laptop could be shut, and it would still answer.

Hello, and welcome to lesson 28 of the MCP Masterclass. Last lesson your server got a web address, and we found out why Claude cannot use it until the server is on the internet. Today we put it there. And we start with our map, as always.

15 lit boxes. One left, the registry, at the very bottom. It gets its minute at the end of this lesson.

What free really means

Well, first the thing I promised in lesson 24. If you stop before this lesson, you still have a working server with 7 tools, a guard, a memory, and 2 services. This lesson is a bonus. It needs 2 free accounts, GitHub and a host called Render, and neither one asks for a card.

And I want to say free the honest way. Render's free plan gives you 750 hours a month, and a server that goes to sleep after 15 minutes with nobody talking to it. Free today, for a hobby server, with a nap. Not free forever, and not for something people pay you for.

Put the server on GitHub

Okay. Two things on the laptop, then the host.

First, the server has to be in a GitHub repo, because that is where Render reads it from. Two files go in. scribe_server.py, and the requirements file. Here it is, with the fourth line from lesson 25.

mcp>=2.1,<3
google-api-python-client>=2.0,<3
google-auth>=2.0,<3
requests>=2,<3

Second, and this one matters, a file called dot git ignore, with 3 lines.

key.json
memory.json
.venv/

Your key is a password, and it never goes into git. memory.json holds your own notes and your trust list, and it stays with you. And the dot venv folder is the installed packages, which the host builds for itself.

Make a new repo on GitHub, and push the folder. If you have never done that, the 4 lines are in your checkpoint notes. Private or public, both work.

Set up Render

Now Render.

On screen: dashboard.render.com, the New button, Web Service.

Sign in, click New, and pick Web Service. Connect your GitHub, and choose the scribe repo.

On screen: the form. Name scribe, Language Python, Build Command pip install -r requirements.txt, Start Command python scribe_server.py, Instance Type Free.

Then 5 settings in the form.

The name becomes part of your web address. The language is Python, and Render picks a recent version on its own, which MCP runs on, so you set nothing there. The build command installs the 4 packages. The start command is the same line you ran last lesson. And the instance type is Free.

Then scroll down to the environment. This is where the 4 settings go that used to live in your Claude Desktop file.

Your folder id, your Substack name, your cookie, and scribe transport set to h t t p, so the server picks the web address and not the pipe. You do not set the port. Render sets it, to ten thousand, and your server reads it, because of the line from last lesson.

And the key. There is a section called Secret Files. Make one called key dot json, and paste the whole key into it. Render puts that file next to your server when it runs, so the key setting keeps its default and you add nothing for it.

On screen: the Secret Files section, filename key.json, the contents pane blurred.

Pause your screen recording while you paste the cookie and the key, if you record this. Both are passwords.

Deploy and check it is up

Now click Deploy. And watch the log.

On screen: the Render build log. pip installing the 4 packages, then "Uvicorn running on http://0.0.0.0:10000". Hold on that line.

It installs the 4 packages, and then the same line as last lesson. Running on, all zeros, port ten thousand. Your server is up on somebody else's computer.

Open the address Render gave you, in a browser.

On screen: Chrome at https://scribe-something.onrender.com showing "Scribe is up. Claude talks to /mcp". Hold 3 seconds.

Scribe is up. That is your home route from lesson 27, answering from the internet.

Connect Claude to the cloud server

Now Claude. Not the settings file, the connector door.

On screen: Claude Desktop. Customize, then Connectors, then the plus button, Add custom connector. The URL field holds the onrender address with /mcp on the end. Add.

Open Customize, then Connectors, and press the plus. Pick add custom connector. Paste your address, with slash m c p on the end, because that is where Claude talks, and press Add.

Then open a new chat. Press the plus button in the chat, and switch the new scribe connector on. And switch the old local scribe off for this chat, so you can see which one answers.

Use scribe to read draft.md.

On screen: Claude calls read_doc through the connector. The draft comes back, "# My first draft", "This is a test. This line has a typo in it."

Your draft. Read through the cloud, by a server that is not on your laptop, through a web address instead of a pipe. Same tool, same words.

Three limits of the free host

Now 3 things about the free host that you need to know before you trust it. All 3 are true, and I would rather you hear them from me.

First, the nap. After 15 minutes with nobody talking to it, the server goes to sleep, and the next call takes about a minute to wake it. So the first connect after a quiet hour may fail. Open your address in a browser, wait for Scribe is up, and try again. The home route exists for exactly this.

Second, and this one hurts. The memory does not survive the nap.

The free host keeps no disk. When the server sleeps, every file it wrote is gone, and memory.json is a file it wrote. So remember and trust work, right up to the next nap, and then Scribe remembers nothing. On your laptop the memory is safe. On the free host it is not, and I am telling you now so you do not find out next week. Lesson 30 says what fixes it.

Third, and read this one twice. Your web address is the password.

On screen: a plain card. "This URL is the password. Anyone who has it can read and edit your Drive folder, make drafts in your Substack, and read your memory. Keep it private."

Scribe has no login of its own. Anyone who has that address can do everything you can do. Read your drafts, change them, make drafts in your Substack, read your notes. The address is long and nobody can guess it. But if you paste it anywhere public, you have handed out the key.

Keep it private. A real product puts a login in front of this, and the protocol has a way to do that, called O Auth. It is a module of its own, and lesson 30 names it as the first thing that breaks next.

The MCP Registry, and why Scribe stays off it

And that brings me to the last box. The registry.

There is a public list of MCP servers now, run by the people who run the protocol. It is called the MCP Registry, and as I record this it is in preview. You describe your server in a small file called server dot json, you log in with GitHub, and a tool called m c p publisher puts it on the list. Any app that reads the list can then find your server.

And here is why Scribe does not go on it, and why this box gets a pointer and not a lesson.

The registry is for a server that other people run, with their own keys and their own folders. Listing an address on it is an invitation for the world to connect to it. For Scribe, that address is wired to your Drive and your Substack. You would be publishing the password from a minute ago.

So the rule is in your checkpoint notes, with the server dot json and the 4 commands. Publish the package, never your address. If you ever want strangers running their own Scribe, that is the path, and it is a short one.

Where the map stands

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

16 boxes lit. The registry is on, as a pointer. Every box on the map is lit, and 1 of them is a place you chose not to go yet.

Next lesson is the module 4 recap. Five points, and then the last lesson of the course.

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