"terraform" matching MCP tools:

• terraform

  agent-planets

  Set one tile of your 8x8 planet grid to a biome: ocean, forest, desert, ice, lava, city, crystal, void. 1 action / 3s.

  Connector

• terraform-plan-cost-estimator

  Utility Matrix

  Use when a user asks to estimate monthly cost of a Terraform plan.

  Connector

• tflogs

  InsideOut (Riley)

  MONITORING: Fetch Terraform deployment logs with pagination Fetches logs from a running or completed Terraform deployment job. For **completed jobs**: uses REST endpoint for instant retrieval (supports `tail` for server-side filtering). For **running jobs**: streams via SSE with timeout-based pagination. **PAGINATION** (running jobs only): Use `last_event_id` from the response to fetch more: 1. First call: `tflogs(session_id='...')` → get logs + `last_event_id` 2. Next call: `tflogs(session_id='...', last_event_id='...')` → get NEW logs only 3. Repeat until `complete: true` in response **RESPONSE FIELDS**: - `logs`: Array of log messages collected - `last_event_id`: Pass this back to get more logs (pagination cursor, SSE only) - `complete`: true if job finished, false if more logs may be available - `total_logs`: total log entries before tail truncation REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: job_id to target a specific deployment (use tfruns to discover IDs), timeout (default 50s, max 55s), last_event_id (for pagination), tail (return only last N entries) ⚠️ CONTEXT WARNING: Deploy logs can be hundreds of lines. Use tail: 50 for completed jobs to avoid blowing up the context window.

  Connector

• tfplan

  InsideOut (Riley)

  PREVIEW: Run terraform plan to preview infrastructure changes Runs a terraform plan for an InsideOut session without applying any changes. This lets the user review what will be created/changed/destroyed before committing. Returns job_id, plan_id, and project_id. Use tflogs to stream the plan output. After the plan completes, use tfdeploy with plan_id to apply the exact plan. SINGLE-FLIGHT: only one TF job per session at a time. If another job is already in flight, tfplan returns tf_job_conflict with the live job_id — attach with tfstatus/tflogs, or pass force_new=true to override. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: sandbox (boolean, default false) — plans real generated Terraform. Set to true for cheap sandbox template (testing only). OPTIONAL: force_new (boolean, default false) - bypass the single-flight guard. Use only when the existing run is provably wedged. CREDENTIAL HANDLING: Same as tfdeploy - credentials must be configured first.

  Connector

• convoreply

  InsideOut (Riley)

  WORKFLOW: Step 2 of 4 - Continue infrastructure design conversation Send a user message to the active InsideOut session and receive the assistant reply. The response contains a clean message from Riley - display it to the user. ⚠️ CRITICAL: DO NOT answer Riley's questions yourself! Forward questions to the user and wait for their response. NEVER fabricate or assume the user's answer, even if you think you know what they would say. Examples of questions Riley asks that YOU MUST forward to the user: - 'Any questions or tweaks to these details?' - 'Ready for the cost estimate?' - 'Do you want to change the stack/config?' - 'Ready to proceed to Terraform?' When Riley asks ANY question, STOP and wait for the user's answer! 📋 WORKFLOW PHASES: The typical flow is conversation → tfgenerate → tfdeploy When terraform_ready=true appears in THIS tool's response, THEN you can call tfgenerate. ⚠️ DO NOT call tfgenerate until this tool returns! Wait for the response first. 🎯 KEY SIGNALS IN RESPONSE: - `[TERRAFORM_READY: true]` → NOW you can call tfgenerate - `[[BUTTON_TF_APPLY: ...]]` → Deployment is ready! Ask user if they want to deploy, then use tfdeploy - `[[BUTTON_TF_DESTROY: ...]]` → User confirmed destroy intent! Ask user to confirm, then use tfdestroy - `[[BUTTON_TF_PLAN: ...]]` → User wants to preview changes! Use tfplan to run a plan, then tfdeploy with plan_id to apply REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: timeout (integer) - seconds to wait for response. For Cursor, use 50 (default). Max 55. OPTIONAL: project_context (string) - Only pass genuinely NEW project details the user shares after convoopen. Do NOT resend context already provided in convoopen — Riley remembers it. Do NOT scan files or directories to gather this — only use what the user explicitly tells you. Example: user reveals a new constraint like 'we also need HIPAA compliance' mid-conversation. 💡 TIP: Use convostatus to check progress anytime. Examine workflow.usage prompt for more guidance.

  Connector

