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.

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.

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.

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 assumed — with a Node 20 first on PATH, command-pinning still gave the server Node 20.

   command -v may also hand back a wrapper rather than a real binary — heap shims, local-first npx wrappers and version-manager stubs are all common, and some behave differently depending on the client's working directory. Do not try to reason your way to the "real" one. Step 3 settles it.

3. Verify with a tool that touches the index. yomi version is not a verification — it prints a string without opening SQLite, so it succeeds on a Node that cannot run search. Call get_scope_policy: it needs SQLite and no LINE login. If it returns the policy text, the runtime is right. If it fails, the error names the Node that actually ran and what it needed.

4. Fully quit and reopen Claude Desktop. Confirm Yomi is loaded under Settings → Developer before anything else: if Yomi is not listed there, Claude never read your config — on Windows, see the MSIX warning in step 2. Once it is listed, the tools are available in chat and in Cowork's local sessions alike.

You do not need to install Claude Code for this setup.

claude mcp add yomi -- npx @rikaidev/yomi

Start a new claude session. The Yomi tools should appear automatically. This command configures Claude Code only; it does not configure Claude Desktop.

This form leaves the runtime to PATH, which is fine as long as the node your claude session resolves is a supported one — it is the same PATH you can see, unlike Claude Desktop's. Check with node -e 'require("node:sqlite")'. If it throws, or you would rather not depend on PATH at all, name the Node explicitly:

claude mcp add yomi -e PATH="$(dirname "$(command -v node)"):$PATH" -- npx -y @rikaidev/yomi

Either way, verify with get_scope_policy rather than yomi version: the version command prints a string without opening SQLite, so it passes on a Node that cannot run search.

Running Claude Code inside a clone of this repo? Spell the spec @rikaidev/yomi@latest. Without a tag, npx looks for a local bin first, and in this repo package.json declares "bin": {"yomi": ...} while nothing links it into node_modules/.bin — so npx skips the install and dies with sh: yomi: command not found. An explicit tag makes it fetch the published package. Only affects working copies of Yomi itself; everywhere else the untagged form is fine.

This standard config works in most MCP clients:

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

Cursor Settings → MCP → Add new MCP Server → name it yomi, command type, value: npx @rikaidev/yomi

Or add to .cursor/mcp.json in your project root.

Add to .vscode/mcp.json:

{
  "servers": {
    "yomi": {
      "command": "npx",
      "args": ["@rikaidev/yomi"]
    }
  }
}

Add to ~/.config/opencode/opencode.json:

{
  "mcp": {
    "yomi": {
      "type": "local",
      "command": ["npx", "@rikaidev/yomi"],
      "enabled": true
    }
  }
}

codex mcp add yomi npx @rikaidev/yomi

Or add to ~/.codex/config.toml:

[mcp_servers.yomi]
command = "npx"
args = ["@rikaidev/yomi"]

Add to cline_mcp_settings.json:

{
  "mcpServers": {
    "yomi": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@rikaidev/yomi"]
    }
  }
}

Add to ~/.codeium/windsurf/mcp_config.json — same JSON as standard config.

amp mcp add yomi -- npx @rikaidev/yomi

Advanced settings → Extensions → Add custom extension → name yomi, type STDIO, command: npx @rikaidev/yomi

grok mcp add yomi -- npx @rikaidev/yomi

First login

Once connected, tell the agent:

"Log into LINE — my number is +8869XXXXXXXX."

Approve the device on your phone (see Logging in), and:

"Summarize my unread LINE and tell me who's waiting on a reply."

Related MCP server: line-desktop-mcp

What you can do

Yomi exposes 20 tools over MCP (the ones worth naming; see the tables). Large read results use token-efficient TOON; small status and write results use compact JSON. Errors remain plain text and media uses native MCP image/audio/resource content. "Honest error" below means an explicit failure naming the problem (e.g. missing_decrypt_material) — Yomi never fabricates a fallback, a placeholder, or a fake success.

Reading

Insight (read the situation, not just the messages)

Writing (these really send — not drafts)

Search (local, cross-conversation — LINE has no such primitive)

Scope & privacy (all work offline, no LINE session needed)

Session

Logging in

Prerequisite: on your primary phone, enable 設定 › 我的帳號 › 允許自其他裝置登入 (Settings › Account › Allow login on other devices). Without it LINE never offers this device a sign-in prompt — this is the single most common reason a first login appears to hang.

