Introduction

Due to changes in Anthropic's terms of service, the use of Claude subscriptions via third-party harnesses has been blocked. While there was some buzz about it, to be honest, it didn't really affect me.

I have the Claude Code CLI at my fingertips. I just need to build a bridge: send a message to Discord, pass it to the CLI, and return the reply to Discord.

So, I built it.

Built Just the Framework

I created LogBot. It's a simple bot that forwards messages from Discord to the Claude Code CLI and returns the responses to Discord.

Discord ──→ LogBot ──→ Claude Code CLI
              ↑                │
              └── Post Response ──┘

I implemented the following features as a minimal framework:

• Session Management — Maintains Claude Code sessions based on UUID. These are completely isolated from VSCode sessions.
• Message Queue — If messages arrive while Claude is processing, they are queued and processed in order, so none are missed.
• Approval Flow — If Claude attempts to edit a file, a notification is sent to Discord, where I can approve or reject it via reactions (✅ / ❌).
• MCP Server — If you place files in the tools/ directory, they can be used as tools by Claude.

What's important here is that I started with zero MCP tools. No weather, no calendar, no train info—nothing. Just the framework.

However, this framework has one powerful characteristic:

Claude can write files. In other words, it can add JavaScript files to the tools/ directory. The MCP server automatically scans and registers tools under tools/.

Claude can create its own limbs.

Started with "I want a clock"

The first thing I asked Claude from Discord was trivial.

"What time is it?"

While the Claude Code CLI can retrieve system time, it's smarter to have it as an MCP tool. I asked Claude to "make an MCP tool that returns the time."

In a few seconds, tools/current-time.js was created.

Next was "I want to know the weather." Claude created tools/weather.js using the free Open-Meteo weather API. No API key required.

"I want to see my Google Calendar schedule." Claude created tools/gcal-auth.js and tools/gcal-list.js, complete with OAuth helpers.

"I want to read my Gmail too." Following the same pattern, a complete set of Gmail tools was created—authentication, listing, reading bodies, sending, filtering, and bulk deletion.

All I did was say "I want this" from Discord. I didn't write a single line of code myself.

It's not code that CRON hits

Once the tools were in place, the next thing I wanted was periodic execution.

"Tell me the weather, train operation info, and today's schedule every morning at 7:00 AM."

Normally, one would write a script that hits the weather API, calls the calendar API, scrapes train information, formats it, sends it, and registers it to CRON.

But since I'm using Claude, it's more interesting to pass a prompt rather than code.

{
  "cron": "0 7 * * *",
  "prompt": "Give me the morning report. Tell me the weather (Saitama City Kita-ku, today), train operation info, and today's calendar schedule. Please include a 'Good morning' greeting as well."
}

When 7:00 AM hits, the scheduler wakes up Claude. Claude calls the weather tool, the calendar tool, and the train info tool, summarizes the results, and posts them to Discord.

Claude decides which tools to combine and how. The logic isn't written in code; it's written in the prompt.

In other words, if I want to change the format of the report, I just rewrite the prompt. Just by sending a single line to Discord saying, "Add tomorrow's weather too," it changes the next morning.

Departure Notification—The Real Topic

The morning report was just the beginning.

"Based on today's schedule, let me know when it's time to leave."

From this single request, the departure notification mechanism was born.

What I wanted

If I have an appointment, say, "Meeting in Shinjuku at 2:00 PM," I want to be notified 30 minutes before departure, including weather and train operation info, by calculating the travel time backward.

Difference from regular reminders

Google Calendar notifications trigger "30 minutes before the event." But it doesn't consider travel time. If it takes an hour to get from home to Shinjuku, a notification at 1:30 PM is too late. I want to be told "time to go" at 12:30 PM.

Furthermore, the calculation changes if I'm already out. If I have another errand in Omiya in the morning and then head to Shinjuku, the travel time is shorter.

What Claude is doing

Every hour (from 6 AM to 10 PM), a prompt like this is sent to Claude via CRON:

Check the calendar, and if a departure notification is needed for any appointment with a location, register it.

Claude receives this instruction and makes its own judgment:

1. Look at the calendar — Get upcoming appointments. Find appointments with a set location.
2. Estimate current location — If there's an ongoing calendar event, assume I'm there. Otherwise, assume home.
3. Calculate travel time — Use the Google Maps API to calculate travel time from current location to destination. If within 2km, assume walking; otherwise, train. Since the Transit API isn't available in Japan, I approximate using car travel time + 15 minutes. It's crude but surprisingly practical.
4. Calculate departure time backward — Appointment start time - travel time = departure time.
5. Register notification job — Push a one-shot job to the scheduler for 30 minutes before departure.

Then, 30 minutes before departure, the job fires, Claude wakes up, retrieves the weather and train info, and constructs the notification.

🚨 Time to leave soon!
📅 Meeting (Starts at 14:00)
📍 Destination: Shinjuku
🚃 Train (Estimated): ~55 min → Leave at 12:35

☁️ Today (Mon) Partly Cloudy
　🌡️ 22.3℃ / 14.1℃　☔ 10%

🟢 Currently, there are no reported issues with train lines!

Where is the logic?

This is what I want to convey the most.

This entire decision logic is consolidated into an MCP tool called departure-check.js. But Claude made this tool too. When I said "I want a departure notification," the necessary tools (travel time, location estimation) didn't exist yet, so it created those first, and finally created departure-check.js to combine them.

And what CRON is hitting is still just a prompt: "Check the calendar, and if a departure notification is needed, register it." With this one sentence, Claude utilizes its tools to make a judgment.

Individual parts are simple. A tool to get the weather, a tool to view the calendar, a tool to calculate travel time, a tool to get train information. But when and how to combine them is up to Claude. I didn't line up 'if' statements in code. The AI is observing the situation and making decisions.

A Self-Expanding Environment

To summarize everything so far:

• MCP Tool = Limbs. Individual capabilities (weather, calendar, travel time, email...)
• Claude = Brain. Uses tools to combine and judge.
• CRON = Alarm clock. Wakes Claude up periodically. Hits it with a prompt.
• Discord = Interface. Both requests and notifications happen here.

And the biggest feature is that if Claude lacks limbs, it creates them on the spot.

If you send "I want this feature" to Discord, Claude writes the tool code and adds it to tools/. The MCP server automatically detects and registers it. It becomes usable from the next moment.

Conversely, all I did was build the framework. The bridge between Discord and CLI, the MCP auto-scan, and the CRON scheduler.

Conclusion

Now, it tells me the weather and schedule at 7 AM, notifies me before going out with travel time calculations and train information, and manages my email. Of course, there have been times when I had to tweak the behavior of the tools, but basically, they grew by me saying "I want this" from Discord.

This might be obvious for ideas from an AI beginner, but I'm releasing it on GitHub.

OpenCClaw — A bot system that operates Claude Code CLI via Discord.