The Penpot MCP server demonstrates moderate definition quality with consistent naming patterns and documented parameters. However, there are significant gaps in output schema documentation, parameter descriptions lack depth, and error handling is not visible in the source provided. 15 tools are registered with names starting with action verbs (list_, get_, create_, delete_, search_, rename_, duplicate_), which follows the naming convention baseline (90% of A+ tools). Descriptions are present for all tools (range 50-180 chars, within the 10-1024 baseline) and all input parameters have type declarations and descriptions. However, parameter descriptions are brief and generic (averaging 40-60 chars vs the 72 char baseline), lacking constraint details, format specifications, and dependency hints. The most critical gap: no output schemas are documented for any tool, violating the core pattern that 'LLMs need to know what fields to expect so they can plan downstream tool calls.' All tools return JSON-serialized strings, but the internal structure (field names, types, nesting) is not declared. Additionally, the source code provided is incomplete, tool implementations are imported from separate modules (e.g., `from penpot_mcp.tools.projects import list_teams`) but the actual implementation logic is not visible, preventing verification of error handling, security controls, and data transformation. Given this incomplete visibility, per-tool scores are conservative.

• Document return type schema for every tool. Example: 'Returns array of {team_id: string, team_name: string, member_count: int, project_count: int}'. Include nested object structures and field types.
• Add limit/offset pagination parameters to list_teams, list_projects, list_files, and get_page_objects. Document defaults (e.g., limit=20, offset=0) and maximum values.
• Expand parameter descriptions with format constraints and examples. E.g., 'team_id: UUID string identifying the team (obtain via list_teams first). Format: 32 hex chars.' instead of just 'Filter by team UUID.'
• Define explicit error categories and recovery actions. E.g., 'If team not found, call list_teams() to discover available team IDs. If permission denied, request access from team admin.'
• Add tool annotations to FastMCP tool decorators. Use @mcp.tool(annotations={"readOnlyHint": true}) for read-only tools and destructiveHint for delete_file, rename_file operations.
• Document idempotency for mutation tools. State which operations (create_project, create_file) are idempotent and which (rename_file, delete_file) have irreversible side effects.
• Convert shape_type parameter in get_page_objects to enum: @mcp.tool(input_schema={"shape_type": {"type": "string", "enum": ["rect", "circle", "frame", "text", "group", "path", "image", "svg-raw", "bool"]}})
• Add tool discovery hints. E.g., in list_projects description: 'Call list_teams() first if you need to filter by team. Returns project_id values that can be passed to list_files().'