Public assessment

helbertparanhos/easypanel-mcp-server (easypanel-mcp-server)

easypanel-mcp-server · v2.0.0 · scanned Aug 2, 2026

What changed in the harness

Selection accuracy 100→100, token cost up 5%, unconfirmed writes 0%→0%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

0.0 / 30

0.0 out of 30

02Legibility

18.0 / 30

18.0 out of 30

03Economics

14.8 / 20

14.8 out of 20

04Discoverability

11.4 / 20

11.4 out of 20

Highest-impact fix

Estimated gain +30 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

31 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`create_project`	name_restates_behavior no_return_description	Cria um novo projeto vazio no Easypanel para agrupar serviços — nome apenas com letras minúsculas, números, hífens e underscores. Retorna os dados do projeto recém-criado.
`delete_project`	no_return_description	⚠️ DESTRUTIVO — Remove permanentemente o projeto e TODOS os seus serviços e dados. Irreversível. Requer confirm: "CONFIRMO". Retorna uma confirmação de que o projeto foi removido.
`create_service`	no_return_description	Cria um novo serviço de app (ainda sem source configurada) em um projeto e retorna os dados do serviço criado. Após criar, configure a source com set_source_github ou set_source_image.
`rename_service`	no_return_description	⚠️ Renomeia ou move um serviço. Webhooks, DNS e referências internas que usam o nome antigo deixarão de funcionar. Requer confirm: "CONFIRMO". Retorna os dados atualizados do serviço com o novo nome e/ou projeto.
`destroy_service`	no_return_description	⚠️ DESTRUTIVO — Remove permanentemente o serviço e seus dados. Irreversível. Requer confirm: "CONFIRMO". Retorna confirmação de que o serviço foi removido.
`deploy_service`	no_return_description	Dispara o deploy do serviço com a configuração atual. Usa o source configurado (GitHub, image, dockerfile). Funciona para serviços app E compose — detecta o tipo e roteia para o namespace certo (não precisa saber de antemão se é compose). Retorna os dados da ação de deploy disparada, que pode ser acompanhada via get_action ou list_actions.
`start_service`	no_return_description	Inicia um serviço que está parado. Funciona para app e compose (em compose, equivale a um redeploy/compose up). Retorna o status atualizado do serviço após o início.
`stop_service`	no_return_description	⚠️ PARA o serviço em produção. Usuários não conseguirão acessar enquanto parado. Requer confirm: "CONFIRMO". Retorna o status atualizado do serviço após ser parado.
`restart_service`	no_return_description	Reinicia o serviço. Causa breve indisponibilidade. Funciona para app E compose — em compose, reinicia via redeploy (docker compose up recria os containers). Retorna os dados da ação de restart disparada.
`set_service_notes`	no_return_description	Salva notas/anotações no serviço (markdown suportado), substituindo o conteúdo anterior. Retorna as notas salvas para confirmação.
`set_service_resources`	no_return_description	Define limites e reservas de CPU e memória do serviço. Envie só os campos que quer alterar — os omitidos mantêm o valor atual (0 = sem limite). Memória em MB, CPU em núcleos (0.5 = meio núcleo). Aplica no próximo deploy/restart. Retorna a configuração de recursos atualizada do serviço.
`set_source_github`	no_return_description	Configura a source do serviço para um repositório GitHub. O repo deve estar conectado no Easypanel (Settings > GitHub). Retorna a configuração de source atualizada do serviço.
`set_source_image`	no_return_description	Configura a source do serviço para uma imagem Docker. Retorna a configuração de source atualizada do serviço.
`enable_github_deploy`	no_return_description	Ativa o auto-deploy via GitHub: a cada push no branch configurado, um deploy é disparado automaticamente. Retorna o status atualizado da configuração de auto-deploy do serviço.
`disable_github_deploy`	no_return_description	Desativa o auto-deploy via GitHub. Deploys precisarão ser disparados manualmente. Retorna o status atualizado da configuração de auto-deploy do serviço.
`set_env_var`	no_return_description	Adiciona ou atualiza UMA variável de ambiente. Lê o estado atual antes de escrever — não apaga outras variáveis. Retorna a lista atualizada de variáveis de ambiente do serviço.
`delete_env_var`	no_return_description	⚠️ Remove UMA variável de ambiente. Lê estado atual antes de escrever. Requer confirm: "CONFIRMO". Retorna a lista atualizada de variáveis de ambiente após a remoção.
`add_domain`	no_return_description	Adiciona um domínio customizado ao serviço com HTTPS automático via Let's Encrypt. Retorna os dados do domínio criado, incluindo seu ID.
`remove_domain`	no_return_description	⚠️ Remove permanentemente um domínio. O tráfego para esse host parará de funcionar. Requer confirm: "CONFIRMO". Retorna confirmação de que o domínio foi removido.
`set_primary_domain`	no_return_description	Define qual domínio é o primário (usado como URL principal do serviço). Retorna a lista de domínios atualizada com o domínio primário marcado.
`create_database`	no_return_description	Cria um serviço de banco de dados (Postgres, MySQL, MariaDB, MongoDB ou Redis) em um projeto. Retorna os dados do serviço criado, incluindo as credenciais de acesso geradas.
`destroy_database`	no_return_description	⚠️ DESTRUTIVO — Remove o banco de dados e TODOS os seus dados permanentemente. Irreversível. Requer confirm: "CONFIRMO". Retorna confirmação de que o banco foi removido.
`prune_docker`	no_return_description	Executa um "docker system prune" no servidor inteiro via Easypanel: remove containers parados, redes sem uso, cache de build e imagens não referenciadas para liberar espaço em disco. ⚠️ Ação destrutiva e de escopo GLOBAL (afeta todos os projetos do servidor, não um serviço específico) — exige confirm: "CONFIRMO". Use cleanup_docker_images para uma limpeza mais leve (só imagens não usadas). Retorna um resumo do espaço em disco liberado e dos recursos removidos.
`cleanup_docker_images`	no_return_description	Remove do servidor apenas as imagens Docker não utilizadas (dangling/sem container), liberando espaço sem mexer em containers, redes ou volumes. Operação mais leve e segura que prune_docker — imagens podem ser recriadas em um novo deploy. Escopo global do servidor. Retorna um resumo das imagens removidas e do espaço liberado.
`create_mount`	no_return_description	Adiciona um volume/mount a um serviço para persistir dados entre deploys. Use type 'volume' para volume nomeado gerenciado, 'bind' para mapear um caminho do host. Aplica no próximo deploy. Retorna a configuração de mounts atualizada do serviço.
`create_port`	no_return_description	Publica uma porta de um serviço no host (port mapping), expondo-a externamente sem passar pelo proxy/domínio. Útil para TCP/UDP brutos (bancos, jogos, etc). Aplica no próximo deploy. ⚠️ Portas privilegiadas (publishedPort < 1024, ex: 80/443/22) exigem confirm: "CONFIRMO". Retorna a configuração de portas atualizada do serviço.
`create_compose`	no_return_description	Cria um novo serviço do tipo Docker Compose (ainda sem arquivo compose definido) em um projeto e retorna os dados do serviço criado. Depois use set_compose_file (via trpc_raw) ou o painel para definir o docker-compose, e deploy_compose para subir.
`deploy_compose`	name_restates_behavior no_return_description	Sobe um serviço Docker Compose executando 'docker compose up' com o arquivo compose e a configuração atuais, recriando os containers definidos. Retorna os dados da ação de deploy disparada, que pode ser acompanhada via get_action ou list_actions.
`restart_panel`	no_return_description	⚠️ Reinicia o próprio Easypanel. O painel/API ficam brevemente indisponíveis; os serviços hospedados continuam rodando. Requer confirm: "CONFIRMO". Retorna confirmação de que o reinício do painel foi disparado.
`reboot_server`	no_return_description	⚠️ CRÍTICO — Reinicia o SERVIDOR inteiro (máquina host). TODOS os serviços e o painel ficam fora do ar até o boot completar. Use apenas em manutenção planejada. Requer confirm: "CONFIRMO". Retorna confirmação de que o reinício do servidor foi disparado.
`trpc_raw`	no_return_description	Chama diretamente qualquer procedure tRPC do Easypanel (~347 em 43 namespaces) não coberta pelas tools dedicadas. Use para recursos avançados: traefik., branding., cloudflareTunnel., box., mariadb., volumeBackups., databaseBackups.*, etc. Leitura (isMutation=false) é o padrão. ⚠️ Reads podem retornar dados sensíveis (env vars/secrets de qualquer projeto). Para escrita, passe isMutation:true E confirm:"CONFIRMO" — mutations arbitrárias pulam as proteções das tools curadas. Retorna o payload bruto (JSON) devolvido pela procedure chamada, cujo formato varia conforme o namespace/procedure.

