Desktop app to manage MCP servers, Skills, and Sub-Agents for Claude Code
This MCP server exposes 29 tools for managing MCPs, Skills, Sub-Agents, and Hooks. While tool names follow verb_noun conventions and schemas are properly defined in JSON Schema, the implementation has critical gaps in parameter descriptions and error handling. Most tools lack detailed descriptions of what they return, error conditions, and when to use them over similar tools. Many parameters have minimal documentation (e.g., 'MCP name' vs 'The unique identifier of the MCP server to load tools from; use list_available_mcps to discover available servers'). Output schemas are not documented, forcing LLMs to guess structure. Error recovery guidance is absent. The server implements HTTP transport with custom Rust/Axum framework, but lacks key MCP spec patterns like tool annotations (readOnlyHint, destructiveHint), Multi-Round-Trip Request support, and per-request logLevel. Security considerations for credential handling are not evident. Overall, this reads as a functional but unpolished tool gateway lacking production-grade LLM-readiness patterns.
Assign an MCP to a project
Execute a tool on a specific MCP server. The MCP must be connected first via load_mcp_tools.
Create a new hook
Create a new MCP in the library
Create a new skill
Create a new sub-agent
Delete a hook
Output schemas not documented. LLMs cannot determine what fields to expect from tool responses, forcing unstructured output parsing and increasing hallucination risk. No return types documented for any of the 29 tools.
Parameter descriptions are generic and lack actionable guidance. 'MCP name' and 'The MCP ID' provide no context on format, constraints, or dependencies. Descriptions should explain what happens, when to use the tool, and what constraints apply (e.g., 'The unique name of the MCP server; discover available names via list_available_mcps').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Delete an MCP from the library
Delete a skill
Delete a sub-agent
Disable an item globally
Disable an MCP globally
Enable an item globally
Enable an MCP globally
Get details of a specific hook
Get details of a specific MCP
Get details of a specific skill
Get details of a specific sub-agent
List all MCP servers available through this gateway. Call this first to discover what MCPs you can use.
List all hooks in the library
List all MCPs in the library with optional filtering by type or search term
List all skills in the library
List all sub-agents in the library
Load and return all tools from a specific MCP server. The MCP will be connected if not already. Call this after list_available_mcps to see what tools an MCP offers.
Remove an MCP from a project
Update an existing hook
Update an existing MCP
Update an existing skill
Update an existing sub-agent
Destructive tools (delete_mcp, delete_skill, delete_subagent, delete_hook) lack confirmation/dry-run patterns and error recovery guidance. No indication that these operations are irreversible or how to undo them. Agents need clear warnings and alternatives.
No tool annotations present. Tools lack readOnlyHint, destructiveHint, and idempotentHint tags. The MCP spec (2026-07-28) requires these for proper tool categorization. Agents cannot determine which tools are safe to retry or which mutate state.
Generic enable/disable tool names ambiguous. 'enable_item_globally' and 'disable_item_globally' violate naming clarity. What is an 'item'? Is it an MCP, Skill, Sub-Agent, or Hook? LLM cannot determine which tool to call. Replace with explicit tools: enable_mcp_globally, enable_skill_globally, etc.
No error handling documentation. Tools do not describe failure modes, error categories (retryable vs. user-fixable vs. fatal), or recovery steps. When create_mcp fails, does the LLM retry, ask the user to fix input, or give up? No guidance provided.
Pagination support missing from list tools. list_mcps, list_skills, list_subagents, list_hooks have no limit/offset/page parameters or total_count in response. Large result sets will blow context window; LLM has no way to iterate.
Composite operations combine multiple concerns. create_mcp accepts 'headers' (auth) and 'env' (configuration) as free-form objects. These should be validated, sanitized, and documented with examples of safe patterns (e.g., 'API key must be set via environment variable, not in headers object').
Tool dependencies not documented. load_mcp_tools 'loads and connects' an MCP, but tools do not explain: Must call list_available_mcps first? What happens if you call call_mcp_tool without loading? Is the connection persistent or per-call?
Ambiguous similar tool names. get_mcp, list_mcps, load_mcp_tools all return MCP information but with different purposes. Descriptions do not clarify: When use get_mcp vs list_mcps? What is the difference between 'loading tools from an MCP' and 'getting MCP details'?