This MCP server exposes only 2 tools with partial schema visibility. Descriptions themselves are moderately strong (explaining when to call the tool and what it affects), but fall short of LLM-optimized length (200+ chars vs. 50-200 target). Tool composition is reasonable, two focused tools that follow a discovery pattern (get preference → act on update).

• Make tool registration explicit in the Go source code (cmd/mcp-service or equivalent) with visible Tool structs. Include InputSchema and OutputSchema definitions referencing formal JSON Schema objects.
• Add complete output schemas. For get_skill_update_preference, declare a response type with fields: shouldPrompt (bool), reason (enum: disabled|auto_upgrade|snoozed|version_changed|expired|no_snooze|no_latest_version), snooze (object with deadline: ISO8601, remainingSeconds: int), latestVersion (string).
• Add English descriptions (50 - 200 chars) alongside or replacing Chinese descriptions. Focus on WHEN to call and WHY, not implementation details. Example: 'Query the device's update preference and snooze state. Call this before prompting the user about updates to respect their past choices.'
• Add descriptions to all parameters. For 'version' in set_skill_update_preference: 'Target version number (semantic version format, e.g. 1.2.3). Required only when action=snooze.'
• Add error handling and recovery hints. E.g., 'If set_skill_update_preference fails with "invalid_action", call get_skill_update_preference to verify current state before retrying.'
• Use JSON Schema's conditional constraints (if/then in oneOf) to formally express that 'version' is required when action=snooze. This enables client-side validation.
• Consider adding a third tool, get_available_actions, to let agents discover valid actions and allowed transitions without trial-and-error.

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

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API