MCP server for integrating with Relation API to manage customers, tickets, and templates
Server has 5 tools with basic schemas and descriptions in Japanese. Critical gaps: (1) get_customers has empty input schema ({}), scoring 0 for schema; (2) descriptions are non-English and very short (10-20 chars), below the 50-200 char LLM-optimized baseline; (3) no error handling guidance, errors return generic 'Failed to search customers' with no recovery hints; (4) no output schemas documented; (5) no parameter validation or constraints (e.g., per_page 1-50 stated in description but not enforced); (6) create_customer lacks confirmation/dry-run for destructive operation. Naming is acceptable (verb_noun pattern), but descriptions are too terse and non-English, limiting LLM comprehension.
顧客を作成します
顧客情報を取得します
顧客を検索します
テンプレートを検索します
チケットを検索します
get_customers has empty input schema ({}). Tool cannot accept any parameters, making it non-functional for filtering or pagination. Schema score must be 0.
All descriptions are under 30 characters and in Japanese. LLM-optimized descriptions should be 50-200 chars in English, explaining WHAT the tool does, WHEN to use it, and any prerequisites. Current descriptions ('顧客情報を取得します') are too terse for LLM selection.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., customer_id for chaining). Responses are raw JSON dumps without field documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Error handling returns generic messages ('Failed to search customers') with no recovery guidance. Per pattern:recovery-guide, errors should tell the LLM what to do next (e.g., 'Try search_customers() with a partial name').
create_customer is a destructive operation (WRITE) with no confirmation step or dry-run. Agents can accidentally create duplicate customers. Per pattern:confirmation-request, irreversible operations should support confirmation.