mcp

Wait for a deployment to finish, and get the evidence in one answer

wait_for_deployment

Read-onlyIdempotent

⭐ CALL THIS INSTEAD OF POLLING. Waits up to 50 seconds per call (an MCP client cuts a call at about 60 s) for the deployment to reach a TERMINAL state (ready, build_failed, error or vm_missing) and returns, in ONE response, everything you would otherwise fetch afterwards: the HTTP status of the PUBLIC url (not the VM's private interface, which can answer 401 while the public path still 502s), the container table with health and restarts, the host's memory/disk/load, and the .env KEY NAMES. Do NOT loop on get_deployment: that is 8-9 round trips per deploy that learn nothing, and then three more asking for what this already returned. ⚠️ A TIMEOUT IS NOT A FAILURE: if it returns timed_out:true the build is simply still running, so call it again (a typical deploy takes 2 to 5 calls). Only status decides success. On build_failed or error, call get_deployment(id) for the full build_log, which is the diagnosis.

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

Input Schema

Name	Required	Description	Default
`id`	Yes	Deployment id, from the deploy call or list_deployments.
`timeout_s`	No	Seconds to wait in this call before returning timed_out:true: at most 50 (the default); a larger value waits 50, because an MCP client cuts a call at about 60 s (ROADMAP 7). Call again until it is terminal.

Output Schema

Name	Required	Description	Default
`next`	No
`note`	No
`error`	No
`status`	No
`details`	No
`message`	No
`evidence`	No
`recovery`	No
`terminal`	No
`timed_out`	No
`deployment`	No
`validation`	No
`waited_seconds`	No
`account_notices`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 5, 2026
- addedOutput schema / properties / details
```
Added value: +{}
```
- addedOutput schema / properties / error
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / recovery
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / status
```
Added value: +{}
```
- addedOutput schema / properties / validation
```
Added value: +{}
```

Changed1 schema field changedOct 31, 2026

addedOutput schema / properties / account_notices

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "dismissible": {
+        "type": "boolean"
+      },
+      "id": {
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "url": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "message",
+      "url",
+      "dismissible"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / timeout_s / description

Previous value: -"How long to wait before returning timed_out:true (default 300, max 600). A typical deploy reaches ready in 90 to 250 seconds."New value: +"Seconds to wait in this call before returning timed_out:true: at most 50 (the default); a larger value waits 50, because an MCP client cuts a call at about 60 s (ROADMAP 7). Call again until it is terminal."

AddedAug 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: a 50-second wait cap, MCP client cutoff around 60 seconds, typical 2 to 5 calls per deploy, and the fact that timed_out:true is not a failure. It also reveals what evidence is returned, including public URL status versus private interface, container health, host metrics, and env key names.

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?

The description is front-loaded with the primary directive and structured with explicit warnings and failure guidance. It is somewhat dense and repetitive in places, but nearly every sentence carries actionable information for correct invocation.

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?

Given the tool's complexity and the presence of an output schema, the description is complete enough for an agent to invoke it correctly. It covers terminal-state semantics, timeout handling, retry expectations, and diagnostic follow-up without needing to explain the output schema.

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 100%, so both the deployment id and timeout_s are already fully documented in the schema. The description reinforces timeout behavior and retry semantics, but adds little parameter-level meaning beyond the schema's own descriptions.

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?

States a specific verb and resource: it waits for a deployment to reach a terminal state and returns aggregated evidence in one response. It explicitly distinguishes itself from get_deployment polling and names the exact terminal states and returned artifacts.

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?

Gives explicit when-to-use guidance ('CALL THIS INSTEAD OF POLLING') and when-not-to-use guidance ('Do NOT loop on get_deployment'). It also explains the timeout retry path and directs the agent to get_deployment(id) for build_log only after build_failed or error.

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

All mcp tools Inspect

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

Need Help?