Skip to main content
Glama

Generate Terraform

tfgenerate
Idempotent

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.

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": "tfgenerate"
  }
}

Input 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).

Output Schema

NameRequiredDescriptionDefault
filesNoNumber of generated Terraform files.
hintsNoGuidance for the calling agent: what to do next and which tools relate to this result.
inlineNoTrue when the source is inlined in the result (include_code=true) instead of offered as a download.
successNoTrue when the Terraform was generated.
download_urlNoURL of the archive with the generated Terraform.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "download_url": {
      +      "description": "URL of the archive with the generated Terraform.",
      +      "type": "string"
      +    },
      +    "files": {
      +      "description": "Number of generated Terraform files.",
      +      "type": "integer"
      +    },
      +    "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"
      +      ]
      +    },
      +    "inline": {
      +      "description": "True when the source is inlined in the result (include_code=true) instead of offered as a download.",
      +      "type": "boolean"
      +    },
      +    "success": {
      +      "description": "True when the Terraform was generated.",
      +      "type": "boolean"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / include_code / description
      Added value: +"When 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)."
    • 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. Riley must have signaled [TERRAFORM_READY: true] before calling this tool."
    • addedInput schema / properties / session_id / pattern
      Added value: +"^sess_v2_[0-9A-Za-z]+\\?token=[0-9a-f]+$"
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and the description does not contradict them. It adds meaningful behavior beyond the annotations: default response returns a summary table + download URL rather than inline code, include_code triggers a fallback path, and there's a required user-confirmation step before download. It does not say whether generation overwrites existing files in ./insideout-infra/, a minor gap.

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 the workflow step and purpose, and organized under clear headers, but there is noticeable redundancy: the terraform_ready prerequisite is asserted three separate times and the fallback/retry behavior is stated twice. It is longer than necessary without being disorganized.

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?

Even though an output schema exists (so return values need not be described), the description goes further and explains the shape of the response (summary table + URL vs inline code). Prerequisite state, fallback behavior, required user confirmation, and the handoff to tfdeploy are all covered.

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 description coverage is 100%, so both parameters are already documented; the schema itself explains the ?token= suffix and the include_code fallback. The description restates these rather than adding new semantics, though noting session_id originates from convoopen adds slight provenance value. Baseline 3 is appropriate.

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?

Specific verb+resource ('Generate Terraform files') scoped to an InsideOut session that has completed infrastructure design. Clearly distinguishable from siblings like tfplan, tfdeploy, and tfdestroy, which operate at other stages. The 'Step 3 of 4' framing further anchors it in the workflow.

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?

Explicit when-to-use ('convoreply has returned with terraform_ready=true, OR the user asks to see the terraforms') and explicit when-not ('DO NOT call this while convoreply is still running or before terraform_ready is confirmed'). It also routes the user forward to tfdeploy after generation, naming the alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources