InsideOut (Riley)

Deploy Infrastructure

tfdeploy

Destructive

WORKFLOW: Step 4 of 4 - Deploy infrastructure to the cloud Deploy infrastructure by starting a Terraform job for an InsideOut session. This tool initiates the actual deployment process after Terraform files have been generated. IMPORTANT: This starts a long-running job (15+ minutes). Use tfstatus to monitor progress. SINGLE-FLIGHT: only one TF job (apply/plan/destroy/drift) runs per session at a time. If another job is already in flight, tfdeploy returns tf_job_conflict with the live job_id — attach with tfstatus/tflogs instead of retrying, or pass force_new=true to override. Returns confirmation that the deployment has started. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: plan_id (string) — Apply a previously created plan from tfplan. Preview-then-apply workflow: tfplan → tflogs (review) → tfdeploy(plan_id=...). OPTIONAL: sandbox (boolean, default false) — deploys real generated Terraform. Set to true for cheap sandbox template (testing only). OPTIONAL: ignore_drift (boolean, default false) - when true, proceeds with deploy even if infrastructure drift is detected. By default, deploys fail on drift. Use after reviewing drift details via tfdrift or tflogs. OPTIONAL: force_new (boolean, default false) - bypass the session-level single-flight guard. Use only when the existing run is provably wedged. CREDENTIAL FLOW (if credentials are missing):

Response includes a connect_url — present it to the user
Call credawait(session_id=...) to poll for credentials
When credawait returns success, retry tfdeploy Do NOT call credawait without first showing the connect URL to the user.

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

Input Schema

Name	Required	Description
`plan_id`	No	Apply a previously created plan from tfplan. When set, project_id should also be provided.
`sandbox`	No	When true (default for MCP), deploys a small sandbox stack instead of the real generated Terraform. Set false to deploy the actual user stack.
`version`	No	Deploy a specific stack version number. Defaults to the current draft.
`force_new`	No	When true, bypass the session-level single-flight guard and start a new deploy even if another job is in flight. Use only when an existing run is provably wedged.
`project_id`	No	Project ID returned by tfplan. Required alongside plan_id.
`session_id`	Yes	Session ID from convoopen — pass back EXACTLY as returned, including the ?token=... suffix (format: sess_v2_?token=). The suffix is part of the session credential; never strip it when summarizing.
`ignore_drift`	No	When true, proceed with deploy even if drift is detected on the existing stack.

Output Schema

Name	Required	Description
`hints`	No	Guidance for the calling agent: what to do next and which tools relate to this result.
`job_id`	No	ID of the started job. Pass it to tfstatus or tflogs to follow progress. May be empty when the backend did not return one.
`success`	No	True when the deploy job was started.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "hints": {
+      "description": "Guidance for the calling agent: what to do next and which tools relate to this result.",
+      "properties": {
+        "next_actions": {
+          "description": "Suggested next steps, in order, often as ready-to-run tool calls.",
+          "items": {
+            "description": "One suggested next step.",
+            "type": "string"
+          },
+          "type": [
+            "null",
+            "array"
+          ]
+        },
+        "related_tools": {
+          "description": "Names of tools that are useful after this result.",
+          "items": {
+            "description": "A tool name.",
+            "type": "string"
+          },
+          "type": [
+            "null",
+            "array"
+          ]
+        }
+      },
+      "type": [
+        "null",
+        "object"
+      ]
+    },
+    "job_id": {
+      "description": "ID of the started job. Pass it to tfstatus or tflogs to follow progress. May be empty when the backend did not return one.",
+      "type": "string"
+    },
+    "success": {
+      "description": "True when the deploy job was started.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

Changed8 schema fields changedMay 7, 2026

addedInput schema / properties / force_new / description

Added value: +"When true, bypass the session-level single-flight guard and start a new deploy even if another job is in flight. Use only when an existing run is provably wedged."

addedInput schema / properties / ignore_drift / description

Added value: +"When true, proceed with deploy even if drift is detected on the existing stack."

addedInput schema / properties / plan_id / description

Added value: +"Apply a previously created plan from tfplan. When set, project_id should also be provided."

addedInput schema / properties / project_id / description

Added value: +"Project ID returned by tfplan. Required alongside plan_id."

addedInput schema / properties / sandbox / description

Added value: +"When true (default for MCP), deploys a small sandbox stack instead of the real generated Terraform. Set false to deploy the actual user stack."

addedInput schema / properties / session_id / description

Added value: +"Session ID from convoopen — pass back EXACTLY as returned, including the ?token=... suffix (format: sess_v2_*?token=*). The suffix is part of the session credential; never strip it when summarizing."

addedInput schema / properties / session_id / pattern

Added value: +"^sess_v2_[0-9A-Za-z]+\\?token=[0-9a-f]+$"

addedInput schema / properties / version / description

Added value: +"Deploy a specific stack version number. Defaults to the current draft."

First observedMay 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructive=true and openWorld=true, but the description adds a lot beyond them: the 15+ minute long-running nature, the session-level single-flight guard and the tf_job_conflict response contract, the default-fail-on-drift behavior, and the full credential flow. This is unusually rich operational context for a mutation tool.

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?

Front-loaded with WORKFLOW step and the core action, and the labeled sections (REQUIRES, OPTIONAL, CREDENTIAL FLOW) make it scannable. Slightly over-long: force_new and ignore_drift are explained both in prose and again in the schema, and the return-value sentence is redundant given the output schema.

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 destructive, long-running, open-world deploy tool with 7 params, it covers prerequisites (session_id format), optional overrides, conflict handling, drift policy, and credential recovery. With an output schema present, it correctly does not over-explain return values.

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?

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: the preview-then-apply sequence for plan_id (tfplan → tflogs → tfdeploy), the single-flight interaction of force_new, and the drift-override semantics of ignore_drift. Note a minor inconsistency: the description says sandbox defaults to false while the schema says true is the MCP default, which is worth resolving.

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 ('Deploy infrastructure by starting a Terraform job') and frames it as Step 4 of 4, which immediately distinguishes it from tfplan, tfdestroy, tfdrift, and tfstatus. An agent can place this tool in the workflow without opening any schema.

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?

Explicitly states when to use it (after Terraform files are generated), names alternatives for adjacent needs (tfstatus to monitor, tflogs/tfdrift before overriding drift, credawait for missing credentials), and gives a clear when-not rule for force_new ('only when the existing run is provably wedged'). Nothing is left to inference.

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

All InsideOut (Riley) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?