⚠️ Single Desktop Session Limit: LINE allows only one desktop client session at a time per account. Because Yomi connects as a desktop secondary device (DESKTOPMAC), logging into Yomi will sign out your official LINE Desktop app (and signing back into LINE Desktop will invalidate Yomi's session). You cannot use Yomi and the official LINE Desktop client simultaneously.

You only need to give the agent your phone number in E.164 form — it supplies the region itself (e.g. TW for a +886 number) when it calls the tool.

Yomi drives LINE's passwordless (secondary-device) flow. How the login surfaces depends on your MCP client:

• Clients with the MCP elicitation capability — login prompts you for your phone/region, shows the PIN in a dialog, and blocks to completion. One call, no PIN relayed through the model. Your phone number never enters the transcript.

• Clients without it (e.g. Claude Desktop today) — two calls. login (with your phone + region) returns the PIN in its result; enter it in LINE on your primary phone and approve the device; then call login_complete, which blocks until the phone confirms. The agent should call login_complete immediately — it does the waiting, so there is nothing for you to report back.

• From a terminal — npx @rikaidev/yomi login runs the whole flow on stdout, PIN and all. Always available as a fallback.

The one deadline that matters is LINE's: you have about 3 minutes from when the PIN is shown to enter it and approve the device. Yomi's own client keeps listening for many minutes beyond that, so a slow phone is never the failure — only LINE's 3-minute code lifetime is.

Once you've logged in, the session — including a login certificate — is persisted (see below), and future logins skip the PIN entirely.

There is also an experimental MCP Apps UI (a ui://yomi/login card) for clients that render interactive views. It is spec-correct and renders under the MCP Inspector, but some hosts fetch the resource without completing the view handshake, so it is display-only and never on the critical path — the flows above always work regardless.

Sessions and credentials

Yomi owns its own login. On startup it calls resumeSession() once, reading the LINE session from the macOS Keychain (service dev.rikai.yomi.credentials, account line) and silently refreshing the token if needed.

• First-party credentials. The passwordless login persists the auth token, refresh token, certificate, MID, and the E2EE keypair itself — then reads them back to verify the write actually landed. A login that can't be persisted fails loudly at login, not silently at the next restart.

• Shared session. The session is stored in the canonical dev.rikai.yomi.credentials keychain entry (or local credential store), allowing Yomi MCP and Yomi Desktop to share the exact same LINE login session seamlessly.

• Platform note. On macOS the session lives in the login Keychain. On Linux and Windows Yomi currently falls back to a local JSON file — functional, but less protected than an OS secret store, and less exercised than the macOS path. Native secure-storage backends (libsecret / DPAPI) are planned; until then, treat a non-macOS install accordingly.

Every tool except login and the offline scope/search tools returns an honest error when there is no session. Yomi is otherwise a pure query server — it never polls, never backfills in the background; each tool call makes exactly the LINE requests it needs, and collect_messages is the only path that fetches across many chats at once.

Search

LINE has no cross-conversation search; Yomi builds one locally. The index is a gitignored SQLite database (data/search-index.db) in the repo — nothing leaves your machine.

Search is hybrid by design. It always runs FTS5 keyword search (bm25 over bigram-preprocessed text, so CJK substrings with no word boundaries are covered) and, when embeddings exist, semantic search, then fuses the two ranked lists by Reciprocal Rank Fusion. Pure semantic search silently drops exact matches that live in un-embedded messages; pure keyword misses paraphrases; fusing both surfaces an exact term and a meaning-match together. The response's mode field always reports which methods contributed.

Semantic ranking keeps each message as its own vector. Testing against real indexed LINE conversations found that embedding overlapping conversation windows diluted the center message and reduced retrieval quality. Context is therefore added only after ranking: Yomi limits one chat from flooding the top results and expands each winner with two messages on either side so the agent sees the exchange that gave the hit meaning without weakening the embedding itself.

Semantic ranking uses Xenova/bge-small-zh-v1.5 (BAAI general embedding, small, Chinese-primary but multilingual) via transformers.js. Embedding inference runs fully in-process on CPU — your message text is never sent anywhere.

The one caveat is a one-time model download: on the first collect_messages or search_messages, transformers.js fetches the model (~90 MB) from huggingface.co and caches it locally; every run afterwards is fully offline. That first fetch is an outbound HTTPS request to HuggingFace for the model weights — it carries your IP and which model is being downloaded, but no message content and no LINE data. If you need Yomi fully air-gapped, pre-populate the transformers.js cache (or point it at a local model directory) before the first search so no network call is ever made.

The secondary-device reality (read before trusting "I can't get old messages")

Yomi runs as a secondary device on your account. That shapes what it can see:

• Group chats without Letter Sealing are plaintext at the LINE server — full history and media, no restriction.

• Group chats with Letter Sealing are E2EE, and there the epoch matters. Such a group is encrypted with a shared group key that rotates (on membership changes, or when a client provisions a new one). LINE only ever hands a device the current group key — there is no API to fetch a superseded one. So a secondary device decrypts messages from the epoch whose key it holds onward; messages sent under an older epoch — before Yomi obtained the current key — can come back undecryptable, even in a group whose earlier history it can read. This is inherent to Letter Sealing's per-epoch group keys, not a bug here. It can also cut sideways: the epoch your phone holds and the epoch Yomi holds need not be the same, so the two devices can each read a different slice of the very same group.

• Installing Yomi does not itself rotate anything, so "before I installed Yomi" is the wrong boundary. Yomi only ever resolves an existing group key; it never registers (mints) one, because minting rotates the group's shared secret for every member and strands every message encrypted under the previous one. So a fresh install picks up the current key and reads back to the last rotation — which may predate the install by months. The boundary is the last rekey, not your install date. And once Yomi has seen an epoch it keeps that key, so a rotation after install leaves it able to read both sides. If a group comes back undecryptable all the way to today, that is not this limitation — please report it.

• 1:1 media uses the account-level E2EE keychain, which a secondary device fully possesses (LINE syncs it during pairing) — Yomi can decrypt 1:1 images/files it can see.

• 1:1 history backfill is the one real limitation. LINE does not hand a secondary device the past 1:1 message history the way it does for groups. Messages received while Yomi is connected decrypt normally; deep-scrolling into 1:1 history that predates pairing may come back empty. This is a LINE server-side restriction, not a bug here.

When decryption genuinely fails, Yomi returns an explicit missing_decrypt_material error — never a fake card or placeholder. Silence is honest; a fabricated result is not.

Development

For contributors working on the Yomi source code (requires bun or Node.js 24+ — .nvmrc pins the same 24 that CI installs, so nvm use in this directory picks it up; note nvm does not read engines, which is why the two are stated separately and guarded by a test):

bun install                 # install dependencies (or npm install)
bun run.mjs                 # run the stdio MCP server
bun run.mjs login           # run the login flow in a terminal
npm run build               # tsc --noEmit — type-check only (Yomi ships & runs from src/)
npm test                    # bun test

The build only type-checks and compiles; this repo does not talk to live LINE servers as part of its own build. Connecting an MCP client and calling login is what actually starts a session.

src/
  line/     LINE protocol core: TCompact/Thrift codec, E2EE (Letter-Sealing,
            group keys, media), Talk/Auth/Sync service clients, session state,
            passwordless login flow.
  auth/     Credential store (macOS Keychain, JSON-file fallback off-darwin).
  search/   Local cross-conversation index (SQLite + FTS5) and the offline
            embedding pipeline (transformers.js).
  mcp/      The stdio server: tool schemas, handlers, the privacy-policy loader,
            and the experimental MCP Apps login view (mcp/ui/).
  util/     [TAG]-prefixed logger (stderr only — stdout is the MCP JSON-RPC stream).

Everything Yomi writes for humans goes to stderr; stdout is reserved for the MCP JSON-RPC stream. A stray console.log corrupts the protocol — don't add one on any path the server can reach.

Privacy

By default Yomi indexes all your conversations into the local, on-device search index so an agent can search across them — a capture-all default, opt-out per chat. Nothing is ever uploaded; the only data that leaves your device is whatever the agent itself surfaces in its replies. (The one non-LINE network call Yomi itself makes is the one-time embedding-model download from HuggingFace on the first search — model weights in, no message content out; see Search.) PRIVACY.md is the canonical policy, and Yomi surfaces that same text to the agent on connect (and via get_scope_policy) so it can disclose the default before any bulk read.

Disclaimer

Yomi is an independent, unofficial personal project, built for learning and for accessing one's own LINE account. It is not affiliated with, authorized, or endorsed by LINE Corporation. "LINE" is a trademark of its respective owner.

Running Yomi may violate LINE's Terms of Service, and operating an additional client on an account can result in rate-limiting or suspension of that account. Yomi is intended for accessing your own account and data. You are solely responsible for how you use it. The software is provided "as is", without warranty of any kind — see LICENSE.

Acknowledgments

Yomi's LINE protocol implementation was written with reference to three open-source projects, whose field layouts, E2EE chunk ordering, request shapes, and Thrift definitions informed this independent implementation:

• evex-dev/linejs (MIT) — request shapes and the Letter-Sealing E2EE payload layout.

• DeachSword/CHRLINE (BSD-3-Clause) — protocol field layouts and the passwordless login flow.

• er1ce/LINE-Protocol (Apache-2.0) — Thrift enum definitions (ContentType, MessageRelationType, ServiceCode).

Their copyright notices and full license texts are reproduced in NOTICE, as their licenses require.

License

MIT