<!-- rikai-logo --> <p align="center"> <picture> <source media="(prefers-color-scheme: dark)" srcset=".github/assets/logo-dark.svg"> <img src=".github/assets/logo.svg" alt="yomi" width="96" height="96"> </picture> </p>

Yomi (読み) — the personal LINE MCP server

Yomi is an open-source LINE MCP server for your personal account. Read, reply, send images, and search every conversation from Claude or any local AI agent — without a browser, bot account, or LINE's own client.

The name reads more than one way. 読み (yomi) — a reading: not just parsing your messages, but reading the situation, the way you do. 詠み (yomi) — to recite: it doesn't read in silence, it reads things back to you. And 黄泉 (yomi) — the unreachable realm; the very yomi in 黄泉帰り (yomigaeri), "returning from Yomi." Like a messenger moving between two realms, Yomi passes through sealing and silence to bring messages still readable deep inside your conversations back into the light. It does not summon history already lost; it helps what has not disappeared be seen again.

Unlike LINE's official Bot MCP server, which connects AI agents to a LINE Official Account through the Messaging API, Yomi connects to your existing personal LINE account and conversations as a secondary device.

Yomi speaks LINE's TCompact-over-HTTPS protocol directly, decrypts Letter-Sealing (E2EE) messages and media, and exposes the result to any AI agent through a small stdio MCP server. Point Claude Desktop (or any MCP client) at it and the agent can catch up on your LINE the way you do — read, reply, send an image, mention someone, and search your whole history locally — and, with get_insight, read the situation: which conversations are waiting on your reply, who ties your world together, and what has gone overdue.

No official API, no bot account, no webhook. Yomi logs in as a secondary device on your own account.

Guides: What is a LINE MCP server? · LINE MCP 是什麼？Yomi、官方 Bot 與桌面自動化的差異.

Unofficial. Yomi is an independent personal project, not affiliated with or endorsed by LINE. Using it may be against LINE's Terms of Service, and running an additional client on your account carries a risk of rate-limiting or suspension. It is intended for reading your own account. Use it at your own risk. See Disclaimer.

---

Getting started

Native Desktop preview

Yomi Desktop puts the LINE inbox and local agent workspace in one native app. It bundles its own runtime: users do not install Node, open Terminal, clone this repository, or configure YOMI_RUN_MJS. Native Desktop is separate from the Claude Desktop MCPB extension described below.

| Platform | General-user package | Signing status | Install experience | | --- | --- | --- | --- | | macOS 14+, Apple Silicon | Yomi-Desktop-macOS-arm64-<version>.dmg | Developer ID signed and Apple notarized | Open DMG → drag Yomi to Applications → open Yomi | | Windows 10/11 x64 | Yomi-Desktop-Windows-x64-<version>-Setup.exe | Trusted OSS signing application in progress | Download remains unavailable until signing and installer smoke pass |

The macOS package has been tested through the real downloaded-app path: quarantined DMG, install to /Applications, Gatekeeper assessment, first launch, bundled-runtime message refresh, and no-terminal LINE login form. The Windows installer contains the equivalent in-app phone/PIN login flow and is tested on a native Windows runner before release.

Desktop builds are experimental and unofficial. LINE changes may break them, and running an additional client may put an account at risk. Prefer a test account and keep a current backup. Preview installers are published as GitHub pre-releases only after platform signing is available.

See the desktop release process, code-signing policy, and privacy policy.

MCP server and Desktop Extension

You need Node.js and a LINE account. Yomi runs locally through npx; you do not need to clone this repository, install Bun, or build anything. Run node --version first, and install the current LTS if the command is missing or the version is unsupported.

Yomi's local search index uses Node's built-in node:sqlite, so it needs v22.13 or newer — except v23.0–v23.3, which are newer than v22.13 yet still lack that module (it was unflagged in both 22.13.0 and 23.4.0). Any current LTS is fine. This is engines.node in package.json; the rest of Yomi runs on older Node, but search, scope and capture do not.

⚠️ Yomi needs a client that runs it on your own machine. Cloud-only tools (ChatGPT, Claude.ai web) cannot run Yomi. Configure Yomi in Claude Desktop or Claude Code and it works in both chat and Cowork, because Desktop starts Yomi on your machine and Cowork's local sessions load it. Do not ask Cowork to install Yomi for you: Cowork's shell runs inside a throwaway VM, not on your machine, so anything it installs there is gone when the session ends. Follow the steps below yourself, in your own terminal.

Choose the client you actually use and follow only that section. Claude Code and Claude Desktop have separate MCP settings; configuring one does not configure the other.

<details open> <summary><strong>Claude Desktop — one-click install (no terminal, no Node)</strong></summary>

The easiest path, and the only one that needs no command line at all. Claude Desktop ships its own Node runtime, so nothing else has to be installed.

