line-bot-mcp-server: LINE Messaging API tools for MCP agents
MCP server that integrates the LINE Messaging API to connect an AI Agent to the LINE Official Account.
At a glance
- What is it?
- An Apache-2.0 TypeScript MCP server from LINE that exposes push, broadcast, profile, rich menu and follower tools to an AI agent. It is a preview release, so treat its tool surface as provisional and verify quota behaviour before wiring it into anything customer-facing.
- Who is it for?
- Adopt line-bot-mcp-server if you already operate a LINE Official Account with the Messaging API enabled and want an agent to draft and send pushes or manage rich menus without you writing a Messaging API client. Do not adopt it if you need delivery guarantees, per-message auditing, or anything beyond the thirteen documented tools, because the repository labels itself a preview.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between an AI agent and a LINE Official Account
An agent that can write a message still cannot send it. The LINE Messaging API is an HTTPS surface with its own authentication model, its own resource types (users, rich menus, groups), and its own quota accounting. Wiring an agent to it normally means writing a small client, deciding which endpoints to expose, and describing them in a form the model can call. line-bot-mcp-server is LINE's own attempt to skip that step: it is a Model Context Protocol server that presents the Messaging API as a fixed set of named tools. The intended user is someone who already runs a LINE Official Account, has enabled the Messaging API on it, and wants an MCP-capable agent such as Claude Desktop or Cline to act on that account. The README is explicit that this is a preview, offered for experimental purposes, and that it may not include complete functionality or comprehensive support. That framing matters more than any individual tool, because it tells you how to read the rest of the documentation.
Thirteen tools, and the shape they impose on the agent
The tool list is the product. Four tools send: push_text_message and push_flex_message target one user, broadcast_text_message and broadcast_flex_message target everyone who follows the account. Two read account state: get_profile returns display name, picture URL, status message and language for a user, and get_message_quota returns the monthly limit and current consumption. Five manage rich menus: list, delete, set default, cancel default, and create. The create tool is the most opinionated: it takes a chatBarText and between one and six actions, then generates and uploads an image and sets the menu as default in one call. The action types it accepts are postback, message, uri, datetimepicker, camera, cameraRoll, location, richmenuswitch and clipboard, which is a subset of what the Messaging API itself supports. Two tools were added later: get_follower_ids, which pages through the user IDs of friends of the account using a start continuation token and a limit, and get_group_summary, which returns group ID, name and icon URL from a groupId. The pattern across all thirteen is that the server does not try to mirror the API. It picks operations that a conversational agent can plausibly drive, and leaves the rest to a hand-written client.
How a call actually flows, and where DESTINATION_USER_ID fits
The data flow is one-directional and stateless. The agent picks a tool, fills the arguments, and the MCP server translates that into a Messaging API call authenticated with CHANNEL_ACCESS_TOKEN. Nothing is cached between calls, and there is no inbound path: this server sends and reads account metadata, it does not receive webhooks or messages from users. The one piece of shared state is the DESTINATION_USER_ID environment variable. Both push tools and get_profile accept an optional userId, and when it is omitted the server falls back to DESTINATION_USER_ID. The README states that either the tool input or the environment variable must be set, which means an agent configured without DESTINATION_USER_ID will fail on any push where the model does not supply a user ID explicitly. That default is convenient for a single-recipient testing setup and awkward for anything else, because it quietly makes one user the implicit target of every underspecified push. The broadcast tools have no such fallback and no targeting arguments at all; they go to the whole follower list.
Getting it running with npx or Docker
The npx path requires Node.js v22 or later. Before configuring anything, the README says you need a LINE Official Account with the Messaging API enabled, following LINE's own getting-started instructions. The agent configuration is a standard MCP server block: command npx, args ["@line/line-bot-mcp-server"], and an env object containing NPM_CONFIG_IGNORE_SCRIPTS set to "true", CHANNEL_ACCESS_TOKEN, and DESTINATION_USER_ID. The README marks CHANNEL_ACCESS_TOKEN as required and DESTINATION_USER_ID as optional, and points at LINE's documentation for obtaining a long-lived channel access token and for finding your own user ID. The Docker path is also documented: clone the repository with git clone git@github.com:line/line-bot-mcp-server.git and build the image from there. The README text supplied here is truncated partway through the Docker build step, so the exact build command and any Docker-specific environment handling are not visible in the material. One release note is worth reading before you install: v0.4.2 is titled Fix Create Richmenu Tool via npx, which implies that create_rich_menu was broken specifically when the server was launched through npx and was repaired in that release.
The preview label is not decoration
Three things in the material point the same direction. The repository carries a note that it is provided as a preview version, for experimental purposes, possibly without complete functionality or comprehensive support. The tool list has visible holes: there is no tool for retrieving a user's message history, no way to query or manage the account's rich menu aliases, and no inbound handling, so an agent using this server can speak but cannot listen. And the release history is thin and unevenly spaced, with v0.4.0 and v0.4.2 landing on the same day in November 2025 and v0.5.0 following in May 2026, which suggests a small surface that changes in bursts rather than a stable interface. The practical failure mode is the broadcast pair. broadcast_text_message and broadcast_flex_message take no audience argument, so a model that misreads intent and calls a broadcast instead of a push sends to every follower at once, and the only guard available in this server is the quota tool, which reports consumption after the fact rather than blocking a send. If you need approval gates, per-recipient logging, or scheduled delivery, this is the wrong layer and you should call the Messaging API directly.
Compared with writing your own Messaging API client
The real alternative is not another MCP server, it is a thin client you control. A hand-written wrapper around the LINE Messaging API gives you the full endpoint surface rather than thirteen tools, lets you enforce an allowlist of recipients before a send leaves your process, and keeps the channel access token inside your own service instead of in an agent's environment block. What you give up is the part line-bot-mcp-server already did: describing each operation in a schema an MCP client understands, handling the rich menu image generation and upload that create_rich_menu bundles together, and paging follower IDs with a continuation token. If your agent work is exploratory, that trade is easy to take. If your agent is going anywhere near real followers, the missing approval layer is the deciding factor, because a broadcast through this server is one tool call with no confirmation step in between.
Licence, maintenance and what upgrading costs you
The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirements around preserving notices and stating changes. That is a permissive licence, and nothing in the material suggests additional terms; this is a description of the licence text, not legal advice, and you should read the LICENSE file yourself before shipping. The maintenance cost is mostly about version skew. The server is published to npm as @line/line-bot-mcp-server, so an npx configuration resolves whatever version is current at launch time unless you pin it, which means an agent's behaviour can change without any edit on your side. Pinning the version in the args array is the obvious mitigation. Upgrading also has a history of breaking one specific tool: the v0.4.2 release exists to fix create_rich_menu under npx, so if you rely on that tool, test it after every bump rather than assuming the tool list is stable. Node.js v22 or later is a hard floor on the npx path.
Editorial conclusion
Adopt line-bot-mcp-server if you already operate a LINE Official Account with the Messaging API enabled and want an agent to draft and send pushes or manage rich menus without you writing a Messaging API client. Do not adopt it if you need delivery guarantees, per-message auditing, or anything beyond the thirteen documented tools, because the repository labels itself a preview. Verify three things first: that your Node.js runtime is v22 or later, that CHANNEL_ACCESS_TOKEN is a long-lived token you are willing to place in the agent's config file, and that get_message_quota reports enough monthly headroom for the broadcast tools you intend to expose.
Community notes