Skip to main content
Glama
Sign In
vhe-deploy-mcp

vhe-deploy-mcp

by herlonventura
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

deploy_site

Destructive

Deploy an authorized website preview to a remote server after explicit user confirmation. Uses token and hash, and retains the last three successful deployments per domain.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>",
      "preview_hash": "<preview_hash>",
      "preview_token": "<preview_token>"
    },
    "name": "deploy_site"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainYes
confirmNo
preview_hashYes
preview_tokenYes

Output Schema

NameRequiredDescriptionDefault
dataYes
statusYes
messagesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools