Skip to main content
Glama

Dockhold

by eu.dockhold
OverviewDiscussionsAdmin

Deploy an app

deploy_app

Deploy a GitHub repository as a live web app on Dockhold. Call this when the user wants to put an app online, get a shareable HTTPS URL, or host a demo. Returns the new app id. Two paths: a PUBLIC repo needs only repo_url; a PRIVATE repo needs repo_url plus github_installation_id (call list_github_repos first, each repo comes with the installation_id to pass here). Deploying a private repo turns on auto-deploy: future pushes to that repo redeploy the app automatically. The app builds and comes online automatically; poll get_app_status to watch it. Set memory_mb to size the app's compute, one of the values get_resource_usage reports under compute.steps_mb: 256 MB fits a static site or a small API, 512 MB fits a typical Node or Python web app, and anything that holds data in memory needs more. Omit it and the app gets the minimum slice (256 MB) so it doesn't take your whole compute pool; resize_app changes the size later with no rebuild, applied as a rolling update that replaces the app's instances. The response reports memory_mb (what this app got) and compute_available_mb (what's left in your pool), so size the next app off that. This tool needs a GitHub repo URL: if the code only exists locally (no repo), it cannot be used here, and the user should run npx dockhold login then npx dockhold deploy in the project folder instead. Requires a token with the deploy scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesA name for the app (1-64 chars)
repo_urlYesGitHub repository URL, e.g. https://github.com/owner/repo. Public repos deploy with this alone; a private repo also needs github_installation_id.
memory_mbNoCompute size in MB for this app, one of the values get_resource_usage reports under compute.steps_mb. Omit to get the minimum slice (256 MB); resize_app changes it later with no rebuild.
with_databaseNoProvision a managed Postgres database for the app (default false)
github_installation_idNoRequired for PRIVATE repositories. Get it from list_github_repos — each repo comes with the installation_id to pass here. Omit for public repos.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / memory_mb
      Added value: +{
+  "description": "Compute size in MB for this app, one of the values get_resource_usage reports under compute.steps_mb. Omit to get the minimum slice (256 MB); resize_app changes it later with no rebuild.",
+  "type": "integer"
+}
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, it discloses important side effects: deploying a private repo enables auto-deploy on future pushes, the app builds and comes online automatically, and memory is taken from the user's compute pool. It also explains the rolling-update behavior of a later resize and the required deploy token scope, giving an agent a clear model of the operation's real-world impact.

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 long but information-dense, and every sentence adds decision-relevant context. It is front-loaded with the core purpose and trigger conditions, then flows through private repos, auto-deploy behavior, memory sizing, local-code alternatives, and authentication. There is no filler or repetition.

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?

For a mutation tool with no output schema, the description covers the key operational context an agent needs: what triggers it, what it returns, how to monitor progress, how to size compute, how to handle private vs. public repos, how to recover from local-only code, and what auth scope is required. The optional with_database parameter is already documented in the schema and does not weaken completeness.

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%, the description adds substantial meaning: it explains the public vs. private repo distinction for repo_url, tells the agent to source github_installation_id from list_github_repos, provides concrete memory sizing guidance (256 MB for static sites, 512 MB for typical Node/Python apps, more for in-memory data), and clarifies the memory_mb response semantics. This goes well beyond the raw 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 opens with a specific verb and resource: 'Deploy a GitHub repository as a live web app on Dockhold.' It also lists concrete trigger intents ('put an app online, get a shareable HTTPS URL, or host a demo') and states it returns the new app id, making it easy to distinguish from siblings like redeploy_app or deploy_group.

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?

The description explicitly says when to call the tool: when the user wants to take an app online, get a URL, or host a demo. It also gives exclusion guidance: local-only code cannot use this tool and should use `npx dockhold login` and `npx dockhold deploy` instead, and private repos require calling list_github_repos first to obtain the installation ID.

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

All Dockhold toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources