Skip to main content
Glama

Install managed application

install_application
Idempotent

Queue installation of a catalog application using its version-pinned container blueprint, with chosen access mode and one-time portal secret delivery for asynchronous deployment on VPSnet.

Instructions

Queue installation of a catalog application using its version-pinned container blueprint. Call list_application_catalog first: target.install_requirements.runtime_restart_consent.required tells you whether this server still needs restart consent, and the entry's secret_delivery.one_time_secrets tells you whether the install generates a password shown only once. Confirm the service, application, release channel, access choice, and configuration variable NAMES with the user first; never repeat variable values in confirmation text. For the first managed application on an existing server, acknowledge_runtime_restart may be true only after explicit consent to a possible one-time server restart. This tool always requests portal secret delivery: a generated password is revealed once, to the user, in the VPSnet panel. It is never returned here, and this tool must never claim on the user's behalf to have received and stored it. When the result reports secret_delivery.pending_reveal or a portal handoff, tell the user a password is waiting and send them to the panel. An install left on private access is reachable only from inside the server, not from a browser: when the user wants to open a web-UI application, request an advertised public mode (usually platform_https) in this call, and after the installation reports healthy, read the resulting public endpoint URL from get_application_installation and relay it to the user together with the panel handoff. This is asynchronous and not a paid API-key operation. Requires applications:manage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accessNoExact access request using a mode and fields advertised by the selected catalog entry. Omitting it accepts the platform default: public platform_https when VPSnet platform hostnames are available, otherwise private. private keeps the application reachable only from inside the server, so for an application the user will open in a browser prefer an advertised public mode such as platform_https.
orderNoYesTenant-owned service order number: 1-64 ASCII letters, digits or hyphens, e.g. VP12345 or VP12345-1
confirmedYesTrue only after the user confirmed this installation
variablesNoConfiguration values keyed by the public variable names in the catalog. Values are submitted to VPSnet but never returned by this tool.
applicationYesPublished application slug from list_application_catalog
idempotencyKeyYesClient-global unique key. Reuse it only to replay this exact installation request; never reuse it for another service or request.
release_channelNoPublished release channel. Omit it to install the application's own published channel; most catalog applications are not published on a channel named 'stable', so never guess one.
acknowledge_runtime_restartNoExplicit consent for a possible one-time server restart while the managed runtime is prepared

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.16

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (idempotentHint, destructiveHint=false, openWorldHint), it discloses the asynchronous nature, the auth scope requirement, the one-time password delivery path, the rule that the secret is never returned here, and consent conditions for a runtime restart – rich behavioral context that annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the critical list_application_catalog prerequisite are front-loaded, and most sentences carry actionable instructions. It is long and the secret-delivery rule is restated a few times across sentences, costing some tightness.

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 complex, async, 8-parameter tool with nested objects and no output schema, the description covers the full workflow: prerequisites, consent gating, secret handoff semantics, post-install endpoint retrieval, and success/failure signals like secret_delivery.pending_reveal.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description adds real value: it warns never to guess a release_channel name, explains that omitted access defaults to platform_https-or-private, and clarifies that variable NAMES (not values) are confirmed with the user.

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 opening sentence states a specific verb and resource – 'Queue installation of a catalog application using its version-pinned container blueprint' – and the async framing plus the applications:manage requirement clearly distinguish it from siblings like install_application_recipe, reconcile_application, or update_application.

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 gives explicit prerequisites (call list_application_catalog first, confirm details with the user), conditional guidance (acknowledge_runtime_restart only after explicit consent), and alternatives (request a public mode when the user wants a browser UI, then read the endpoint via get_application_installation). When-to-use is unambiguous.

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