Single tool with basic schema and Korean-language description. Tool name 'generate-mock-data' follows verb_noun convention but lacks clarity on output format. Input schema is present with proper types (number, array) and constraints (min/max), but parameter descriptions are minimal and lack format guidance. No output schema documented. Error handling validates Zod schema but provides generic error messages. Tool is read-only and low-risk, but definition quality falls short of production standards.
사용자 지정 필드에 대한 Mock 데이터 생성
Tool description is in Korean ('사용자 지정 필드에 대한 Mock 데이터 생성') and lacks English translation. LLMs trained primarily on English may misinterpret or fail to select the tool. Descriptions should be in English and explain WHAT the tool does, WHEN to use it, and what it returns.
No output schema documented. The tool returns JSON-stringified mock data, but LLMs cannot plan downstream operations without knowing the structure (field names, types, count). Document that output is an array of objects with user-specified fields.
Parameter 'fields' description mentions examples ('name, email, phone, address etc') but does not enumerate all supported field types. LLMs may hallucinate unsupported fields like 'ssn' or 'credit_card'. Replace examples with an explicit enum or comprehensive list.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
Parameter 'count' lacks description of what 'data' means (rows? records? objects?). The description '生成할 데이터 개수 (1-100)' is in Korean and does not clarify the unit. Use English and be explicit: 'Number of mock data records to generate (1-100).'
Error handling returns generic Zod validation errors without recovery guidance. When 'fields' is empty or contains an unsupported field, the error should suggest valid options: 'Invalid field: got "ssn", supported fields are: name, email, phone, address, company, job, city, country.'