Skip to main content
Glama
luthersystems

insideout-mcp

by luthersystems
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Generate Terraform

tfgenerate
Idempotent

Generate Terraform files from a completed infrastructure design session. Returns a file summary and download link, or inline code as a fallback.

Instructions

WORKFLOW: Step 3 of 4 - Generate Terraform files from completed design Generate Terraform files from an InsideOut session that has completed infrastructure design.

⚠️ PREREQUISITE: Only call this AFTER convoreply returns with terraform_ready=true in the response metadata. DO NOT call this while convoreply is still running or before terraform_ready is confirmed! If you get 'session has not reached terraform-ready state', wait for convoreply to complete first.

🎯 USE THIS TOOL WHEN: convoreply has returned with terraform_ready=true, OR the user asks to 'see the terraforms', 'generate terraform', 'show me the code', etc.

DEFAULT RESPONSE: Returns summary table + download URL (keeps code out of LLM context). FALLBACK: Set include_code: true to get full code inline if curl/unzip fails.

CRITICAL WORKFLOW (default mode):

  1. Call this tool to get file summary and download URL

  2. ASK the user: 'Where would you like me to save the Terraform files? Default: ./insideout-infra/'

  3. WAIT for user confirmation before running the download command

  4. Run the curl/unzip command with the user's chosen directory

  5. If curl/unzip FAILS (sandbox, security, platform issues), retry with include_code: true

AFTER GENERATION: Ask user if they want to review the files and then deploy with tfdeploy

REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: include_code (boolean) - set true to return full code inline as fallback. 💡 TIP: Examine workflow.usage prompt for more context on how to properly use these tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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. Riley must have signaled [TERRAFORM_READY: true] before calling this tool.
include_codeNoWhen true, the response inlines the full generated Terraform source. Use as a fallback when the host can't read the on-disk archive (sandbox or security restrictions).

Tool Definition Quality

A4.6/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false. Description adds rich context: default response keeps code out of context, fallback inlines code on failure, and explains the need to wait for user confirmation before downloading. This significantly augments the annotations without contradicting them.

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 bold headings, emojis, and bullet points that make scanning easy. Front-loaded with workflow step and prerequisite. While verbose, every sentence adds value; minimal redundancy. Could trim a few details but overall effective.

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 (workflow step, prerequisites, dual modes, user interaction), the description covers all essential aspects: prerequisites, when to use, step-by-step workflow, error handling, fallback, and follow-up actions. No output schema exists, but the description clarifies default vs. fallback response behavior.

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?

Input schema has 100% coverage with explicit descriptions for both parameters (session_id format, include_code behavior). Description reinforces critical details like not stripping the token suffix and the fallback use case. Even with high schema coverage, the description adds valuable operational context.

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?

Clear verb ('Generate Terraform files'), specific context ('from completed design'), and explicit workflow step (3 of 4). Differentiates from sibling tools like tfdeploy by stating it's the generation step. Includes explicit conditions for use (after convoreply returns terraform_ready=true).

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 prerequisite (convoreply with terraform_ready=true), when NOT to call (before terraform_ready), and alternative fallback (include_code). Provides a step-by-step workflow including user interaction and error handling, leaving no ambiguity about when and how to use this tool.

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