Safe MCP Skill version manager with security scanning - detect updates, parallel testing, smart merge, auto security audit
This server defines 9 tools with explicit input schemas and descriptions visible in src/svc/mcp/server.ts. However, several critical gaps prevent a higher score: (1) Parameter descriptions are sparse, most tools accept a 'name' parameter with only 'Name of the skill' as documentation, which does not explain format constraints, required naming conventions, or what constitutes a valid skill name. (2) Output schemas are completely undocumented, the server returns JSON-stringified text responses but never declares what fields or structure the client should expect. This forces LLMs to parse free-form JSON and guess at field names. (3) Error handling is minimal, many tools return a boolean success flag or generic 'not found' without recovery guidance. (4) Tool descriptions lack context about when to use each tool versus alternatives (e.g., svc_download_update vs svc_switch_version). (5) Parameters like 'type' in svc_switch_version have enums ('official', 'custom', 'merged') but lack explanation of what each means or when to use each. These gaps align with common community server patterns but fall short of production quality.
Check for available updates for skills
Download a new version without replacing current
Get merge conflicts for a skill
Get detailed information about a specific skill
Get all local versions of a skill
List all managed MCP skills
Merge official new version with custom changes
Output schemas are completely undocumented. All tools return JSON-stringified text with no declared field structure. LLMs cannot determine what fields to expect or plan downstream calls.
Parameter descriptions lack specificity. 'Name of the skill' does not explain format constraints, whether names are case-sensitive, or what characters are valid. LLMs cannot determine how to construct valid inputs.
Enum parameter 'type' in svc_switch_version lacks explanation. What is the difference between 'official', 'custom', and 'merged'? When should each be used? Description does not clarify.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Rollback a skill to its previous version
Switch to a specific version of a skill
Error handling is minimal. Boolean success/failure or generic 'not found' messages do not guide LLM recovery. No clear categorization of retryable vs user-fixable errors.
Tool descriptions lack disambiguation. svc_download_update vs svc_switch_version both manage skill versions but descriptions do not explain when to use each. LLMs may pick the wrong tool.
No pagination or result-limiting documented. svc_list_skills and svc_get_versions may return unbounded lists. No limit or offset parameters visible. Large result sets could exhaust context windows.
Tool descriptions do not indicate whether operations are write/reversible/read-only in the description text itself. LLMs must infer from the name. Risk annotation is missing from the tool definitions (toolAnnotations=false).