The server defines 7 tools with schemas and descriptions present, but quality is inconsistent. All tools have basic JSON Schema definitions with type and enum constraints where appropriate. However, descriptions are formulaic (all 8 - 16 characters in Korean), parameter descriptions lack actionable guidance, output schemas are completely undocumented, and error handling is absent. Tool naming follows verb_noun convention (register_, get_, search_, update_) which is correct, but parameter coverage and composition issues reduce overall quality. This is typical of a mediocre community server that has basic structure but lacks production-grade polish.
사용자에게 맞는 화장품을 추천합니다
특정 성분이 포함된 제품들을 찾습니다
사용자의 프로필 정보를 조회합니다
사용자의 피부 정보를 등록합니다
화장품 성분을 검색합니다
화장품 제품을 검색합니다
사용자의 프로필 정보를 업데이트합니다
Descriptions are all under 20 characters and formulaic (e.g., '사용자의 피부 정보를 등록합니다'). Descriptions lack context on WHEN to use the tool, WHAT it returns, and any prerequisites.
No output schema documented for any tool. LLMs cannot plan downstream calls or extract required fields. Response structure is opaque.
Parameter descriptions are minimal or missing actionable constraints. E.g., 'concerns' says '쉼표로 구분: acne,aging,brightening,hydration' but should use an enum instead of free-form string. 'ingredient' in get_cosmetic_recommendations is marked optional but no guidance on when to provide it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No error handling or recovery guidance. When a user_id is invalid, search fails, or ingredient is not found, there is no structured error response telling the LLM what to do next (retry, ask user, try alternative tool).
Tool composition issue: 'concerns' in register_user_skin_info is a free-form comma-separated string ('acne,aging,brightening,hydration') rather than an enum. This invites hallucinated values (e.g., 'pimples' instead of 'acne'). Should be an array of enums.
Source code incomplete. The server.rb file is truncated at the definition of search_ingredients, so full tool registration and handler implementations are not visible.
No pagination or result limit enforcement visible. search_products and search_ingredients could return hundreds of items, but no max_results parameter, limit, or pagination (offset/cursor) is defined.
Chaining risk: get_cosmetic_recommendations returns user-matched products, but there is no visibility into whether the response includes ingredient details needed for downstream calls like get_products_by_ingredient. If not, the LLM must make an extra lookup.