The LINE MCP server defines 3 tools with complete input schemas and descriptions, but has significant gaps in error handling, output documentation, and parameter constraints. All tools are properly named with action verbs (send_, get_, get_), and descriptions are present but minimal. However, the server lacks idempotent hints, error recovery guidance, output schemas, and comprehensive parameter documentation. Error handling returns raw JSON from LINE API without structured guidance. No pagination or result limiting is present despite potential for returning large message histories. This is a typical community server with basic functionality but production gaps.
Output schemas undocumented. Tools return JSON.stringify() of raw LINE API responses without documenting what fields to expect or how to extract relevant data for downstream operations.
No pagination or result limiting for line_get_group_history. The 'count' parameter has no bounds (minValue/maxValue), allowing unbounded requests that could exhaust context windows or timeout.
Error responses lack recovery guidance. When fetch fails or LINE API returns an error, the tool returns raw error JSON without actionable next steps (e.g., 'Try verify_group_id first' or 'Invalid token, check LINE_CHANNEL_ACCESS_TOKEN').
Document output schemas for all three tools. Example: 'Returns { groupId: string, displayName: string, iconUrl: string, members: number } from LINE API group summary endpoint.' This lets LLMs extract the right fields and plan follow-up calls.
Add destructiveHint annotation to line_send_group_message so agents know this is a write operation that cannot be undone. Use { inputSchema: { ..., additionalProperties: false }, destructiveHint: true }.
Add bounds to 'count' parameter: minValue=1, maxValue=100, default=10. Document in description: 'Number of messages to retrieve (1 - 100, default 10). LLM requesting >100 will be capped.'
Enhance error responses with recovery guidance. For example: if line_send_group_message fails with 'Invalid group ID', return 'Group not found. Try calling list_groups() to see available groups, or verify the group_id format (should be alphanumeric).'
Expand tool descriptions to 100 - 200 characters, including when to use each tool. Example: 'Send a text message to a LINE group. Use this to notify group members of important updates. Requires group_id and message text. Returns message send status.'
Add a dry-run or confirmation step for destructive operations. Propose a tool like 'confirm_send_message' that requires explicit approval before actually calling line_send_group_message.
Validate group_id format before calling LINE API. If invalid, return a clear error: 'Invalid group_id format. Must be a LINE group identifier (e.g., C1234567890abcdef...). Check list_groups() for valid group IDs.'
Score history
Overall score trend
↑ 9 points across a rubric change (v1 → v2)
49/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
49
2026-07-28+
v2
2026-03-09
F
40
-
v1
Missing tool annotations (destructiveHint, readOnlyHint, idempotentHint). line_send_group_message is a destructive write operation but has no annotation signaling this to the agent.
Parameter 'count' in line_get_group_history has no type constraints, minValue, or maxValue. Description says 'default: 10' but schema does not reflect this default. LLM cannot determine valid range or what 'count' actually means (messages? seconds? bytes?).
Descriptions are too generic and lack context for LLM selection. 'Get profile information of a LINE group' does not explain when this tool should be used vs other tools, what data it returns, or what group_id should be.
No validation of group_id format or availability before calling LINE API. A misspelled or invalid group_id returns raw API error rather than guiding the LLM to search for available groups.
LINE_CHANNEL_ACCESS_TOKEN is checked at startup but expiration or invalidation at runtime is not handled. If the token expires mid-session, all tools fail with confusing API errors instead of a clear 'Authentication expired' message.
Distinguish between retryable errors (e.g., rate limit, timeout) and permanent ones (e.g., invalid token, group not found) in error responses. Return { error, retryable: boolean, recoveryHint: string } so agents know whether to retry or abandon.
Add a list_groups or describe_groups tool so agents can discover available groups before calling send_group_message. This prevents wasted calls and dead-ends on invalid group IDs.
Strip verbose metadata from LINE API responses. Return only { groupId, name, iconUrl, memberCount, createdAt } rather than dumping the entire API response, which may include internal fields and waste tokens.