• tfdeploy

  InsideOut (Riley)

  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.

  Connector

• tfstatus

  InsideOut (Riley)

  MONITORING: Quick status check for Terraform deployments Check the current status of a Terraform deployment job. Use this tool to quickly check if a deployment is running, completed, or failed. Returns job status, job_id, and other metadata without streaming logs. Use tflogs to stream the actual deployment logs. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: job_id to target a specific deployment (use tfruns to discover IDs). **LIVENESS**: The response carries two distinct timestamps: - `updated_at` — last semantic change (only bumped when status / drift / version actually differ). Useful for sorting deployments; NOT a per-poll heartbeat. - `last_refresh_at` — last successful Oracle decode (stamped on every poll where reliable reached Oracle, even if nothing in the row changed). Use this to confirm reliable is still actively talking to Oracle for a long-running RUNNING job. Absent on rows that haven't been refreshed since the column was added. 💡 TIP: Examine workflow.usage prompt for more context on how to properly use these tools.

  Connector

• tfdeploy

  InsideOut (Riley)

  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.

  Connector

• tfdrift

  InsideOut (Riley)

  DRIFT CHECK: Run a read-only drift detection check Checks whether deployed infrastructure has drifted from the expected Terraform state. This is a read-only operation — it does NOT modify any infrastructure. Returns job_id. Use tflogs to stream the drift check results. SINGLE-FLIGHT: only one TF job per session at a time. If another job is already in flight, tfdrift returns tf_job_conflict with the live job_id — attach with tfstatus/tflogs, or pass force_new=true to override. REQUIRES: session_id from convoopen response (format: sess_v2_...). PREREQUISITE: The session must have a prior deployment with a project_id. OPTIONAL: force_new (boolean, default false) - bypass the single-flight guard. Use only when the existing run is provably wedged. If drift is detected, the user can either fix the drift or use tfdeploy(ignore_drift=true) to proceed.

  Connector

• convert_to_terraform

  Control Plane

  Convert a Control Plane resource manifest (YAML or JSON) into the equivalent Terraform (HCL). The manifest is first DRY-RUN VALIDATED against the API (no resource is created) — if it fails validation you get the error instead of HCL, so the returned Terraform always corresponds to a schema-valid resource. Pass `gvc` when the kind is GVC-scoped (workload, identity, volumeset). Set `generateImports` to also return ready-to-run `terraform import` commands. To convert an EXISTING resource instead of a manifest, use export_terraform.

  Connector

• tfdrift

  InsideOut (Riley)

  DRIFT CHECK: Run a read-only drift detection check Checks whether deployed infrastructure has drifted from the expected Terraform state. This is a read-only operation — it does NOT modify any infrastructure. Returns job_id. Use tflogs to stream the drift check results. SINGLE-FLIGHT: only one TF job per session at a time. If another job is already in flight, tfdrift returns tf_job_conflict with the live job_id — attach with tfstatus/tflogs, or pass force_new=true to override. REQUIRES: session_id from convoopen response (format: sess_v2_...). PREREQUISITE: The session must have a prior deployment with a project_id. OPTIONAL: force_new (boolean, default false) - bypass the single-flight guard. Use only when the existing run is provably wedged. If drift is detected, the user can either fix the drift or use tfdeploy(ignore_drift=true) to proceed.

  Connector

• convoreply

  InsideOut (Riley)

  WORKFLOW: Step 2 of 4 - Continue infrastructure design conversation Send a user message to the active InsideOut session and receive the assistant reply. The response contains a clean message from Riley - display it to the user. ⚠️ CRITICAL: DO NOT answer Riley's questions yourself! Forward questions to the user and wait for their response. NEVER fabricate or assume the user's answer, even if you think you know what they would say. Examples of questions Riley asks that YOU MUST forward to the user: - 'Any questions or tweaks to these details?' - 'Ready for the cost estimate?' - 'Do you want to change the stack/config?' - 'Ready to proceed to Terraform?' When Riley asks ANY question, STOP and wait for the user's answer! 📋 WORKFLOW PHASES: The typical flow is conversation → tfgenerate → tfdeploy When terraform_ready=true appears in THIS tool's response, THEN you can call tfgenerate. ⚠️ DO NOT call tfgenerate until this tool returns! Wait for the response first. 🎯 KEY SIGNALS IN RESPONSE: - `[TERRAFORM_READY: true]` → NOW you can call tfgenerate - `[[BUTTON_TF_APPLY: ...]]` → Deployment is ready! Ask user if they want to deploy, then use tfdeploy - `[[BUTTON_TF_DESTROY: ...]]` → User confirmed destroy intent! Ask user to confirm, then use tfdestroy - `[[BUTTON_TF_PLAN: ...]]` → User wants to preview changes! Use tfplan to run a plan, then tfdeploy with plan_id to apply REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: timeout (integer) - seconds to wait for response. For Cursor, use 50 (default). Max 55. OPTIONAL: project_context (string) - Only pass genuinely NEW project details the user shares after convoopen. Do NOT resend context already provided in convoopen — Riley remembers it. Do NOT scan files or directories to gather this — only use what the user explicitly tells you. Example: user reveals a new constraint like 'we also need HIPAA compliance' mid-conversation. 💡 TIP: Use convostatus to check progress anytime. Examine workflow.usage prompt for more guidance.

  Connector

