Local-first React kaomoji drawer and optional MCP server with hidden usage ranking, manual curation and Unicode compatibility hints.
Solid tool definitions with complete schemas and descriptions. All 6 tools have Zod-validated input schemas with type constraints (min/max lengths, enums, defaults). Descriptions are present and contextual (avg ~120 chars). However, several parameter descriptions lack detail (category, limit have null descriptions), and output schemas are not formally documented. Error handling is minimal, tools return JSON but lack recovery guidance. Naming is clear and verb-forward (search, pick, add, remove, favorite, inspect). No security concerns detected (read-only/write/destructive risk levels are appropriate). Composition is sound, each tool has one responsibility and outputs chain-able IDs.
Add a kaomoji to the private local library, merge duplicate values, and classify it into one or more categories.
Change whether an exact kaomoji value is ranked as a favourite.
Check a kaomoji for transport controls, stacked combining marks, rare glyphs, and an optional safer copy without saving it.
Choose from the best matching kaomoji while avoiding immediate repetition, increment its private usage count, and return it for inclusion in the assistant response.
Delete an exact kaomoji value from the private local library.
Search the local kaomoji library by visible face, label, or category. Results are ranked by favourite and hidden usage frequency.
Parameter descriptions incomplete: 'category' and 'limit' have null descriptions across multiple tools (kaomoji_search, kaomoji_pick). LLMs cannot infer parameter meaning from names alone.
Output schemas not formally documented. Tools return JSON via textResult() but LLMs have no schema to understand response structure (e.g., kaomoji_search returns {items: [...]}, kaomoji_pick returns {found, item, useCount, lastUsedAt}). Undocumented outputs force LLMs to infer field names.
Error handling lacks recovery guidance. kaomoji_remove returns {removed: false, reason: 'not_found'} but does not suggest next steps (e.g., 'Try kaomoji_search() to find the exact value'). Bare error codes give agents nothing to act on.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
kaomoji_add uses a custom Zod refine() validator ('Kaomoji must contain a visible character') but does not document this constraint in the parameter description. LLMs cannot read JSON Schema refinements, they rely on description text.
No pagination support. kaomoji_search returns up to 50 items but does not offer offset/cursor or total count. If the library grows large, returning all results wastes tokens and risks context window exhaustion.