Strake-MCP is a read-only design system API with 4 well-named tools following verb_noun convention (list_*, get_*). All tools have descriptions (avg 95 chars, within 10-1024 range) and input schemas with type definitions. However, parameter descriptions are sparse or missing entirely: list_tokens has 'group' and 'query' with descriptions, but get_token's 'name' parameter lacks guidance on format (CSS var vs dotted path is mentioned in tool description, not param description). list_components and get_component have empty input schemas with no parameter descriptions. Output schemas are undocumented, LLMs cannot infer what fields to expect from responses. Error handling is absent from descriptions. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Composition is sound: tools chain naturally (list → get). Naming is clear and action-oriented.

• Document output schemas for all 4 tools. Example for get_token: 'Returns {name: string, value: string, group: string, description?: string}'. For list_tokens: 'Returns {tokens: [{name, value, group, description}], total: number}'.
• Add parameter descriptions to get_token's 'name' param: 'CSS variable name (e.g. "--strake-color-accent") or dotted path (e.g. "color.accent"). Both formats are accepted and resolve to the same token.'
• Add input schemas and descriptions to list_components and get_component. get_component's 'name' param should describe expected format: 'Component name as listed by list_components (e.g. "Button", "Tooltip").'
• Add tool annotations: set readOnlyHint=true and idempotentHint=true on all 4 tools to signal to clients that results are cacheable and safe to retry.
• Add error handling guidance to get_token and get_component descriptions: 'If token/component not found, returns error with available alternatives. Call list_tokens or list_components to discover valid names.'