Skyll has solid tool descriptions (150-200 chars) and well-named tools with clear action verbs (search_, get_, add_). However, input schemas lack critical details: parameters are described but many are missing type constraints (enums, min/max for integers), and output schemas are entirely undocumented. All four tools are read-only, reducing complexity, but descriptions could be more action-oriented. No evidence of error handling guidance or recovery patterns. The server is built on fastmcp (current framework) and exposes HTTP transport, placing it in the 'fair to good' range.

• Add explicit JSON Schema constraints to all numeric and string parameters: minValue/maxValue for integers, maxLength/pattern for strings. Example: search_skills.limit should have minValue: 1, maxValue: 20 in the schema, not just in description.
• Document the response structure for each tool. For search_skills, specify: returns array of {name, description, install_count, url, ...}. For get_skill, return {content, references, source, skill_id, ...}. This enables LLM to extract and chain data.
• Add explicit error handling section to descriptions. Example for get_skill: 'If the skill is not found, returns a 404 error. If the source repository is invalid, returns a 400 with message "Invalid GitHub source format. Use owner/repo." Call search_skills() to discover available skills.'
• Clarify 'add_skill' semantics. Does it fetch and return the skill, or does it modify agent state, or both? Rename to 'fetch_skill' or 'get_latest_skill_version' if it only reads. If it modifies state, add a description of the state change.
• Add per-parameter examples that match constraints. For search_skills.query, show valid examples: 'react performance', 'api testing', 'authentication setup', all within the 500-char limit and demonstrating the expected breadth.
• Add a 'dependencies' field to descriptions. Example for search_skills: 'Call this first to discover available skills. Then call get_skill() with the result's skill_id to fetch full content.'
• Validate inputs early and return structured errors. Instead of a bare 500 error, return: {error: 'invalid_query_length', message: 'Query exceeds 500 characters', received_length: 750, max_length: 500}.

Inferred effective spec: 2026-07-28+.

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