1. Download the bundle for your machine from the latest release:

   | Machine | File | | --- | --- | | Windows (Intel/AMD) | yomi-win32-x64.mcpb | | Mac (Apple Silicon) | yomi-darwin-arm64.mcpb | | Linux (x64) | yomi-linux-x64.mcpb |

2. In Claude Desktop, open Settings → Extensions, and drag the downloaded file onto that page (or just double-click the file).

3. Review what it asks for, click Install.

4. Start a conversation and say "log in to LINE". Yomi shows a form, you enter your phone number, and you confirm on your phone. No terminal at any point.

This skips the config file entirely, which also sidesteps the Windows MSIX bug described below.

Note for Cowork users: do not ask Cowork to install Yomi for you. Cowork's shell runs inside a throwaway VM — not on your machine — and it will not type into your real terminal. Install the bundle yourself with the three clicks above; once installed, Cowork's local sessions can use Yomi like any other tool.

</details> <details> <summary><strong>Claude Desktop — manual config (npx)</strong></summary>

1. Find the full path to npx:

   macOS / Linux: which npx
   Windows:       where npx
   

2. Open the Claude Desktop config file:

   macOS:   ~/Library/Application Support/Claude/claude_desktop_config.json
   Windows: %APPDATA%\Claude\claude_desktop_config.json
   

   ⚠️ Windows: the documented path may not be the one Claude actually reads. Claude Desktop ships as an MSIX package, whose filesystem is virtualized. The app reads its config from

   %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
   

   while Settings → Developer → Edit Config opens the unvirtualized %APPDATA%\Claude\ file. They are two different files that never sync, so a correct Yomi config written to the documented path is silently ignored — no error, no log, Yomi simply never appears. This is claude-code#26073, still open. If Yomi does not show up after a restart, write the same config to the LocalCache path above as well. (Not applicable to Claude Code, or to Desktop installed outside MSIX.)

3. Add Yomi under mcpServers, replacing the example command with the full path printed in step 1. On Windows, JSON requires each \ in the path to be written as \\:

{
  "mcpServers": {
    "yomi": {
      "command": "/opt/homebrew/bin/npx",
      "args": ["@rikaidev/yomi"]
    }
  }
}

For example, a Windows path may look like "C:\\Program Files\\nodejs\\npx.cmd". Use the path reported on your own machine rather than copying either example blindly.

⚠️ The npx you name here does not decide which Node runs Yomi. On macOS and Linux npx is a script beginning with #!/usr/bin/env node, so it runs whichever node comes first on Claude Desktop's PATH — not the Node installed beside the npx you just pointed at. Desktop inherits its PATH from the desktop session, which is often not your terminal's, and version managers (nvm, fnm, asdf, volta, …) put their own node ahead of everything else. So which npx can report a perfectly modern install while Yomi still starts on an old Node.

The symptom is specific: logging in, reading and sending all work, but search, scope and capture fail, and the log says No such built-in module: node:sqlite. Yomi prints the runtime it actually got in that error — read it rather than assuming.

The fix is to give the server a PATH whose first entry holds a supported node:

"yomi": {
  "command": "<the npx path from step 1>",
  "args": ["-y", "@rikaidev/yomi"],
  "env": { "PATH": "<dir holding a supported node><sep><a base PATH>" }
}

Separator: : on macOS/Linux, ; on Windows. Keep a usable base after it (/usr/local/bin:/usr/bin:/bin or your platform's equivalent) — this replaces the server's PATH rather than prepending to it, and npx needs the ordinary tools.

Naming an absolute node in command does not work, however plausible it looks: npx spawns the package's own bin as a child process and resolves node from PATH again for it, so command only picks who runs npx, not who runs Yomi. Setting PATH is what actually reaches the server.

Configuring this with an AI agent? MCP configs are mostly written by agents now rather than by hand, so the steps above are stated for a human reading their own machine. An agent should resolve the values instead of emitting placeholders, and this setup has one trap worth stating outright: naming npx in command does not pin the runtime. Procedure:

1. Find a Node that actually has the module Yomi's index needs — do not infer it from a version number:

   node -e 'require("node:sqlite")' && command -v node    # POSIX
   node -e "require('node:sqlite')" && where node         # Windows
   

   If it throws, that Node is unusable for search/scope/capture. Try the other installs (which -a node, nvm ls, fnm list, …) until one passes; only then continue.

2. Write that Node's directory into env.PATH, per the JSON above, and keep a base PATH after it. Resolve the directory on the target machine (dirname of the path from step 1); do not copy an example out of this README — they are Apple Silicon Homebrew paths and wrong nearly everywhere.

   Do not instead put an absolute node in command. It reads like the stronger fix and is not one: npx spawns the package's bin as a child and re-resolves node from PATH for it, so command only decides who runs npx. This was measured, not as