• tfgenerate

  InsideOut (Riley)

  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.

  Connector

• tfoutputs

  InsideOut (Riley)

  INSPECTION: Retrieve Terraform outputs from a completed deployment Returns structured output values (VPC IDs, endpoints, cluster names, etc.) after a successful deploy. Sensitive outputs are redacted (shown as '(sensitive)'). By default returns outputs for the latest successful deploy. Optionally specify job_id to get outputs for a specific deployment. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: job_id (specific deployment), lifecycle (filter by step e.g. 'cloud-provision').

  Connector

• tfstatus

  InsideOut (Riley)

  MONITORING: Quick status check for Terraform deployments Check the current status of a Terraform deployment job. Use this tool to quickly check if a deployment is running, completed, or failed. Returns job status, job_id, and other metadata without streaming logs. Use tflogs to stream the actual deployment logs. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: job_id to target a specific deployment (use tfruns to discover IDs). **LIVENESS**: The response carries two distinct timestamps: - `updated_at` — last semantic change (only bumped when status / drift / version actually differ). Useful for sorting deployments; NOT a per-poll heartbeat. - `last_refresh_at` — last successful Oracle decode (stamped on every poll where reliable reached Oracle, even if nothing in the row changed). Use this to confirm reliable is still actively talking to Oracle for a long-running RUNNING job. Absent on rows that haven't been refreshed since the column was added. 💡 TIP: Examine workflow.usage prompt for more context on how to properly use these tools.

  Connector

• tflogs

  InsideOut (Riley)

  MONITORING: Fetch Terraform deployment logs with pagination Fetches logs from a running or completed Terraform deployment job. For **completed jobs**: uses REST endpoint for instant retrieval (supports `tail` for server-side filtering). For **running jobs**: streams via SSE with timeout-based pagination. **PAGINATION** (running jobs only): Use `last_event_id` from the response to fetch more: 1. First call: `tflogs(session_id='...')` → get logs + `last_event_id` 2. Next call: `tflogs(session_id='...', last_event_id='...')` → get NEW logs only 3. Repeat until `complete: true` in response **RESPONSE FIELDS**: - `logs`: Array of log messages collected - `last_event_id`: Pass this back to get more logs (pagination cursor, SSE only) - `complete`: true if job finished, false if more logs may be available - `total_logs`: total log entries before tail truncation REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: job_id to target a specific deployment (use tfruns to discover IDs), timeout (default 50s, max 55s), last_event_id (for pagination), tail (return only last N entries) ⚠️ CONTEXT WARNING: Deploy logs can be hundreds of lines. Use tail: 50 for completed jobs to avoid blowing up the context window.

  Connector

