Skip to main content
Glama
Sign In
Flux Cloud MCP server

Flux Cloud MCP server

Official
by RunOnFlux
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Wait for a deployment to be accepted and its instances to run

flux_wait_for_app

Polls the network for payment confirmations and spec acceptance, returning running instances with URLs. Call repeatedly until done=true.

Instructions

Polls the network for up to timeoutSeconds (default 300, max 600). Returns payment confirmations, whether the spec was accepted, and the running instances with URLs. Safe to call repeatedly until done=true.

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": {
      "name": "<name>"
    },
    "name": "flux_wait_for_app"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
txidNoPayment txid from flux_deploy_app, to report confirmations.
previousHashNoFor updates: the hash of the previous spec, so acceptance means a new hash.
timeoutSecondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does reasonably well: it discloses the polling model, the 300s default / 600s cap, idempotent repeated invocation, and the shape of the result including a done flag. It omits what happens on timeout expiry (error vs partial result), which is the notable behavioral gap.

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?

Three tight sentences, each carrying distinct information (poll mechanism, timeout bounds, return payload, idempotency). Nothing is redundant and the key constraints are front-loaded.

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

Completeness3/5

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

For a 4-parameter polling tool with no annotations and no output schema, the description covers the essentials of invocation and return values, but it leaves timeout-failure behavior, permission/auth needs, and the 'name' parameter's relationship to the deployed app unspecified.

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 coverage is 50%, and the description only reinforces timeoutSeconds semantics (already in the schema) plus the meaning of txid confirmations. The required 'name' parameter and the update-flow semantics of previousHash remain undocumented in the description beyond the schema's own text.

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 names the polling behavior and enumerates what it returns (payment confirmations, spec acceptance, running instances with URLs), so an agent can tell it is a wait/poll tool. It does not, however, contrast itself with siblings like flux_get_app or flux_deploy_app, which is the main remaining ambiguity.

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

Usage Guidelines3/5

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

'Safe to call repeatedly until done=true' implies a poll-until-complete usage pattern, and the default/max timeout hints at appropriate call scope. But it never states when to choose this over flux_get_app or that it should follow flux_deploy_app, so usage is implied rather than directed.

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