Skip to main content
Glama
wasintoh

line-oa-mcp-ultimate

by wasintoh

Send LINE Message (universal)

line_send_message

Send LINE messages to users via reply, push, multicast, narrowcast, or broadcast. Supports text, templates, flex, stickers, coupons, images, and videos.

Instructions

Universal LINE sender. Auto-picks the API (reply/push/multicast/narrowcast/broadcast) from the target shape; message shape selects text/template/flex/sticker/coupon/image/video. Feed pre-built objects from line_design_imagemap/line_design_card/line_design_flex via message.message_json; native coupons from line_manage_coupon via message.coupon_id.

mode: send_now (default) sends immediately; draft returns a LINE OA Manager handoff package (URL + Flex JSON + steps) — use when the user wants to SCHEDULE, since the Messaging API can't schedule but the OA Manager UI can; dry_run validates + estimates cost without sending.

Safety: pre-flight /validate before spending quota; Quota Guardian blocks if projected cost >95% of remaining quota unless confirm=true; broadcast { everyone:true } requires confirm=true; quiet-hours 22:00–08:00 BKK warns unless force=true; quiet_push silences the recipient device; reply tokens expire ~1 min (falls back to a push hint).

Returns send_now → { success, transport, request_id?, recipient_count_estimated, quota, warnings[] }; draft and dry_run return their own shapes. Narrowcast needs ~24h before line_get_message_stats shows engagement.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
oaNoOA id (multi-OA). Omit to use active OA.
modeNosend_now (default) sends immediately; draft returns a handoff package for LINE OA Manager UI; dry_run validates + estimates without sending.send_now
forceNoOverride quiet-hours warning (22:00–08:00 BKK). Defaults false; LINE Thai customers prefer not to be pinged at night.
targetYesWho to send to. Pick one shape: { reply_to } | { user_id } | { user_ids[] } | { audience } | { filter } | { everyone: true }
confirmNoRequired to be true when projected cost > 95% of remaining quota, or when target.everyone === true.
messageYesWhat to send. Pick one shape: { text } | { template, data } | { flex_json, alt_text } | { sticker } | { coupon_id }
quiet_pushNoSuppress push notification on recipient device (silent send). Default false.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses numerous behavioral traits beyond annotations, including auto-chunking, quota guardian, broadcast confirmation requirement, quiet-hours warning, reply token expiry fallback, and return value shapes. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with key information and well-structured into paragraphs. While somewhat long, every sentence adds value. It could be slightly more concise but is not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, many options, safety features), the description is comprehensive. It covers return shapes for each mode, includes an example, and notes limitations like narrowcast stats delay. No output schema exists, but the description compensates well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning to parameters by explaining the target shapes, mode behavior, safety parameters, and the use of message_json for pre-built objects. This adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a universal LINE sender that auto-selects the appropriate API and message type based on input shapes. It distinguishes itself from siblings by mentioning integration with design tools and coupon management, and it provides a comprehensive list of capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use different modes (send_now, draft, dry_run) and safety features (confirm, force, quiet_push). It also mentions specific scenarios like quiet hours and quota limits. However, it does not explicitly compare with siblings that could send messages (like rich menus are different but not exhaustive).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wasintoh/line-oa-mcp-ultimate'

If you have feedback or need assistance with the MCP directory API, please join our Discord server