Security-first MCP server for bounded Easypanel operations
Strong security-first design with clear descriptions and proper schema definitions. All 13 tools have descriptions (avg 156 chars, within 10-1024 baseline). Input schemas present with type definitions and parameter descriptions. Tool names follow verb_noun pattern (list_, inspect_, check_, plan_, apply_, change_, get_, rotate_, destroy_). Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are well-applied. Key gaps: output schemas not documented in source; some parameter descriptions could be more prescriptive about constraints; error handling guidance minimal in descriptions.
Apply exactly one stored service plan by hash after current policy, external approval, TTL, and precondition checks.
Return the sanitized Easypanel compatibility profile, logical features, access mode, and project allowlist.
Two-phase typed start, stop, or restart for an app. Stop is critical and requires both external approval and independent confirmation artifacts.
Return a strict readiness projection for one allowlisted service without probing arbitrary URLs or exposing configuration.
Permanently destroy one allowlisted service after approval and confirmation.
Inspect one deployment's status and progress without exposing logs or configuration.
Output schemas not documented in source code. Tool descriptions state what is returned (e.g., 'Return a strict readiness projection', 'Return sanitized deployment summaries') but formal JSON Schema output definitions are not visible. LLMs cannot plan downstream tool calls without knowing response field names and types.
Parameter descriptions lack prescriptive constraints. 'project' and 'service' parameters state they are names but do not specify format, length limits, or character restrictions. 'maxLines' has min/max but no guidance on typical values or performance implications.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Retrieve sanitized deployment or service logs with redaction of secrets and credentials.
Inspect one allowlisted service through a positive projection. Environment values and credentials are never returned.
List sanitized deployment summaries for one allowlisted service.
List only projects in the configured Easypanel project allowlist.
List sanitized service summaries for one allowlisted project.
Create a target-bound desired-state plan. Secret environment values must be supplied by secret reference. Planning never authorizes apply.
Rotate the deployment webhook secret for one allowlisted service.
Error handling guidance absent from tool descriptions. Descriptions do not explain what errors are retryable, what user actions are needed, or how to recover from failures. E.g., 'easypanel_apply_service' mentions 'policy, external approval, TTL, and precondition checks' but does not describe failure modes or recovery paths.
Pagination not documented for list tools. 'easypanel_list_projects', 'easypanel_list_services', 'easypanel_list_deployments' do not expose limit, offset, or cursor parameters. Large result sets risk context window exhaustion.
Tool composition assumes external approval workflow. 'easypanel_plan_service' and 'easypanel_apply_service' are separate, with approval between them, but the tool descriptions do not explain how the agent obtains approval or what the approval interface looks like. This breaks the tool chain for autonomous agents.