EasyPanel MCP has 11 tools with consistent naming (verb_noun pattern) and descriptions present for all tools. However, parameter descriptions are sparse or missing for many tools, and output schemas are not documented. The three advisory network tools (create_network, delete_network) are misleading, they claim to return guidance but do not actually perform operations, which violates the principle that tool names should convey what happens. Input schemas are visible and typed, but lack depth in parameter constraints (no enums, ranges, or format specifications). Error handling is basic. Security considerations around destructive operations (delete_project) are noted but not enforced via confirmation patterns.

• Rename create_network and delete_network to advise_network_creation and advise_network_deletion (or similar) to clarify they are informational, not operational. Update descriptions to explicitly state 'This tool does NOT create or delete anything, it returns guidance only.'
• Document output schemas for all tools. For list_deployments, specify: returns array of {deployment_id, project_id, service_id, image, status, created_at}. For create_deployment, specify: returns {deployment_id, status, created_at}. This enables LLMs to chain tools correctly.
• Expand parameter descriptions with format and constraint details. E.g., 'project_id (string, UUID format, required)' and 'config (object with keys: environment, replicas, memory_limit, etc.)'. Reference EasyPanel API docs or provide examples.
• Add a confirm_delete_project tool or modify delete_project to require a confirmation_token parameter. Agents must explicitly confirm destructive operations to prevent accidental data loss.
• Declare enums for constrained parameters. E.g., driver: enum [overlay, bridge, host, macvlan]. Add min/max for numeric params (e.g., replicas: 1-100).

Inferred effective spec: 2026-07-28+.

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