Skip to main content
Glama

InsideOut (Riley)

by com.luthersystems.app

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):

  1. Response includes a connect_url — present it to the user

  2. Call credawait(session_id=...) to poll for credentials

  3. When credawait returns success, retry tfdeploy Do NOT call credawait without first showing the connect URL to the user.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
plan_idNoApply a previously created plan from tfplan. When set, project_id should also be provided.
sandboxNoWhen true (default for MCP), deploys a small sandbox stack instead of the real generated Terraform. Set false to deploy the actual user stack.
versionNoDeploy a specific stack version number. Defaults to the current draft.
force_newNoWhen 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_idNoProject ID returned by tfplan. Required alongside plan_id.
session_idYesSession 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_driftNoWhen true, proceed with deploy even if drift is detected on the existing stack.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare destructiveHint and openWorldHint; the description adds substantial behavioral context: long-running (15+ minutes), single-flight guard with tf_job_conflict response, drift-fails-by-default behavior, and credential flow with connect_url. This goes well beyond the annotations.

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 long but well-structured with clear sections for workflow, options, and credential flow. While some redundancy with schema exists, most content earns its place by providing operational context.

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 tool with no output schema, the description covers expected return behavior, failure mode (tf_job_conflict), prerequisite session_id, optional parameters, and credential flow. It provides a complete operational picture.

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

Parameters2/5

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

Schema provides 100% coverage, but the description clarifies session_id format and the relationship between plan_id and project_id. However, it contradicts the schema on sandbox default: description says default false, schema says default true for MCP. This is a misleading discrepancy that could cause incorrect invocation, so score is reduced.

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 clearly states the tool deploys infrastructure via a Terraform job, explicitly positioning it as Step 4 of a 4-step workflow. It distinguishes itself from siblings like tfplan and tfgenerate by stating it initiates the actual deployment after files have been generated.

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?

Provides explicit workflow context: after generation, preview-then-apply sequence (tfplan → tflogs → tfdeploy), and clear instructions for conflicts (don't retry, attach with tfstatus/tflogs or use force_new). Also includes credential flow prerequisites and a direct 'Do NOT call credawait without showing URL' exclusion.

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

All InsideOut (Riley) toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, with clear domain prefixes (convo*, tf*, stack*, aws/gcp inspect) separating conversation, deployment, versioning, and cloud inspection. The batch variants (awsinspect_batch, gcpinspect_batch) are explicitly scoped as higher-throughput versions of their singular counterparts, so no ambiguity exists.

Naming Consistency4/5

The naming is mostly consistent: lowercase concatenated verb_noun patterns dominate (convoopen, tfdeploy, stackrollback, awsinspect). However, submit_feedback uses snake_case, and help stands alone as a generic utility, breaking the otherwise uniform lowercase-concatenated style.

Tool Count4/5

24 tools is on the heavier side, but the count is justified by the breadth of the domain: conversation workflow, multi-cloud inspection, Terraform lifecycle, stack versioning, and utilities. Each tool fills a distinct role, so while slightly high, the count is not bloated.

Completeness5/5

The tool surface covers the full infrastructure lifecycle: conversation and design (convoopen/convoreply/convostatus), Terraform generation and deployment (tfgenerate/tfplan/tfdeploy), monitoring (tfstatus/tflogs), teardown (tfdestroy), drift detection, stack versioning, and cloud inspection. No critical dead ends; only a missing explicit cancel/abort for running jobs is a minor gap.

Resources