Send any LINE message to any target. Picks the right LINE API automatically (reply / push / multicast / narrowcast / broadcast) based on the shape of target.

Three modes (parameter mode):

• send_now (default): Send immediately. Pre-flight validation + Quota Guardian + quiet-hours check are applied.

• draft: DO NOT SEND. Return a "handoff package" with audience id, Flex JSON, a LINE OA Manager broadcast URL, and 6 click-through steps. Use this when the user wants to SCHEDULE — LINE OA Manager UI has native scheduling that Messaging API lacks.

• dry_run: Validate + estimate cost only. Useful before confirm flows.

Target shapes (pick one):

• { reply_to: "webhookEventId" } — reply (1 user, free, 30s window)

• { user_id: "U..." } — push to one

• { user_ids: ["U...", "U..."] } — multicast (auto-chunked to 500/call)

• { audience: "name-or-id" } — narrowcast by audience group

• { filter: { ages, genders, areas, ... } } — narrowcast by demographic

• { everyone: true } — broadcast (requires confirm: true)

Message shapes (pick one):

• { text: "..." } — plain text (≤5000 chars)

• { template: "voucher", data: {...} } — pre-built Thai-localized Flex template

• { flex_json: {...}, alt_text: "..." } — raw Flex JSON (advanced)

• { sticker: { package_id, sticker_id } } — LINE sticker

Auto-applied safety:

• Pre-flight validation via LINE /validate (catches JSON errors before consuming quota)

• Quota Guardian: blocks if projected cost > 95% of remaining quota unless confirm=true

• Quiet-hours warning (22:00–08:00 BKK) unless force=true

• Reply-token TTL handling: falls back to push if token is expired (with a warning)

• Auto-generated X-Line-Retry-Key for safe retries

Returns (varies by mode): send_now → { success, transport, request_id?, recipient_count_estimated, quota, warnings[], next_steps? } draft → { draft: true, oa_manager_url, audience_summary, flex_json_pretty, flex_preview_url, copy_paste_steps[], notes } dry_run → { dry_run: true, transport, validated, projected_recipients, projected_cost_messages, quota, warnings[] }

Examples:

• "ส่งข้อความให้คุณ A" → { target: { user_id: "U..." }, message: { text: "..." } }

• "ออกแบบโปรวันแม่ + เตรียม schedule" → { target: { audience: "moms" }, message: { template: "promo_simple", data: {...} }, mode: "draft" }

• "ส่งโปรให้ผู้หญิง 25-44 กรุงเทพ" → { target: { filter: { genders: ["female"], ages: ["age_25", "age_30"], areas: ["bangkok"] } }, message: {...} }

Errors:

• QUOTA_OVER → Reduce audience or wait for monthly reset

• QUIET_HOURS → Pass force=true or use mode=draft to schedule

• INVALID_MESSAGE → Pre-validation caught a JSON error; check details

• AUDIENCE_NOT_READY → Wait ~10 minutes after audience creation

Display the "..." typing indicator in a 1:1 chat with a user. The indicator vanishes when the bot sends a message OR after the timeout. Use this when an agent is about to take a noticeable amount of time before replying.

Only works in 1:1 chats (NOT in groups or multi-person rooms).

Args:

• chat_id: The user ID of the 1:1 chat.

• seconds: How long to display (5-60). Default 20.

• oa: optional OA id.

Returns: { success: true, chat_id, seconds }

Find LINE stickers from a curated catalog by mood or keyword. Both Thai and English search terms are supported.

LINE only allows bots to send stickers from a limited official list. This tool lets agents pick stickers by intent ("celebration", "ขอบคุณ", "sorry") rather than guessing IDs.

Args:

• query: Mood or keyword. Examples: "ขอบคุณ", "celebration", "sorry", "love".

• limit: Number of suggestions (1-20). Default 5.

• response_format: 'markdown' (default) | 'json'.

Returns: { query, count, stickers: [{ package_id, sticker_id, moods, keywords_th, keywords_en, description }] }

Pass the chosen package_id + sticker_id to line_send_message: { message: { sticker: { package_id, sticker_id } } }

Examples:

• "หา sticker ขอบคุณ" → { query: "ขอบคุณ" }

• "celebration sticker" → { query: "celebration" }

