Loading ToolBench
MCP server for operating a LINE official account from AI agents over MCP
This MCP server exposes 2 tools with CRITICAL definition gaps. Both tools have meaningful descriptions (55-120 chars) and clear input schemas with enums, but lack essential documentation for error handling, response structures, and parameter constraints. The naming is adequate (verb_noun pattern observed), but parameter descriptions are sparse and output schemas are entirely undocumented. No evidence of idempotency, pagination, or recovery guidance. For a production LINE CRM integration, this is significantly below acceptable quality.
Look up a customer in MyService and show their LINE profile, tags, and membership status.
Send a MyService-related notification (appointment reminder, etc.) to a LINE friend.
No output/response schema documentation. Both tools lack documented return types. LLMs cannot plan downstream actions or extract required fields (e.g., customer ID, transaction ID, notification status). This violates pattern:tool and forces agents to guess output structure.
Sparse parameter descriptions. 'send_myservice_notification' has a 'message' parameter marked nullable with description 'Custom message text (required for "custom" type)', but this is contradictory (nullable yet required). The 'friendId' and 'customerId' parameters lack detail on format, length, or examples. Parameter constraints are implicit, not explicit.
No error handling or recovery guidance. Tools do not document failure modes (e.g., customer not found, notification delivery failure, invalid friend ID). Responses should include actionable error messages, retryability classification, and next steps. Currently, agents have no guidance on how to recover from failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
'send_myservice_notification' combines two concerns: notification type selection AND optional customer-based message generation. The tool description does not clarify the interaction between 'customerId' (optional, for auto-generation) and 'message' (optional, for custom text). Ambiguous parameter relationships violate pattern:tool and force agents to guess intent.
Inconsistent nullable semantics. 'message' is marked nullable: true but described as 'required for "custom" type'. This contradicts the schema. If 'message' is conditionally required, the description must explicitly state: 'Required when notificationType is "custom". Omit for other types.' Ambiguity here causes agents to pass null incorrectly.
Missing pagination and result limits. 'lookup_customer' returns customer data, but no schema documents whether results are paginated, how many records are returned, or what fields are included. For a CRM lookup, this is essential, customers may have multiple records, and agents need to understand result boundaries.
No idempotency declaration. 'send_myservice_notification' is a WRITE operation with side effects (sends a message). If agents retry due to ambiguous failures, will notifications be sent multiple times? Tool description must declare: 'Idempotent: safe to retry with identical parameters' or 'Non-idempotent: may send duplicate notifications if retried.'