Loading ToolBench
LINE Summary MCP Server. Reads LINE PC wxSQLite3-encrypted .edb to list chats, retrieve message history, and access contacts.
The server implements 4 tools with STDIO transport (hard cap applies). Tool names follow verb_noun convention (line_list_chats, line_get_history, line_get_unread, line_get_contacts) and are reasonably clear. Descriptions are present and moderately detailed (100-300+ chars), explaining what each tool does. However, several critical gaps reduce the score: (1) Parameter descriptions in the schema view are minimal (e.g., 'Fuzzy match on chat name (optional)' is brief; no format constraints or ranges); (2) Output schemas are documented only in docstrings, not in machine-readable form ('Returns: [{chat_id, name, type, last_message_at}]'); (3) No error handling guidance, what happens if chat_id is invalid, if since/until are malformed, or if the DB is locked? (4) No parameter constraints (enums for chat_type, ranges for limit/page sizes); (5) ISO 8601 parsing has custom validation but LLMs cannot see the exact format requirement without reading implementation; (6) line_get_unread has a detailed disclosure in its docstring about lazy loading and missing_count, but this critical context is in the docstring, not the parameter/return descriptions visible to LLMs. Overall: functional definitions with room for LLM-facing refinement.
Get LINE contacts for name resolution.
Get LINE chat message history.
List LINE chats that have unread messages. Reading is passive: this reads the local encrypted DB and never contacts LINE's servers, so it does NOT send a read receipt or mark anything read.
List LINE chats: personal, group, multi-person, official account, open chat.
Output schemas not machine-readable. Tool docstrings document returns as prose ('Returns: [{chat_id, name, type, ...}]') rather than JSON Schema. LLMs cannot parse these to plan downstream operations. For example, if line_list_chats returns chat_id, LLMs need to know the exact field name and type to pass it to line_get_history.
Parameter constraints missing. chat_type in line_list_chats accepts 'personal', 'group', 'multi', 'official', 'open' but these are not declared as an enum constraint, only documented in text. limit and per_chat_limit lack min/max ranges. LLMs may hallucinate invalid values or pass unbounded numbers.
ISO 8601 parsing requirements not in parameter descriptions. line_get_history requires 'since' and 'until' in ISO 8601 with timezone (e.g., 2026-06-15T00:00:00+08:00). The parameter description says 'ISO 8601 with timezone, e.g. 2026-06-15T00:00:00+08:00', good, but _parse_iso8601() will reject values without explicit timezone offset or 'Z'. This format constraint should be explicit in the schema, not just text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
No error handling guidance for LLMs. If line_get_history receives an invalid chat_id, what error is returned? If the DB is locked or corrupted, what should the agent do next? If _parse_iso8601() rejects a timestamp, the error message 'Invalid ISO 8601 (must include timezone offset)' is good, but this is internal, not exposed via tool error contract.
line_get_unread disclosure buried in docstring. The tool has a detailed, honest explanation about lazy loading, available_count vs missing_count, and limitations around read boundaries, but this is in the Python docstring, not in the LLM-visible parameter or return descriptions. LLMs may not see or understand these critical caveats, leading to misuse.
No pagination support in tool definitions. line_list_chats and line_get_contacts accept a 'limit' but there is no offset, page, or cursor parameter to fetch additional results. If an agent needs all chats but limit=50 is the default, it cannot iterate to page 2. The description should clarify: does this tool support pagination, or does it always return up to limit results and no more?