Create a LINE Rich Menu in one call: validate → create → upload image → set as default. Collapses what is normally 4 LINE API calls into one tool, including the api-data.line.me domain switch for image upload (the #1 cause of failed implementations).

This V1 supports single-panel rich menus. The "tab-pair" (Tab A ↔ Tab B switching design) shipped widely by Thai agencies will be added in V1.1 alongside richmenu alias support.

Args:

• name: Internal admin name (≤300 chars).

• chat_bar_text: Label on the chat-bar button (≤14 chars). Show in user's LINE UI.

• size: 'compact' (2500x843) or 'large' (2500x1686, default).

• image_url: Public HTTPS URL of the rich menu image. JPEG/PNG, aspect ≥1.45, ≤1MB.

• areas: Tappable regions with action objects (postback / message / uri / richmenuswitch).

• set_as_default: Set as account-wide default after creation. Default true.

• selected: Whether the menu auto-opens. Default true.

• oa: Optional OA id.

Returns: { rich_menu_id: string, name: string, set_as_default: boolean, warnings: string[] }

Image requirements (validated client-side before upload):

• Width: 800-2500px

• Aspect ratio: ≥1.45

• File size: ≤1MB

• Format: JPEG or PNG

Examples:

• "Rich Menu โปรวันแม่ 2 ปุ่ม" → params with 2 areas, large size, set_as_default: true

Errors:

• INVALID_AREA → Coordinates exceed image bounds

• IMAGE_TOO_LARGE → ≥1MB; resize and retry

• QUOTA_EXCEEDED → 1,000 rich menus max per OA

List all rich menus on an OA + identify which one is the account-wide default. OAs can hold up to 1,000 rich menus — use line_delete_rich_menu to clean up.

Args:

• oa: optional OA id.

• response_format: 'markdown' (default) | 'json'.

Returns: { total: number, default_id?: string, rich_menus: [{ rich_menu_id, name, chat_bar_text?, size?, is_default, is_selected }] }

Use this before line_build_rich_menu to avoid hitting the 1,000-menu cap.

Delete a rich menu by ID. If the menu is currently linked to specific users, those links break silently — consider running line_audit_user_menu first.

Requires confirm=true to prevent accidental deletion via prompt drift.

Args:

• rich_menu_id: The richMenuId (starts with 'richmenu-').

• confirm: Must be true to proceed.

• oa: optional OA id.

Returns: { success: true, deleted_id }

Why is user X seeing menu Y? This tool inspects the rich-menu priority chain for a user:

1. Per-user link (line_link_rich_menu_to_user) — overrides everything

2. Account-wide default

3. (LINE OA Manager built menus override API-built ones — silent gotcha!)

Args:

• user_id: LINE user ID.

• oa: optional OA id.

Returns: { user_id, visible_rich_menu_id?: string, source: 'per_user' | 'default' | 'none', per_user_link?: string, default_id?: string, explanation: string // Thai-language explanation }

Compose a validated Flex Message ready for line_send_message. Two input modes:

1. Template mode (recommended for Thai use cases): { template: "voucher", data: { title, code, discount, valid_until } } Available templates: receipt, voucher, shipping_update, order_confirm, appointment_reminder, promo_simple, course_cert, thank_you

2. Raw mode (advanced): { flex_json: {...bubble or carousel JSON...}, alt_text: "..." }

3. Discovery: { list_templates: true } returns the catalog with descriptions in Thai and required fields per template.

Returns: { template?: string, flex_json: { ...Flex contents... }, alt_text: string, preview_url: string, // LINE Flex Simulator deep link size_bytes: number, warnings: string[] // e.g., if approaching the 30KB bubble limit }

Composability:

• Use line_design_flex first → grab flex_json → pass to line_send_message as { message: { flex_json, alt_text } }

• Or pass { message: { template, data } } directly to line_send_message — the same templates are reused.

Examples:

• "ออกแบบคูปอง 20% หมดวันที่ 31 ส.ค." → { template: "voucher", data: { title: "ส่วนลดวันแม่", code: "MOM20", discount: "ส่วนลด 20%", valid_until: "31 ส.ค. 2026" } }

• "ดูว่ามี template อะไรบ้าง" → { list_templates: true }

Create a new LINE audience by uploading user IDs (or IFAs). After creation LINE indexes the audience for ~5-10 minutes — line_list_audiences will report status=IN_PROGRESS during that window, then READY.

This is the "CSV from Google Sheets → retargeting audience" flow most Thai SMBs need.

Args:

• name: Audience name (≤120 chars).

• user_ids: Array of LINE user IDs (max 10,000 per call).

• is_ifa: True for IFA values instead of LINE user IDs (default false).

• oa: optional OA id.

Returns: { audience_group_id, name, type, created_unix_ms }

Region note: Audience Management API is gated to JP / TW / TH OAs (+ premium).

Examples:

• "สร้าง audience ลูกค้าเดือนก่อน" → { name: "buyers_last_month", user_ids: [...] }

Create a LINE audience from people who clicked or opened a previous broadcast / narrowcast. The killer "retarget without a CRM" tool.

Args:

• name: New audience name.

• source_request_id: request_id from a previous line_send_message call (saved in its return value).

• type: 'clicks' (default) or 'opens'.

• click_url: optional — limit to a specific clicked URL (for 'clicks' only).

• oa: optional OA id.

Returns: { audience_group_id, name, type }

Notes:

• LINE requires the source message to be ≥24 hours old before the engagement audience is reliable.

• Minimum ~50 users for the audience to be usable in narrowcast.

• Region-gated to JP / TW / TH (+ premium).

Example workflow:

1. line_send_message(..., target: narrowcast) → save request_id

2. Wait 24h

3. line_build_audience_from_engagement({ source_request_id, type: 'clicks' })

4. line_send_message(..., target: { audience: 'new-engagement-audience' })

List audience groups on the OA. Audiences created via LINE OA Manager UI (e.g. chat-tag audiences, friend-path audiences, web-traffic audiences) also appear here — even though those types cannot be CREATED via Messaging API.

Status meanings:

• READY: usable in narrowcast immediately

• IN_PROGRESS: still indexing — wait ~10 minutes

• FAILED: creation failed; recreate

• EXPIRED: aged out; recreate

Args:

• status_filter: 'all' (default) | 'READY' | 'IN_PROGRESS' | 'FAILED' | 'EXPIRED'.

• name_contains: optional substring filter (case-insensitive).

• limit, page: pagination (default 20/page).

• oa: optional OA id.

Returns: { total: number, count: number, page: number, audiences: [{ audience_group_id, name, status, audience_count?, created, type? }], has_more: boolean }

Examples:

• "ดู audience ที่พร้อมส่ง" → { status_filter: "READY" }

• "หา audience ชื่อ vip" → { name_contains: "vip" }

Delete an audience group. Irreversible — requires confirm=true.

Args:

• audience_group_id: numeric ID (from line_list_audiences).

• confirm: must be true to proceed.

• oa: optional OA id.

Returns: { success: true, deleted_id }

Generate a digest of LINE OA performance over a date range. Bundles 8+ Insight API calls into a single Thai-friendly markdown report.

Args:

• range: One of 'today' | 'yesterday' | 'this-week' | 'last-week' | 'this-month' | 'last-month', or { from: "YYYY-MM-DD", to: "YYYY-MM-DD" }. Default 'last-week'.

• oa: optional OA id.

• response_format: 'markdown' (default) | 'json'.

Returns (structured): { oa_id, range: { from, to, preset? }, delivery: { total, daily: [{ date, broadcast, multicast, push, reply, total }] }, followers: { latest_count?, follow?, unfollow?, net_gain? }, demographic_available: boolean, quota: { used, total, percentage_used }, notes: string[] // T-2 data lag note, privacy-floor note, etc. }

Notes:

• LINE insight data has a T-2 lag (yesterday is the latest reliable date).

• Insight is masked below the ~20-user privacy floor; report surfaces this.

• Demographic only populated when the OA has enough consented friends.

Examples:

• "สรุปสัปดาห์ที่แล้ว" → range: 'last-week'

• "ดูข้อมูลเดือนนี้" → range: 'this-month'

• "วิเคราะห์ 1-15 พ.ค." → range: { from: '2026-05-01', to: '2026-05-15' }

Fetch per-broadcast engagement stats for a specific request_id: impressions, opens, clicks, CTR, and per-URL click breakdown.

Args:

• request_id: From a prior line_send_message return value.

• oa: optional OA id.

• response_format: 'markdown' (default) | 'json'.

Returns (structured): { request_id, delivered?: number, unique_impression?: number, // null if below ~20-user privacy floor unique_click?: number, ctr_percent?: number, per_url_clicks: [{ url, click, unique_click }], notes: string[] // T-1 lag note, privacy-floor note }

Important caveats (surfaced in notes):

• 24-hour data lag — stats stabilize ~T+1 after send.

• Below ~20 unique users, LINE returns null for privacy.

• Available only for narrowcast / multicast / broadcast (not reply / push to single user).

Quick health check of a LINE Official Account: friend count, monthly quota usage, webhook status, and current default rich menu. Aggregates 4 LINE API calls into one card.

Use this as the first call of a session — every other tool decision (whether to send, schedule, switch OA, etc.) benefits from knowing current quota and webhook state.

Args:

• oa (string, optional): OA id from multi-OA config. Default = active OA.

• response_format ('markdown' | 'json'): Output format. Default 'markdown'.

Returns: Structured object: { oa: { id, display_name, picture_url? }, friends?: number, // omitted if not retrievable quota: { used, total, remaining, percentage_used }, webhook: { active, url? }, default_rich_menu?: { id, name? }, region?: string, health: 'OK' | 'WARNING' | 'ERROR', warnings: string[] }

Examples:

• "ดูสถานะ OA หน่อย" → call with no args

• "Status ของ Client A" → { oa: "client_a" }

Estimate how many quota messages a planned send will consume — without actually sending. Useful before user confirmation, especially for narrowcast / broadcast.

Args:

• target: Same shapes as line_send_message ({ user_id } | { user_ids } | { audience } | { filter } | { everyone: true }).

• message_count: How many message objects in the send (1-5, default 1). LINE charges per message * recipients.

• oa: optional OA id.

Returns: { estimated_recipients?: number, // known exactly for user_id(s); approximate for audience; unknown for filter/everyone estimated_cost_messages?: number, // recipients * message_count quota: { used, total, remaining, percentage_used }, cost_share_percent?: number, // estimated_cost / remaining notes: string[] }

Notes:

• For target.audience: we look up audience_count via line_list_audiences first.

• For target.filter or target.everyone: exact estimation isn't possible from API alone — we surface "unknown" and recommend a dry_run via line_send_message instead.

Ping the OA's webhook URL from LINE servers and report HTTP status + latency. LINE checks that the endpoint returns 200 within their timeout AND that signature verification works (when secret is configured).

Args:

• override_endpoint: optional public HTTPS URL to test instead of the configured one.

• oa: optional OA id.

Returns: { success: boolean, status_code: number, latency_ms?: number, reason: string, // LINE's human-readable result detail?: string, configured_endpoint?: string, tested_endpoint: string }

Common failure modes (LINE returns them via 'reason'):

• INVALID_REPLY: webhook responded but the response shape is unexpected

• UNAUTHORIZED: signature verification failed (your code uses wrong channel_secret)

• SERVER_ERROR: webhook returned 5xx

• TIMEOUT: webhook took >10s

• SSL_ERROR: HTTPS cert problem

Use this whenever a bot stops responding before debugging anything else.

LIFF lifecycle CRUD. Four modes:

• create: New LIFF app. Requires config.view (type + url).

• list: List all LIFF apps on the channel.

• update: Modify an existing LIFF app. Requires liff_id + partial config.

• delete: Remove a LIFF app. Requires liff_id + confirm=true.

Args:

• mode: 'create' | 'list' | 'update' | 'delete'.

• liff_id: required for update / delete.

• config: full for create, partial for update.

• confirm: required true for delete.

• oa: optional OA id.

Auth note: LIFF Server API uses LINE Login channel tokens — V1 uses the same Messaging API token for simplicity. For separate-channel setups, see docs.

Examples:

• "สร้าง LIFF tall https://my.app" → { mode: "create", config: { view: { type: "tall", url: "https://my.app" } } }

• "ดู LIFF apps ทั้งหมด" → { mode: "list" }

Generate a working LIFF SDK init code snippet for the requested framework and features. The output is paste-ready and includes feature-detection guards (e.g., scanCodeV2 only on LINE 14+, iOS 14.3+).

Args:

• framework: vanilla | react | next-app-router | vue | svelte. Default 'vanilla'.

• features: array from [getProfile, scanCode, shareTargetPicker, sendMessages, openWindow, permission, getIDToken]. Default ['getProfile'].

• liff_id_placeholder: string to use where the LIFF ID goes. Default 'YOUR_LIFF_ID'.

• typescript: emit TypeScript (default) or plain JavaScript.

Returns: { framework, features, language: 'ts' | 'js', code: string, // copy-paste ready install_command: string, notes: string[] }

Generate a working LINE Login OAuth 2.1 flow scaffold (authorize URL + token exchange + verify + userinfo + optional refresh + optional friendship check) for your backend framework.

This replaces 10 separate OAuth tool calls with one paste-ready code block — Claude Code's superpower.

Args:

• framework: express | nextjs-route-handlers | fastify | hono. Default 'express'.

• scopes: ['profile', 'openid', 'email']. Default ['profile', 'openid'].

• with_pkce: emit PKCE S256 helpers (recommended; default true).

• with_friendship_check: include /friendship/v1/status call (default false).

• with_refresh: include refresh-token route (default true).

• typescript: emit TypeScript (default) or JavaScript.

Returns: { framework, scopes, code: string, env_vars_required: string[], notes: string[] }

The emitted code uses placeholders:

• LINE_LOGIN_CHANNEL_ID

• LINE_LOGIN_CHANNEL_SECRET

• REDIRECT_URI

Fetch a LINE user's profile (display name, picture, status message, language) by user ID.

Note: Only works if the user has added the bot as a friend AND has not blocked it AND has consented to share profile (per LINE TOS). Returns 404 ambiguously if any of these conditions fail — we surface a clear Thai-language explanation.

Args:

• user_id: LINE user ID (typically starts with 'U').

• oa: optional OA id.

• response_format: 'markdown' (default) | 'json'.

Returns: { user_id, display_name, picture_url?, status_message?, language? }

Page through every user that has added the OA as a friend.

⚠️ Region-gated: only TH / JP / TW OAs with premium tier can use this endpoint. Other OAs will get LINE 403.

Args:

• page_size: 1-1000 (default 300).

• continuation_token: token from previous call (cursor pagination).

• oa: optional OA id.

Returns: { user_ids: string[], count: number, has_more: boolean, next_continuation_token?: string }

For very large OAs (50k+), prefer creating an engagement audience via line_build_audience_from_engagement rather than pulling all IDs.

List all LINE Official Accounts available to this MCP instance, from the multi-OA config file (or single-OA env mode). Useful before line_use_oa to discover the OA IDs.

Args:

• response_format: 'markdown' (default) | 'json'.

Returns: { active_oa: string, oas: [{ id, display_name?, region?, is_premium?, is_active }] }

Switch which OA all subsequent tool calls default to (until changed or process restarts). In-memory only — does not edit ~/.line-mcp/config.json.

Args:

• oa_id: OA id from the multi-OA config (use line_list_oas to discover).

Returns: { active_oa, display_name }

Agency feature — run any read-only line_* tool across many OAs in parallel. Errors on individual OAs are isolated (one bad token doesn't break the whole run).

Supported tools (read-only only for V1 safety):

• line_get_oa_status

• line_get_oa_report

• line_list_audiences

• line_list_rich_menus

• line_test_webhook

Args:

• tool: One of the supported tool names.

• oa_ids: Array of OA ids, or 'all' (default).

• parallel: Max concurrency 1-10 (default 5).

• response_format: 'markdown' (default) | 'json'.

Returns: { tool, count_ok, count_failed, results: [{ oa_id, oa_name, success, summary }], errors: [{ oa_id, error }] }

Examples:

• "เช็คสถานะทุก OA" → { tool: "line_get_oa_status", oa_ids: "all" }

• "ทดสอบ webhook ทุก client" → { tool: "line_test_webhook" }

Coupon CRUD on a LINE OA. Four modes:

• create: Make a new coupon. Requires data: { title, description, valid_from, valid_to, ... }

• list: List all coupons.

• get: Fetch a specific coupon by coupon_id.

• discontinue: End a live coupon (irreversible — requires confirm=true).

Rate limit: shared bucket 200 req/sec with multicast.

Args (varies by mode):

• mode: 'create' | 'list' | 'get' | 'discontinue'

• coupon_id: required for get / discontinue.

• data: required for create.

• confirm: required true for discontinue.

• oa: optional OA id.

Examples:

• "สร้าง coupon ส่วนลด 20% MOM20 ใช้ได้ถึง 31 ส.ค." → { mode: "create", data: { title: "คูปองวันแม่", coupon_code: "MOM20", valid_from: "2026-08-01", valid_to: "2026-08-31" } }

• "ดู coupons ทั้งหมด" → { mode: "list" }

• "ปิด coupon C123" → { mode: "discontinue", coupon_id: "C123", confirm: true }

Read available stats for a LINE coupon. We combine multiple signals because LINE's Coupon API does not (yet) expose a dedicated redemption-events endpoint:

1. Raw coupon detail (LINE GET /v2/bot/coupon/{id}) — some accounts include usage fields inline.

2. Click-audience size (if you pass click_audience_id) — proxies "users who clicked through".

Args:

• coupon_id: ID of the coupon (from line_manage_coupon mode='list' or mode='create').

• click_audience_id: optional numeric audience id to enrich the report.

• oa: optional OA id.

• response_format: 'markdown' (default) | 'json'.

Returns (structured): { coupon_id, raw: {...whatever LINE returned about the coupon...}, click_audience?: { id, name, audience_count, status }, estimated_redemptions?: number, notes: string[] // explains data sources clearly }

Notes:

• For an accurate redemption count, build your coupon Flex with a postback action and listen for postback events via a webhook server (V2 webhook-server companion).

• Click audience size approximates "clickthroughs", not actual redemptions — surface this caveat to the user.