Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vhe-deploy-mcp Compare my production site files with local changes for example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English · Downloads · Licença MIT
Deploy website files with an AI assistant or CLI: preview changes, create verified backups, and transfer files over SFTP/FTPS using Model Context Protocol (MCP).
Comandos oficiais: vhe-deploy e vhe-deploy-mcp. A marca identifica a ferramenta, sem limitar o provedor de hospedagem. Mudança de nome e configuração.
Gerencie arquivos de sites pelo domínio completo cadastrado: compare versões, gere uma prévia, faça backup e envie alterações verificadas. A implementação Python oferece CLI e servidor MCP local via stdio, com SFTP/FTPS, identidade do servidor validada, credenciais separadas da configuração e publicação desativada por padrão.
Pré-versão: 0.1.0a2. Pacotes portáteis e checksums. Gerencie sites em provedores com SFTP/FTPS compatíveis com os requisitos documentados; não administra painel de revenda, DNS, e-mail ou bancos de dados. Não há FTP sem criptografia na implementação Python.
A skill e os scripts PowerShell anteriores permanecem disponíveis, com suas dependências Windows/WinSCP/DPAPI: guia legado. Instalar o Python não substitui essa skill automaticamente.
Requer Python 3.11+ e Git. Com pipx já instalado:
git clone https://github.com/herlonventura/vhe-deploy-sftp-ftps-mcp.git
cd vhe-deploy-sftp-ftps-mcp
pipx install .
vhe-deploy configurarO assistente pergunta domínio, protocolo, servidor, porta, usuário, pastas e provedor da senha. Não depende de FileZilla. A senha é digitada em prompt oculto no terminal quando se usa keyring/age; nunca no chat, no YAML ou em argumento. Sem fingerprint SFTP confirmada ou cofre disponível, o cadastro permanece pendente. O assistente não conecta nem envia arquivos.
Não há publicação no PyPI: use o repositório ou o wheel dos artefatos; pipx install vhe-deploy sem um caminho não é o procedimento desta entrega.
Configuração MCP: Claude Desktop, Cursor, Zed, VS Code, Continue e Codex
Migração da skill antiga: metadados, sem exportar senhas DPAPI
Related MCP server: cloud71 MCP connector
CI da pré-versão 0.1.0a2: sete jobs verdes, Windows X64/Linux X64/macOS ARM64 com Python 3.11 e 3.14, mais Docker. Foram 498 testes por ambiente, com cobertura de instruções e ramos entre 94,96% e 95,26%. Testes adicionais verificaram pip/pipx, os novos comandos e binários PyInstaller, com prévia CLI, envio MCP, backup e rejeição de token reutilizado contra SFTP/FTPS locais.
Item | Evidência e limite |
CLI e MCP stdio | Cliente oficial do SDK, processos reais e servidores locais SFTP/FTPS |
Windows, Linux e macOS | Matriz executada; outras versões/arquiteturas e WSL não foram testados |
Credenciais age | Criptografia real com identidades temporárias |
Cofres nativos | Cofre real Windows validado com credencial fictícia e MCP instalado; Linux/macOS simulados |
Aplicativos de IA | Codex App Server reconheceu as sete ferramentas; interfaces e aprovações ainda não homologadas |
Docker | Build, usuário não-root, CLI, age e MCP stdio; sem deploy a hospedagem real |
Falhas e recuperação | Concorrência, processo interrompido, registro parcial, backup preservado e retomada com conflito |
Ensaio operacional posterior | Envio, download e restauração em SFTP real com hashes e backups conferidos; limites |
Detalhes dos testes · Matriz de distribuição · Registro das oito etapas e pendências.
Validação adicional Windows/Codex: backup automático somente dos arquivos substituídos, envio de arquivo novo, token sem reutilização e remoção da credencial temporária. A retenção automática mantém os três últimos envios concluídos por domínio, preservando backups completos e falhas. Comparação por hash ainda exige leitura dos arquivos remotos.
vhe-deploy list
vhe-deploy info exemplo.com.br
vhe-deploy test exemplo.com.br
vhe-deploy compare exemplo.com.br
vhe-deploy backup exemplo.com.br
vhe-deploy preview exemplo.com.brlist e info leem configuração local; as demais ações acima acessam o servidor. Execute somente a ação pretendida para o domínio correto. Aliases: listar, configurar, testar, comparar, previa, enviar e migrar. Opções, códigos de saída e fluxo completo.
Cada cadastro fixa pasta local e raiz remota. Por padrão, configuração e estado ficam em ~/.vhe-deploy. Use --sites, --settings e --state-dir antes do subcomando para caminhos próprios. Não coloque essas pastas dentro da publicação ou do Git.
Para enviar, é necessário habilitar conscientemente publish_enabled no site e nas configurações globais, gerar a prévia e revisar o plano. Somente depois da autorização:
vhe-deploy deploy exemplo.com.br --preview-hash HASH_DA_PREVIA --preview-token TOKEN_DA_PREVIA --confirmOs marcadores devem ser substituídos pelo resultado da prévia; não são valores utilizáveis. O token vale cinco minutos, é vinculado ao domínio/plano e tem uso único. Não o publique em Git/logs/scripts. Mudança no plano bloqueia o envio. Token e confirm não provam consentimento humano: o cliente continua responsável por respeitar a autorização do usuário.
O cliente inicia vhe-deploy-mcp e se comunica pelo stdin/stdout. Não existe porta HTTP/SSE nem configuração universal para todos os aplicativos. Os exemplos por cliente usam caminhos absolutos e não contêm senhas.
Ferramenta | Operação |
| Lista metadados locais |
| Autentica e confere a raiz remota |
| Compara conteúdo e datas |
| Gera plano, hash e token quando não há bloqueios |
| Baixa arquivos e verifica hashes |
| Envia a prévia autorizada com hash, token e confirmação |
| Cria cadastro novo desativado, sem senha nem confiança de identidade |
O formato operacional é {status, data, messages}, com success, conflict, partial ou error. A IA deve apresentar a prévia, preservar as aprovações do cliente e examinar falhas antes de tentar novamente. O MCP não recebe senha nem permite habilitar publicação/confiança pelo cadastro. Contrato MCP.
/mcplocaweb/dominio.com.br é uma convenção da skill legada, não um comando de barra universal fornecido pelo servidor MCP.
Fingerprint SSH confirmada antes de autenticar; FTPS valida TLS no controle e nos dados. Não há aceitação automática de chave ou modo TLS inseguro.
Segredos ficam no provedor explicitamente escolhido: keyring, age ou ambiente, sem fallback automático. Ambiente é texto em memória; não é criptografia.
Arquivos bloqueados incluem .env, chaves, wp-config.php, .git e backups. Regras adicionais não retiram bloqueios mínimos. Isso não detecta todos os segredos embutidos em HTML/JS.
Arquivo diferente com data remota igual/mais recente, incluindo tolerância de dois segundos, bloqueia o lote. Não existe --force para ignorar conflitos.
Todos os originais a substituir são copiados/verificados antes do primeiro upload. Cada envio é lido novamente para conferir SHA-256. Arquivos só remotos são preservados; não há exclusão remota.
A publicação escreve no arquivo ativo, sem transação por site ou rollback automático. Leitores podem observar conteúdo parcial; travas locais não bloqueiam outras máquinas/aplicações. FTPS exige condições administrativas adicionais.
Backup cobre arquivos, não banco de dados, permissões ou snapshot simultâneo. Em partial, timeout ou interrupção, siga recuperação; repetir o comando não equivale a restaurar.
No Windows, arquivos privados herdam ACLs, que esta ferramenta não configura/audita. Proteja cadastros, chaves, snapshots, recibos, backups e logs. Não sincronize o estado de autorização entre máquinas.
Configuração e credenciais · Limites dos transportes.
Em um venv, instale requirements-dev.txt. A suíte usa servidores em loopback, credenciais fictícias e pastas temporárias:
python -m pip install -r requirements-dev.txt
python -m pytest -q --ignore=tests/test_distribution.py --cov=vhe_deploy --cov-branch --cov-fail-under=81Para os testes criptográficos, instale age/age-keygen ou configure VHE_DEPLOY_TEST_AGE; sem eles, há skips. Os testes de distribuição precisam dos comandos empacotados e rodam separadamente pelo procedimento em distribuição. Não execute testes contra cadastros reais.
A documentação da etapa 8 não executou migração de produção nem configurou aplicativos locais. A validação adicional cobriu o cofre real Windows e a descoberta no Codex App Server. PyPI, homologação das interfaces dos aplicativos, cofres reais Linux/macOS permanecem pendentes; não confunda a conclusão das oito etapas com essas validações adicionais.
Revise o diff antes de publicar: nunca inclua cadastros reais, credenciais, .dpapi, .age, identidades, recibos de token, exportações FileZilla, conteúdo de clientes, logs ou backups. .gitignore é uma ajuda, não garantia contra vazamentos.
Licenciado sob a MIT, copyright 2026 Herlon Ventura. Uso, modificação e redistribuição são permitidos conforme seus termos. As dependências mantêm suas próprias licenças.
Baixa backup verificado para a pasta privada configurada; não altera o servidor.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes | |
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, destructive, and idempotency hints. The description adds useful behavioral context beyond those hints: the backup is downloaded to a configured private folder, is verified, and does not alter the server. It does not contradict the annotations, though it omits details about overwrite behavior or verification semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the main action front-loaded and a semicolon clause adding a valuable safety constraint. Every word earns its place and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description adequately covers purpose, destination, and the key safety trait of not changing the server. Not explaining the verification process or prerequisites is a minor gap but not critical given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema property coverage is 0% and the description never mentions the 'domain' parameter, so it adds no semantic meaning beyond what the field name itself implies. The agent must rely on the tool name and context to infer that 'domain' identifies which site to back up.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Baixa' / downloads), a specific resource ('backup verificado'), and a destination ('pasta privada configurada'), while the clause 'não altera o servidor' clarifies that this is a non-mutating retrieval tool. This scope distinguishes it from sibling tools like deploy_site and preview_deploy, which imply server changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is appropriate when a verified backup is needed without server modification, but it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives. An agent must infer the usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compara arquivos locais/remotos; não emite autorização de envio.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes | |
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a useful specific behavioral guarantee: it does not issue send authorization, which clarifies that no deployment trigger is involved. This does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the primary behavior front-loaded and a useful restriction in the second clause. Every word earns its place; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with an output schema and strong annotations, the description covers the core action and a key constraint. However, the lack of parameter semantics and explicit sibling differentiation leaves the tool only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain what 'domain' means or how it relates to local/remote file comparison. The parameter name and maxLength=253 provide some hint, but the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Compara arquivos locais/remotos') and adds a boundary ('não emite autorização de envio'), which distinguishes it from deployment-oriented siblings like deploy_site. It is not a tautology, but it does not explicitly name the exact comparison target or criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The negative clause 'não emite autorização de envio' implies this is a safe comparison action rather than a deploy, but the description does not explicitly say when to use it versus alternatives such as deploy_site or preview_deploy. Usage context must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Envia somente a prévia autorizada. Exige token, hash, publicação habilitada e confirm=true após autorização explícita do usuário. Não exclui arquivos remotos. Após sucesso, mantém os três últimos envios concluídos por domínio e remove as cópias locais dos mais antigos; preserva backups completos e falhas.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| confirm | No | ||
| preview_hash | Yes | ||
| preview_token | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes | |
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint=true annotation, the description clarifies that remote files are not deleted, that the last three successful uploads per domain are kept, and that old local copies are removed while full backups and failures are preserved. This adds substantial behavioral detail absent from the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: first the core action, then prerequisites, then non-destructive behavior, then retention policy. Each sentence contributes essential information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need no description. The description covers prerequisites, destructive behavior, retention of the last three uploads, preservation of backups/failures, and the non-destructive nature regarding remote files, giving an agent what it needs to deploy correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It maps well to preview_token, preview_hash, and confirm by stating that a token, hash, and confirm=true are required, and mentions publication must be enabled. However, it does not explain the domain parameter or the precise relationship/meaning of the hash and token beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Envia somente a prévia autorizada' (sends only the authorized preview), clearly stating a specific verb and resource. It differentiates from siblings like list_sites and backup_site, but does not explicitly distinguish itself from preview_deploy, leaving some potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: a token, a hash, enabled publishing, and confirm=true after explicit user authorization. It implies that the tool should only be used for authorized previews, but it does not state when to prefer preview_deploy or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista os domínios cadastrados, sem senhas ou conexão.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes | |
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context by stating that the result excludes passwords and connection information, which is useful for agents expecting credentials. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence in Portuguese that front-loads the action and includes the key exclusion. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with an output schema and annotations covering safety, the description is fully sufficient. It clarifies the returned resource (domains) and what is excluded (passwords, connection), leaving no critical gap for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0), so the schema already covers everything. The description adds nothing about parameters because none exist. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lista os domínios cadastrados' (lists registered domains) and adds 'sem senhas ou conexão' (without passwords or connection), making the action and resource explicit. It is clearly distinct from siblings like deploy_site or test_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: it lists domains. However, it does not explicitly state when to use this over alternatives or mention any exclusions beyond what it lists. Given the sibling set, more explicit routing would help, but the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula prévia e token de uso único válido por 5 minutos. Mostre a prévia ao usuário antes de enviar.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes | |
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the token is single-use and valid for only 5 minutes, and that the preview must be shown to the user first. This is useful behavioral context and does not contradict the readOnly or destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core outcome front-loaded and the user-facing instruction included with no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description covers the preview/token workflow well. However, the complete lack of guidance on the 'domain' parameter leaves a real gap for an agent preparing the call, making the description barely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the sole 'domain' parameter, its accepted values, or how it is used. The description adds no meaning beyond the parameter name and type constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Calcula') and names a concrete resource ('prévia e token de uso único') with a clear validity constraint. This distinguishes it from deploy_site and other siblings by framing it as the preview/token-generation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Mostre a prévia ao usuário antes de enviar' implies a pre-deploy workflow, but it never explicitly states when to choose this tool over siblings like deploy_site, nor does it provide exclusions. The usage is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cadastra domínio novo, desativado e sem senha. Fingerprint/CA e habilitação de envio devem ser configuradas localmente.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | ||
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes | |
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no positive annotations, the description carries the burden of behavioral disclosure. It usefully states that the new site is created disabled, without a password, and that fingerprint/CA and publish enablement are local configuration concerns. However, it does not disclose duplicate handling, idempotency, or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The primary action and resource are front-loaded, followed by the key state and prerequisite information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has a complex nested config and no positive annotations. The description is too minimal: it omits duplicate behavior, idempotency, credential requirements, and how the local configuration should be performed. An agent would likely need to inspect the schema and guess at edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for ca_file/ssh_fingerprint and publish_enabled via 'Fingerprint/CA e habilitação de envio', and 'sem senha' hints at credential handling. But it does not explain the required config fields like host, user, remote_root, and local_root, leaving significant parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Cadastra' (registers) with a clear resource, 'domínio novo', and adds the initial state 'desativado e sem senha'. This clearly distinguishes it from siblings like deploy_site, backup_site, and test_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for registering a new domain and states a prerequisite: fingerprint/CA and send enablement must be configured locally. However, it does not explicitly mention when to use this tool versus alternatives or what happens if the domain already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Testa autenticação e raiz do domínio cadastrado, sem envio.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| status | Yes | |
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds a key behavioral detail: 'sem envio' (no send/request made), which conveys that the tool does not perform any external network call. This clarifies the read-only nature beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys purpose and a key behavioral trait. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations and no output schema, the description sufficiently covers the core purpose and read-only nature. The only minor gap is that it doesn't specify what the test result means (e.g., success/failure), but given the tool's simplicity and annotations, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema only gives the parameter name and format constraints. The description references 'domain cadastrado' (registered domain), implying the 'domain' parameter must be a previously registered domain, adding context beyond the schema. However, it doesn't provide detailed semantics like expected format or examples, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('test'), resource ('authentication and domain root'), and explicitly states it does not send anything ('sem envio'), distinguishing it from other actions. It does not explicitly differentiate from siblings, but the read-only, no-send nature is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a diagnostic/pre-flight check (testing authentication and domain root), and the 'sem envio' clause suggests it is safe to call. However, it does not explicitly state when to use this tool versus alternatives (e.g., list_sites) or when not to use it, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0backup_sitecompare_sitedeploy_sitelist_sitespreview_deployregister_sitetest_connectionScored across 7 tools
Each tool targets a distinct action (listing, testing, comparing, previewing, backing up, deploying, registering) with no overlapping responsibilities. The descriptions clearly differentiate their purposes, preventing agent misselection.
All tool names follow a consistent verb_noun pattern in snake_case (list_sites, test_connection, compare_site, preview_deploy, backup_site, deploy_site, register_site). The naming is predictable and adheres to a single convention.
With 7 tools, the server is well-scoped for a deployment workflow. Each tool serves a clear function without redundancy, fitting comfortably within the ideal range for a domain-specific server.
The tools cover the core deployment lifecycle: registration, connection testing, comparison, preview, backup, and deployment. Minor gaps exist (e.g., no explicit update or delete site operation), but the essential workflow is fully supported.
Deploy and manage Jade Hosting projects from AI clients. Jade account and OAuth required.
Publish a site your AI built to paid hosting, then read it back, change a page or restore a version.
Deploy files, sites, and Dockerfile apps to live URLs + private drives for agent memory.
Manage Laravel Forge servers, sites, and deployments from your AI assistant.