Design memory & guidance for product teams — manages design principles, tenets, elements, Figma components, and design tokens with structured critique and review capabilities
This server has moderate-to-good definition quality with clear tool names and structured schemas. All 9 tools are explicitly registered with input schemas and descriptions. However, there are systematic gaps: (1) descriptions are brief but acceptable (mostly 60-120 chars), lacking the depth and context that LLMs need for confident tool selection; (2) several parameters lack descriptions or constraints (e.g., 'asset' object in add_mood_asset has nested properties but minimal guidance on required vs optional fields); (3) error handling is absent from visible code, no recovery guidance, no input validation documentation, no actionable error messages; (4) output schemas are not documented anywhere, forcing LLMs to infer what each tool returns; (5) no WRITE operations document idempotency or confirmation requirements. Tool names are strong (verb-first, unambiguous). The codebase shows Zod validation hints but error messages are not visible. Schemas are present but incomplete, many nested objects lack full type clarity.
Tools (9)
add_mood_assetwritesource verified67/100
Add an asset (image/link) to a project's moodboard
Output schemas not documented for any tool. LLMs cannot infer return value structure, forcing them to guess what fields are available for downstream tool chains. This breaks composition patterns.
Nested object parameter 'asset' in add_mood_asset lacks field-level descriptions and clarity on required vs optional fields. The object schema shows properties but no descriptions for id, uri, title, tags, notes, LLMs will guess at structure.
No error handling guidance in any tool. Code does not show recovery strategies, input validation messages, or actionable error text. LLMs cannot self-correct on failures.
Document the output schema for every tool. For add_note, log_decision, upsert_principle: return {id: string, created_at: string, project_id: string}. For search_guidelines: return {results: [{type: string, id: string, title: string, body: string, relevance_score: number}], total: number, query: string}. For get_component_details: return {name: string, id: string, description: string, variants: [...], tokens: [...]}. For generate_documentation: return {files: [{uri: string, name: string, type: string}]}. For review_figma: return {findings: [{category: string, severity: string, message: string, principle: string}], summary: string}.
Expand tool descriptions to 60-120 characters with actionable context. Example for add_mood_asset: 'Add an image, link, or asset to a project moodboard for visual inspiration. Use this before creating principles to gather design references.' Example for search_guidelines: 'Search all design principles, tenets, and elements by keyword. Returns structured results with relevance scoring. Call this to discover existing guidelines before creating new ones.'
Add field-level descriptions to nested object parameters. For add_mood_asset.asset, document: 'id (required, string): Unique identifier for the asset. uri (required, string): URL or file path to the asset. title (optional, string): Display name for the asset, 1-100 chars. tags (optional, array): Categorization tags for filtering. notes (optional, string): Internal notes, 0-500 chars.'
Add error handling and recovery guidance to tool descriptions. Example: 'If a project is not found, call search_projects() first. If sync_tokens fails due to Figma API limits, wait 60 seconds and retry with force_refresh=false to use cached tokens. Returns error_code 'invalid_token' if design-tokens.json format is corrupted, restore from version control before retrying.'
Score history
Overall score trend
↑ 10 points across a rubric change (v1 → v2)
58/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
58
2026-07-28+
v2
2026-03-09
F
48
-
v1
sync_tokenswriteauthsource verified77/100
Pull design tokens from Figma and write to project design-tokens.json
upsert_principlewritesource verified77/100
Create or update a principle in project principles.json
Destructive/write operations (add_note, log_decision, upsert_principle, add_mood_asset, sync_tokens, generate_documentation) do not document idempotency, confirmation steps, or side effects. Agents may retry operations without knowing if they are safe.
add_mood_asset description is only 32 characters, below the 50-char minimum guideline. Lacks context on when to use, expected asset format, or return structure.
Several read-only tools (search_guidelines, get_component_details, review_figma) do not document pagination, result limits, or how many items are returned. Large result sets may blow context windows.
generate_documentation does not clarify output format (single markdown string vs file URIs vs structured JSON) or where generated files are stored. Agent cannot chain output to downstream tools.
generate_documentation
Document idempotency and confirmation requirements for write operations. Example for log_decision: 'This operation is idempotent, calling it twice with the same title and project_id will update the existing decision, not create a duplicate. However, concurrent calls may race; consider a confirm_decision step before final commit.' Example for sync_tokens: 'This operation overwrites design-tokens.json. Consider backing up the existing file before calling with force_refresh=true.'
Add pagination and result limits to read-only tools. Example for search_guidelines: 'Accepts limit (1-50, default 20) and offset (0+) parameters. Returns total count for paging. Capped at 1000 results, use filters or narrower queries for large result sets.' Example for get_component_details: 'Returns up to 50 variants and 50 design tokens per component. For larger component libraries, call list_component_variants(component_id) separately.'
Clarify output for generate_documentation: 'Returns a list of generated markdown files, one per token/component/overview. Each file is written to project/docs/ and includes a URI for reading or embedding in downstream tools. Example: [{uri: 'project/docs/overview.md', name: 'overview', type: 'text/markdown'}]. The generated markdown is also suitable for passing directly to an LLM for further refinement.'
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to signal operation safety to clients. Mark search_guidelines, get_component_details, review_figma with readOnlyHint=true. Mark add_note, log_decision, upsert_principle, add_mood_asset, sync_tokens, generate_documentation with destructiveHint=true (they modify state). Mark upsert_principle with idempotentHint=true (safe to retry).
Add input validation constraints to parameter descriptions. Example for upsert_principle.id: 'Principle ID, 1-64 alphanumeric chars + hyphens. Must be unique within project. Snake_case preferred (e.g. primary_colors, spacing_8px).' Example for search_guidelines.query: 'Search query, 2-100 chars. Supports partial matching and tag filtering (e.g. 'color:primary accessibility').'
For tools accepting project_id, document project discovery. Add a note: 'If you don't have a project_id, call list_projects() first to see available project identifiers.' Consider accepting project_name as an alias and resolving it internally.