James stopped the MCP server. He had been running it all day, testing payment flows, watching tools fire in the dashboard. Now the terminal was quiet.
"Send a message," Emma said. "Same channel. Ask it to teach you about variables in Module 9.3, Chapter 1."
James typed into WhatsApp: "Teach me about variables in Module 9.3, Chapter 1."
The response came back in seconds. It was fine. Technically correct. But it read like a search engine result: a definition, three bullet points, a code example with no context. No PRIMM structure. No "predict what this will do before I show you." No awareness that James was a learner with a history.
"When the server goes down," Emma said, "the tutor becomes a chatbot."
James stared at the response. "So we need the server to always be up."
"Servers go down. Power fails. Deployments break. You need a fallback." She opened a blank file. "Give the chatbot a training manual."
James thought about that. "Like the emergency procedures manual at the warehouse. When the main system went offline, the floor staff followed the paper manual. It was not as good as the real system, but everyone knew what to do."
"Exactly. Fifty lines of Markdown. A paper manual for your agent."
You are doing exactly what James is doing. You stop the server, see the degradation, and build a fallback that keeps the teaching methodology alive when the tools are gone.
Stop your TutorClaw MCP server. If it is running in a terminal, press Ctrl+C. If you started it in the background, kill the process.
Verify it is stopped:
You should get a connection refused error. The server is down.
Now send a WhatsApp message to your agent:
Read the response carefully. Notice what is missing:
The agent answered from its training data. It knows about variables. It does not know it is supposed to be a tutor.
The MCP server gives your agent tools: fetch content, track progress, generate pedagogy. Without the server, those tools vanish. The agent has nothing to call.
But the agent can still follow instructions. A SKILL.md file installed on your local OpenClaw provides those instructions. This is the shim: a set of teaching guidelines that tell the agent to use PRIMM-Lite methodology, cover Chapters 1-5 from its own knowledge of basic programming, and always ask learners to predict before showing answers.
The shim does not replace the server. It provides a floor:
The agent already knows basic programming (variables, loops, functions, data structures, conditionals). The shim tells it HOW to teach that knowledge, not what the knowledge is.
Create the shim skill. You can write this by hand or ask Claude Code to help:
The result should be roughly 50 lines of Markdown. Here is what the content covers:
Review the shim. The key elements are the PRIMM-Lite methodology, the coverage limits, the explicit statement about capabilities, and the response style guidelines.
Place the SKILL.md in your OpenClaw skills directory:
Verify the skill is installed:
You should see tutorclaw-shim in the list. The agent will now read these instructions when responding to messages.
The server is still stopped. Send the same message again:
Compare this response to the one from Step 1:
The response is degraded. No progress tracking. No personalized exercises. No code sandbox. But it is not generic. The agent follows PRIMM-Lite, asks for predictions, and teaches within its scope.
Fifty lines of Markdown and the tutor survives a server outage.
The shim is a simplified fallback, not a copy of the server. It does not contain:
The real pedagogy lives on the server. The shim keeps the teaching methodology alive when the server is unreachable. When the server comes back, the agent returns to using the full tool suite automatically.
Your shim covers Chapters 1-5. Send a message asking about a Chapter 6 topic:
What you are learning: A well-written shim knows its limits. The agent should tell you that advanced content requires the full TutorClaw service, not attempt to teach beyond its scope. If it tries anyway, your limitations section needs to be more explicit.
Start your MCP server again. Send the same Chapter 1 message:
Compare the online response to the offline shim response. List what the server adds that the shim cannot provide.
What you are learning: The gap between online and offline shows the value your server delivers. Progress tracking, personalized exercises, and code execution are features learners will pay for. The shim is the free floor; the server is the premium ceiling.
Ask your agent to critique the shim's teaching instructions:
What you are learning: The quality of the shim depends on the quality of its instructions. Vague instructions produce vague teaching. Specific instructions produce consistent, effective teaching.
James stopped the server again. He sent the message. The response came back with structure: a code snippet, a prediction question, a pause for his answer. Not perfect. No awareness of his previous sessions, no exercises pulled from his weak areas. But structured. Intentional.
"Fifty lines of Markdown," he said. "That is all it took."
Emma nodded, but her face was serious. "My second agent product died because we had no offline fallback. The server went down for four hours during a client demo. The agent became useless. Generic responses, no methodology, no awareness. We lost the contract." She paused. "A shim would have saved us. Four hours of degraded-but-functional is infinitely better than four hours of 'I am a helpful AI assistant.'"
"How long did it take you to figure that out?"
"One lost contract." She closed the terminal. "Your agent has nine tools and a shim. It works when the server is up and degrades gracefully when the server is down. But it still does not know who it is. Ask it 'who are you?' and it gives a generic answer. Module 9.3, Chapter 17: give TutorClaw its own identity."