• audit_ci_security

  ci-sentinel

  Audit GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines AND Travis CI for security flaws BEFORE you merge or trust them — SEVEN CI ecosystems in one tool. Give it your CI config — the contents of .github/workflows/*.yml, your .gitlab-ci.yml, your Jenkinsfile, your .circleci/config.yml, your azure-pipelines.yml, your bitbucket-pipelines.yml and/or your .travis.yml (it auto-detects which CI system each file is) — and it returns a CRITICAL / VULNERABLE / RISKY / HARDENED verdict. GitHub Actions: script/expression INJECTION (attacker-controlled ${{ github.event.* }} — issue/PR title, body, comment, branch name, commit message, label name, fork repo identity — into run: or actions/github-script), following taint ACROSS steps.<id>.outputs.*, needs.<job>.outputs.*, env vars, matrix values, reusable-workflow inputs.* and composite-action interiors; pull_request_target / workflow_run 'pwn requests'; reusable-workflow misuse (untrusted data over workflow_call, 'secrets: inherit'); excessive GITHUB_TOKEN permissions; unpinned third-party actions incl. transitive supply chain (tj-actions/CVE-2025-30066 class); self-hosted-runner RCE; OIDC/id-token misuse; broken if: gates. GitLab CI/CD: injection from untrusted CI variables (CI_COMMIT_REF_NAME/BRANCH/TAG, CI_MERGE_REQUEST_TITLE/DESCRIPTION/SOURCE_BRANCH_NAME, commit message/author) interpolated into script:, following taint through variables: and extends: templates AND through remote/project include: files (cross-file, the included file's sinks are resolved & analyzed); secrets / broad CI_JOB_TOKEN / id_tokens (OIDC) exposed to fork merge-request pipelines; include: from untrusted remote/foreign-project sources not pinned to a SHA; rules/only/except that let a fork MR run privileged jobs without a manual gate; and artifact/cache POISONING where an untrusted job feeds bytes a privileged downstream job executes (cross-job & cross-pipeline). Jenkins (declarative + scripted Jenkinsfile): command INJECTION from untrusted input (build params.*, multibranch env.CHANGE_*/BRANCH_NAME, the GitHub PR-builder ghprb* vars like ghprbCommentBody, SCM commit data) interpolated into a sh/bat/powershell GString — following taint through pipeline/stage environment{} bindings; credential exposure (a credentials()/withCredentials secret printed with echo or baked into a shell GString, defeating log masking); Groovy evaluate()/Eval/load over untrusted input (sandbox bypass / RCE); approval-bypass (a privileged deploy/publish step reachable from a PR/comment build with no input() gate); and unsafe 'agent any' running untrusted PR code on a privileged executor. CircleCI (.circleci/config.yml): shell INJECTION from untrusted pipeline values (<< pipeline.git.branch >> / << pipeline.git.tag >> the attacker names, or a pipeline parameter set by an API/PR trigger) interpolated into a run: command; UNPINNED ORBS on a mutable version (@volatile / a bare major / dev: tag = supply-chain, the orb runs in your pipeline with your contexts); CROSS-FILE ORB INJECTION — an untrusted value passed to an orb-command parameter that the published orb's OWN source pipes into an internal run: sink (the orb's interior is resolved & analyzed, a flow a single-file scan can't see); fork-PR CONTEXT SECRET exposure (a job attaching an org context reachable from forked-PR builds without a type: approval gate); and missing approval gate before a privileged deploy job. Azure Pipelines (azure-pipelines.yml): macro INJECTION from untrusted predefined variables ($(Build.SourceBranch)/$(Build.SourceBranchName) the attacker names, $(System.PullRequest.SourceBranch) on fork PRs, $(Build.SourceVersionMessage) commit message) substituted into script:/bash:/pwsh: text, following taint through variables: bindings; UNTRUSTED TEMPLATES pulled from a foreign repository resource (runs in your pipeline with your secrets); CROSS-FILE TEMPLATE INJECTION — an untrusted value passed as a template parameter that the foreign template's OWN body pipes into an internal script:/bash: sink (the template interior is resolved & analyzed); fork variable-GROUP / secret exposure on PR-triggered pipelines; and unpinned repository resources on moving refs. Bitbucket Pipelines (bitbucket-pipelines.yml): shell INJECTION from attacker-named variables ($BITBUCKET_BRANCH / $BITBUCKET_TAG / $BITBUCKET_PR_DESTINATION_BRANCH, or a crafted commit message) expanded unquoted into a script: line in a default/pull-requests pipeline; SECURED / deployment-variable fork exposure (a PR pipeline reachable from external contributors that reads repository/deployment secrets); UNPINNED PIPES (a pipe: on :latest / a floating tag = supply-chain, the pipe runs in your step with your secrets); and ungated DEPLOYMENTS (a deployment: step with no trigger: manual reachable from PR/branch). Travis CI (.travis.yml): shell INJECTION from attacker-named TRAVIS_* variables ($TRAVIS_BRANCH / $TRAVIS_PULL_REQUEST_BRANCH / $TRAVIS_TAG / $TRAVIS_COMMIT_MESSAGE) expanded unquoted into a lifecycle hook (before_script/script/after_*); secure-env PR exposure (encrypted secure: vars present on a PR-buildable config that can leak to same-repo branch PRs / opted-in forks); and ungated DEPLOYS (a deploy: with no on: branch/condition gate that fires on any ref). HARDCODED SECRETS (all seven ecosystems): credentials committed verbatim in any CI config — AWS access key ids (AKIA/ASIA), GitHub tokens (ghp_/gho_/ghs_/github_pat_), GitLab/npm/Slack/Google/Stripe keys, PEM private keys, and generic high-entropy secrets assigned to secret-shaped keys — while correctly suppressing the SAFE indirect references (${{ secrets.X }}, $VAR, << pipeline... >>, $(Var), credentials('id'), Key Vault / vault refs) so you get the real leaks with zero false positives; evidence is redacted so the report never re-leaks the credential. OIDC CLOUD-TRUST MISCONFIGURATION (cross-domain, IaC): include your Terraform / CloudFormation / GCP workload-identity / Azure federated-credential and ci-sentinel models the CLOUD side of OIDC — the trust policy of the IAM role / pool / app that backs CI — and flags the catastrophic-but-common misconfigurations: a `sub` condition with a broad wildcard (repo:org/*, repo:*), NO sub condition at all (any workflow on the issuer can assume the role), a repo pinned but ref/environment UNpinned (any branch can assume), the bare `pull_request` subject (fork-reachable), or an unpinned `aud`. It then CORRELATES the IaC trust condition with the CI side (a workflow that mints id-token reachable from an untrusted trigger) and escalates to critical when the chain is reachable end-to-end — a flow no single-file CI linter catches because it spans the CI claim and the cloud trust policy. JENKINS SHARED LIBRARIES (@Library, cross-file): provide the library's vars/<name>.groovy bodies (sharedLibYmls) and ci-sentinel taints an untrusted pipeline value (a PR title / branch / build parameter) passed to a shared-library global-var step THROUGH the library's call() interior to an internal sh/bat sink — the Jenkins parity of orb/template/composite-action cross-file taint, invisible when reading only the Jenkinsfile — plus flags @Library imports pinned to a mutable ref (a branch / default version) as supply-chain risk. The deep tier returns every finding with file:line, the full taint path and a SARIF 2.1.0 report with codeFlows, uploadable to GitHub code scanning. Use it whenever reviewing, writing or accepting CI config. Heuristic static analysis, not a guarantee.

  Connector

• export_terraform

  Control Plane

  Generate Terraform (HCL) for EXISTING Control Plane resources from a self link. Single resource (`/org/acme/gvc/prod/workload/api`) or bulk by path depth — `/org/acme` exports the whole org, `/org/acme/gvc/prod/workload` exports every workload in a GVC. Set `generateImports` to get ready-to-run `terraform import` commands for adopting the resources into Terraform state, and `includeDependencies` to pull in referenced resources. Exported secrets embed their REVEALED plaintext values — without includeSecretValues they are redacted, and a ref that targets secrets directly is refused. An unsupported kind is rejected with the supported list (list_terraform_kinds, full profile, enumerates them up front). For an in-memory manifest, use convert_to_terraform. Recommended reading: get_cpln_skill("iac-terraform-pulumi").

  Connector

• submit_feedback

  InsideOut (Riley)

  FEEDBACK: Submit feedback, bug reports, or feature requests to Luther Systems Use this tool to forward user feedback directly to the Luther Systems team. This includes bug reports, feature requests, questions, or general feedback about InsideOut. The agent itself can also use this tool to report issues it encounters during operation. REQUIRES: session_id, category, message OPTIONAL: user_email (for follow-up), user_name, source (default: 'mcp'), initiator ('user' or 'agent') Categories: bug_report, feature_request, general_feedback, question, security The 'initiator' field tracks who triggered the report: - 'user' — the user explicitly reported the issue or requested feedback submission - 'agent' — Riley detected an issue and initiated the feedback flow Examples: - User says 'the deploy button is broken' → submit_feedback(category='bug_report', message='...', initiator='user') - User says 'I wish it had dark mode' → submit_feedback(category='feature_request', message='...', initiator='user') - Deployment failed with Terraform error → submit_feedback(category='bug_report', message='Deployment failed: Terraform apply error on aws_alb resource — timeout waiting for ALB provisioning', initiator='agent')

  Connector

• tfgenerate

  InsideOut (Riley)

  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.

  Connector