Skip to main content
Glama
imprezahost

Impreza Host MCP Server

impreza_deploy_custom

Deploy a custom (non-catalog) app to an Impreza VPS using one of three modes: public Docker image, Dockerfile build (from local directory or git repo), or a full docker-compose manifest.

Instructions

Deploy a custom (non-catalog) app to an Impreza VPS. Three modes — pick exactly one: • mode: "image" — public Docker image URL (image: "ghcr.io/user/app:tag"). • mode: "dockerfile" — build from a Dockerfile, sourced from EITHER a local project directory (dir: "/abs/path/to/project"; the MCP tars + uploads it) OR a git repo (git_url). For a private repo set git_auth_method: deploy_key (SSH URL; the response returns git_auth.public_key to add to the repo as a read-only Deploy Key) or pat (https URL + git_pat). • mode: "manifest" — a full docker-compose manifest object (advanced; same schema as catalog apps). Always required: name, agent_id. Use impreza_list_servers to find a valid agent_id. When the customer says "deploy this" with a project open, Dockerfile mode is the right choice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dirNomode=dockerfile: absolute path to a local project dir (tar+uploaded). Use this OR git_url.
cpusNoCPU limit (cores; 1.0 = one core). Default 1.0 server-side.
modeYesSource mode.
nameYesPer-account-unique deploy name (3-100 chars, [a-z0-9_-]).
varsNoEnvironment variables to inject into the container.
imageNoRequired when mode=image. Public Docker image reference.
onionNoAlso publish a Tor v3 hidden service. Default false.
domainNoPublic hostname. Omit when `onion: true` for an onion-only deploy.
git_patNoFine-grained, repo-scoped, Contents:Read token (required with git_auth_method=pat).
git_refNoBranch / tag / commit for git_url (default main).
git_urlNomode=dockerfile: git repo instead of a local dir. https (public, or private with git_auth_method=pat) or SSH like git@github.com:owner/repo.git (deploy_key).
agent_idYesTarget VPS agent_id (from impreza_list_servers).
manifestNoRequired when mode=manifest. Full app manifest object.
memory_mbNoMemory limit in MB. Default 512 server-side.
target_portNoPort the container listens on (default 80).
dockerfile_pathNoOptional Dockerfile path relative to the dir/repo root (default "Dockerfile").
git_auth_methodNoPrivate-repo auth for git_url: none (default), deploy_key (SSH), or pat (token).
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It explains the deployment process (e.g., tars + uploads local dir, returns public key for deploy_key) and covers modes. However, it does not mention whether deployments with duplicate names are overwritten or what happens on failure, so not fully comprehensive.

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 well-structured with bulleted modes, front-loaded with the main action, and uses list formatting for clarity. Every sentence adds essential information, avoiding fluff despite the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 17 parameters, 3 required, and no output schema, the description covers modes, parameter dependencies, and references other tools. It could be improved by mentioning the return value (e.g., deployment details) and handling edge cases like duplicate names, but overall it is quite complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100% (each parameter has a description), the tool description adds significant value by grouping parameters by mode, clarifying relationships (e.g., dir vs git_url for dockerfile mode), and explaining how auth methods work (deploy_key vs pat). It goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deploys a custom app to an Impreza VPS, lists three distinct modes, and differentiates from sibling tools like impreza_deploy_catalog_app by explicitly mentioning 'custom (non-catalog) app'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains when to use each mode (e.g., 'public Docker image URL' for image mode, 'build from a Dockerfile' for dockerfile mode), provides prerequisites (agent_id from impreza_list_servers), and gives explicit guidance like 'when the customer says "deploy this" with a project open, Dockerfile mode is the right choice.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/imprezahost/impreza-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server