Selection evidence

Confusable tool pairs.

16 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`get_exposed_ports`	`list_ports`	high	Both list port information for a service; list_ports' own description says it 'complementa get_exposed_ports', so a task like 'what ports does this service use' could plausibly route to either.
`get_docker_stats`	`get_service_stats`	high	Both return CPU/memory metrics for containers; a request like 'show CPU usage for my-app' could be answered by filtering get_docker_stats (all containers) or calling get_service_stats (per-service), and the agent must correctly infer scope.
`deploy_service`	`deploy_compose`	high	deploy_service's description explicitly states it 'funciona para serviços app E compose... não precisa saber de antemão se é compose', directly overlapping deploy_compose's purpose for compose services.
`inspect_service`	`inspect_database`	medium	A database is created as a service via create_database; a task like 'inspect my postgres service' could plausibly be routed to either inspect_service or inspect_database depending on whether the agent treats it as a generic service or a typed database.
`destroy_service`	`destroy_database`	medium	Databases are a kind of service; 'delete my postgres service permanently' could be resolved via the generic destroy_service or the type-specific destroy_database, both destructive with confirm requirements.
`get_service_error`	`get_service_logs`	medium	Both are used to debug a failing service; a vague task like 'why is my service failing' doesn't clearly indicate whether the last recorded error or full runtime logs are wanted.
`get_service_logs`	`get_build_logs`	medium	Both return 'logs' for a service; a task like 'check the logs, my deploy is broken' is ambiguous between runtime container logs and build/deploy logs.
`get_system_stats`	`get_storage_stats`	medium	get_system_stats already includes disk metrics alongside CPU/memory/network, so a task like 'check disk usage on the server' could be answered by either tool.
`get_docker_stats`	`get_docker_events`	medium	Both relate to investigating docker container activity; a vague task like 'what's going on with my containers' could be misrouted between live resource stats and event capture.
`get_system_stats`	`get_docker_stats`	medium	Both surface CPU/memory metrics ('server health' vs 'per-container'), so a generic resource-usage question could be sent to either.
`create_service`	`create_compose`	medium	A task like 'create a new service for my app' doesn't specify app-type vs compose-type, and both tools create a named service in a project.
`inspect_service`	`inspect_compose`	medium	Both inspect full configuration of a service before changes; if the agent doesn't know whether the target service is a compose type, it may pick the wrong inspector.
`deploy_service`	`restart_service`	medium	Tasks like 'refresh my service' or 'apply the changes' are ambiguous between redeploying with current source config and simply restarting the running container.
`deploy_service`	`start_service`	medium	For a stopped service, 'start my service' could be resolved with start_service or with deploy_service (which also brings up compose/app services), especially since deploy_service doesn't check current state.
`set_source_github`	`set_source_image`	medium	A task like 'set the source for this service' without specifying GitHub repo vs Docker image requires the agent to infer which source-configuration tool applies.
`delete_project`	`destroy_service`	low	Both are irreversible destructive deletions requiring confirmation; a poorly scoped task like 'remove this deployment' could be misapplied at the project level instead of the service level.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard