Skip to main content
Glama
luthersystems

insideout-mcp

by luthersystems
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Deploy Infrastructure

tfdeploy
Destructive

Start a Terraform deploy job for your InsideOut session. Optionally apply a saved plan or ignore infrastructure drift.

Instructions

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.

Tool Definition Quality

A4.6/5.0
Behavior4/5

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

Annotations already indicate destructive and open-world behavior. Description adds details: long-running (15+ min), single-flight constraint, conflict response, credential flow with connect_url, and parameter effects. Does not contradict 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?

Well-structured with clear sections (workflow, purpose, notes, parameters, credential flow). Front-loads key info. Slightly lengthy but each sentence adds value; no redundancy.

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?

Covers all essential aspects: workflow position, prerequisites, parameter details, error handling (conflict, credential flow), and references to sibling tools for monitoring. No output schema, but return behavior is described adequately.

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 baseline is 3. Description adds extra context for each parameter (e.g., plan_id for preview-then-apply, sandbox for testing, ignore_drift for drift handling) and warns about session_id token suffix, improving usability beyond schema alone.

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 by starting a Terraform job, positions it as Step 4 of 4, and distinguishes from siblings like tfplan and tflogs via workflow context.

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 when-to-use (after generation, step 4), when-not-to (another job in flight), and alternatives (tfstatus, tflogs, credawait). Includes preview-then-apply workflow and force_new override guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/luthersystems/insideout-agent-skills'

If you have feedback or need assistance with the MCP directory API, please join our Discord server