line-oa-mcp-ultimate

Get LINE OA Status

line_get_oa_status

Read-onlyIdempotent

Check LINE OA health: friend count, monthly quota usage, webhook status, and default rich menu in one call. Aggregates four API calls into a status card to guide send, schedule, or switch decisions.

Instructions

Quick health check of a LINE OA — friend count, monthly quota usage, webhook status, and current default rich menu, aggregating 4 LINE API calls into one card. Good as the first call of a session: current quota and webhook state inform every later decision (send, schedule, switch OA).

Returns { oa, friends?, quota, webhook, default_rich_menu?, region?, health:'OK'|'WARNING'|'ERROR', warnings[] }.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "line_get_oa_status"
  }
}

Input Schema

Name	Required	Description	Default
`oa`	No	Optional OA id from the multi-OA config. Omit to use the active/default OA.
`response_format`	No	Output format. 'markdown' is human-readable; 'json' is structured.	markdown

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.2May 29, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the tool as read-only and idempotent. The description adds detail on aggregating 4 API calls and specifies the return structure with fields like health status and warnings, which provides transparency beyond annotations.

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

Conciseness5/5

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

The description is three sentences, each serving a clear purpose: stating the tool's function, providing usage guidance, and detailing the return structure. No unnecessary words.

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?

Despite lacking an output schema, the description provides a complete return structure and explains how the tool aggregates multiple calls. It fits well within the sibling tool set as a standalone health check.

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

Parameters3/5

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

Input schema coverage is 100% with descriptions for both parameters. The description does not add further semantic detail beyond what the schema already provides, meeting the baseline expectation.

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 defines the tool as a quick health check aggregating friend count, monthly quota usage, webhook status, and current default rich menu into one call. It is distinct from sibling tools like line_get_oa_report or line_audit_user_menu, as it provides a high-level status overview.

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 explicitly recommends using it as the first call of a session because quota and webhook state inform later decisions. It gives clear context but does not list specific exclusions or alternatives.

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

Deploy Server