Frontgate defines 8 tools with explicit schemas and descriptions. All tools have verb-noun naming (analyze_, build_, critique_, score_, gate_, get_, list_, add_). Descriptions are present and substantive (100-200 chars typical). However, several parameter descriptions are minimal or missing entirely. Output schemas are not documented in the visible code. Error handling guidance is absent, tools return generic errors without recovery hints. The tool composition is sound (each does one thing), but parameter constraints lack detail (e.g., weights in score_ui_quality accepts any integer 1-100 but doesn't explain what each axis means or how to interpret results).

• Document output schemas for all tools. For each tool, add a 'Returns' section in the description or a separate schema definition showing field names, types, and meanings. Example: 'Returns {score: integer 0-100, axes: {spacing: integer, hierarchy: integer, ...}, recommendations: string[]}'.
• Expand parameter descriptions with constraints and examples. For 'weights' in score_ui_quality, specify: 'Object with axis names as keys (spacing, hierarchy, layout, reuse, density, noise, product_alignment) and integer weights 1-100. Weights are normalized; omitted axes default to weight 50.'
• Add error recovery guidance. When a tool fails, return: 'Error: [specific reason]. Next steps: [actionable suggestion].' Example: 'Path not found. Verify the project_path is absolute or relative to the MCP server's working directory.'
• Define the 'context' parameter structure. Create a type definition or example showing what analyze_ui_context returns, so build_ui_spec and critique_ui_output can document what they expect. This enables tool chaining.
• Add a dry-run or confirmation step to add_visual_reference. Return a preview of the change and require explicit confirmation before writing, or add a 'dry_run' boolean parameter to preview changes.