InsideOut (Riley)

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

Call this tool to get file summary and download URL
ASK the user: 'Where would you like me to save the Terraform files? Default: ./insideout-infra/'
WAIT for user confirmation before running the download command
Run the curl/unzip command with the user's chosen directory
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

Name	Required	Description	Default
`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. Riley must have signaled [TERRAFORM_READY: true] before calling this tool.
`include_code`	No	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).

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses that the default response is a summary table plus a download URL (to keep code out of LLM context), and that include_code:true is a fallback for sandbox/security failures. It also outlines the post-call workflow, including asking the user for the save directory and handling curl/unzip failures, providing significant behavioral context 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 well-structured with sections and front-loaded purpose, but it is verbose. The critical workflow and tips add operational value, though some repetition (e.g., 'Generate Terraform' appears multiple times) could be trimmed. Still, each section earns its place for an agent.

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?

The tool has no output schema and is part of a complex workflow, but the description covers prerequisites, default and fallback return behaviors, the post-invocation user-confirmation step, and the handoff to tfdeploy. It also references the workflow.usage prompt for further context, making it comprehensive for safe and correct invocation.

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%, but the description enriches both parameters: session_id must be passed exactly as returned from convoopen (including the ?token=... suffix) and is tied to the terraform_ready prerequisite; include_code is explained as a fallback for environments that cannot read on-disk archives. This exceeds the schema details.

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 'Generate Terraform files from an InsideOut session that has completed infrastructure design', specifying the verb, resource, and context. It also identifies itself as Step 3 of 4, distinguishing it from siblings like tfdeploy and tfplan.

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?

The 'USE THIS TOOL WHEN' section explicitly defines the trigger conditions: after convoreply returns terraform_ready=true, or when the user requests terraform generation. It also provides exclusions (DO NOT call while convoreply is running) and directs to tfdeploy for the next step, giving clear usage boundaries.

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

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

Need Help?