Yosegi has 11 tools with consistent verb-noun naming (search_, get_, list_, create_, apply_, validate_, duplicate_, generate_). All tools have descriptions (avg ~120 chars, within baseline 34-392). Input schemas are present with type declarations. However, parameter descriptions are sparse or missing for complex types (e.g., 'root' and 'operations' in create_screen and apply_screen_operations are typed as 'unknown' with minimal guidance). Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages visible. Composition is sound (single responsibility per tool), but chaining support is unclear due to undocumented output structures.

• Document output schemas for all tools. For search_components, specify: { results: [{ id, category, propTypeTokens, slots }], total, nextCursor? }. For get_screen, specify all fields in the screen definition object.
• Replace 'unknown' types with explicit JSON Schema. For 'root' in create_screen, provide a schema reference or inline definition of the screen node structure (e.g., { type: 'component' | 'container', props: {...}, children?: [...] }).
• Add error handling guidance to write operations. E.g., create_screen: 'Returns 409 Conflict if id already exists. Returns 422 if root schema is invalid, check validate_screen first.' apply_screen_operations: 'Returns 409 if baseRevision is stale, fetch current screen and retry with updated revision.'
• Expand parameter descriptions for complex types. For 'operations' in apply_screen_operations, describe the operation format: [{ type: 'set' | 'delete' | 'insert', path: 'jsonPointer', value?: any }].
• Add pagination guidance to search_components. Clarify: 'Results capped at limit (default 50, max 200). Use nextCursor for pagination. Returns total count for UI feedback.'