Server has 19 tools with consistent naming (verb_noun pattern) and descriptions present for all. However, parameter descriptions are sparse or generic, input schemas lack depth (missing min/max constraints, format specs), and output schemas are not documented. Error handling returns basic text responses without recovery guidance. Tool composition is sound but lacks idempotency hints and chaining metadata. Descriptions average ~100 chars (below 194-char baseline), and many parameters lack type constraints beyond basic JSON Schema.

• Document output schemas for all tools. For figma_get_file_data, specify: returns {document: {id, name, children: [...]}, components: [...], styles: [...]}. For figma_get_variables, specify: returns {collections: [{name, variables: [{id, name, value, type}]}]}.
• Add min/max and format constraints to all numeric/enum parameters. E.g., depth: 1 - 10 (default 2), scale: 0.1 - 4 (default 1), limit: 1 - 100 (default 100). Use parameter descriptions to state these explicitly.
• Enhance error responses with recovery guidance. Instead of 'Error: Invalid file key', return 'Invalid file key. Verify the URL or call figma_get_status to check authentication. Available files: [list].'
• Add idempotency declarations to write tools. E.g., figma_post_comment: 'Idempotent if parent_id is provided (replies are deduplicated by parent_id + message hash). Safe to retry.' figma_delete_comment: 'Idempotent, deleting a non-existent comment returns success.'
• Expand tool descriptions to 150 - 250 chars. Include WHEN-to-use context. E.g., figma_get_file_versions: 'Retrieve version history of a Figma file. Use this to compare designs across iterations or revert to a previous version. Returns versions with timestamps and creator info.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry