InsideOut — Riley Infrastructure Agent

by luthersystems

286 downloads

Not rated

GitHub

About

InsideOut -- AI cloud infrastructure skill for Claude Code, Cursor, Kiro, and 30+ tools

Details

Author: luthersystems
Downloads: 286
Categories: AI, Infrastructure, Cloud Service

- Natural-language infrastructure design (AWS/GCP)
- Real-time cost estimation before deployment
- Generates production-ready, exportable Terraform files
- Deploys and manages infrastructure from your AI environment
- Secure and observable by default (WAF, KMS, CloudWatch, etc.)
- Multi-agent system (Riley, Hippo, Joy, Etch, Core, Axel)

Setting up with Highlight

This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:

Download and install Highlight from highlightai.com/download
Navigate to the plugins tab and select "Add Custom Plugin"
Configure the plugin with the settings below

Plugin Name InsideOut — Riley Infrastructure Agent

Command (node, npx, python, etc.)

Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
Enable "Start Automatically" if you want the plugin to start when Highlight launches

Setting up with Cursor

Open Cursor's settings
Navigate to the MCP section
Click "Add new Global MCP server"
Copy and paste the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

Setting up with Claude Desktop

Open Claude Desktop's settings
Go to the Integrations tab
Click "Add MCP Server"
Use the configuration below based on your operating system

Note: Make sure Claude Desktop is running before attempting to connect.

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

Setting up with Windsurf

Open Windsurf's preferences
Go to the Integrations section
Click "Add MCP Integration"
Use the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

Setting up with Cline

Open Cline's settings
Navigate to the Integrations section
Click "Add MCP Server"
Copy and paste the configuration below based on your operating system

Note: Make sure to restart Cline after adding the configuration.

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

Setting up with Goose

Open Goose's preferences
Go to the Integrations tab
Select "MCP Servers"
Click "Add New Server"
Use the configuration below based on your operating system

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

JSON

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

From the repository

Install by running npx skills add luthersystems/insideout-agent-skills, then ask a question like “Build me a scalable backend for my golang microservices app on AWS with a DB and auth.” InsideOut (led by the agent “Riley”) will propose an architecture, estimate cost, generate Terraform, and deploy it — all conversationally. Specific AI tools have dedicated installation paths (e.g., /plugin marketplace add luthersystems/insideout-claude-code for Claude Code, or adding the power from GitHub for Kiro).

`awsinspect`

INSPECTION: Inspect AWS infrastructure for a deployed project ⚠️ **PREREQUISITE**: This tool requires a prior deployment ATTEMPT (successful or failed). Check convostatus for hasDeployAttempt=true before calling. Works even after failed deploys to inspect orphaned resources. Inspect deployed AWS resources after a deployment attempt. Use this tool when the user asks about the status or details of their deployed infrastructure. It fetches temporary read-only credentials securely and queries the AWS API directly. RESPONSE TIERS (default is summary for token efficiency): - Summary (default): Key fields only (~500 tokens). Set detail=false, raw=false or omit both. - Detail: Full metadata for a specific resource. Set detail=true + resource filter. - Raw: Complete unprocessed API response. Set raw=true. REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: account, acm, alb, apigateway, apprunner, backup, bedrock, cloudfront, cloudwatchlogs, cognito, cost-explorer, dynamodb, ebs, ec2, ecs, eks, elasticache, kms, lambda, msk, opensearch, rds, route53, s3, sagemaker, secretsmanager, sqs, vpc, waf For a specific service's actions, call with action="list-actions". METRICS: Use list-metrics to discover available metrics for a service (no credentials needed). Then use get-metrics to retrieve data (auto-discovers resources). Most services return CloudWatch time-series. KMS returns key health (rotation, state). SecretsManager returns secret health (rotation, last accessed/rotated). Optional filters JSON: {"hours":6,"period":300}. BILLING: Use service=cost-explorer to inspect AWS costs. Actions: get-cost-summary (last 30 days by service, filters: {"days":7,"granularity":"DAILY"}), get-cost-forecast (projected spend through end of month), get-cost-by-tag (costs grouped by tag, filters: {"tag_key":"Environment","days":30}). Requires ce:GetCostAndUsage and ce:GetCostForecast IAM permissions. EXAMPLES: - awsinspect(session_id=..., service="ec2", action="describe-instances") - awsinspect(session_id=..., service="cost-explorer", action="get-cost-summary") - awsinspect(session_id=..., service="ec2", action="get-metrics", filters="{\"hours\":6}") - awsinspect(session_id=..., service="rds", action="describe-db-instances", detail=true)

`awsinspect_batch`

BATCH INSPECTION: run up to 32 AWS inspect probes in one call. ⚠️ **PREREQUISITE**: Same as awsinspect — deploy attempt required. Check convostatus for hasDeployAttempt=true before calling. Use this when you need to check more than ~3 resources. The backend fetches Oracle credentials ONCE per batch and fans out probes against a single AWS config — for a 12-resource health check this is ~5–8× faster and 12× fewer Oracle round-trips than calling awsinspect 12 times. BUDGETS: - Up to 32 sub-probes per call (subs array length). - 30s per-sub timeout; 60s total batch wall-clock. - Concurrency cap 8 — sub-probes run in parallel but never saturate AWS. - 512 KB response cap: subs past the cap keep their envelope (index/service/action/ok) but have result replaced with truncated=true. PARTIAL FAILURE IS EXPECTED. The response is an ordered results array; each entry has {index, service, action, ok, result, error}. Inspect each result — do NOT abort on the first error. A credential fetch failure leaves cred-less probes (list-actions, list-metrics) succeeding anyway. REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: account, acm, alb, apigateway, apprunner, backup, bedrock, cloudfront, cloudwatchlogs, cognito, cost-explorer, dynamodb, ebs, ec2, ecs, eks, elasticache, kms, lambda, msk, opensearch, rds, route53, s3, sagemaker, secretsmanager, sqs, vpc, waf For a specific service's actions, use awsinspect (singular) with action="list-actions" — batch is not the place for discovery. Batch responses are always summarized (no detail/raw per-sub); use singular awsinspect when you need full metadata or raw API output for one resource. EXAMPLES: - awsinspect_batch(session_id=..., subs=[ {"service":"ec2","action":"describe-instances"}, {"service":"rds","action":"describe-db-instances"}, {"service":"vpc","action":"describe-vpcs"}, {"service":"s3","action":"list-buckets"}]) - awsinspect_batch(session_id=..., subs=[ {"service":"ec2","action":"get-metrics","filters":"{\"hours\":6}"}, {"service":"rds","action":"get-metrics","filters":"{\"hours\":6}"}])

`convoawait`

Wait for a pending response from Riley after a convoreply timeout. 🎯 USE THIS TOOL WHEN: convoreply returned a timeout error. This allows you to continue waiting for the response without resending the message. REQUIRES: - session_id: from convoopen response OPTIONAL: - message_id: if known (from convoreply timeout error) - timeout (integer): seconds to wait. For Cursor, use 50 (default). Max 55. Returns the same format as convoreply when successful.

`convoinspect`

INSPECTION: View a session's conversation transcript and metadata Returns the full message history (user / assistant / tool turns) plus the session's meta — workflow step, cloud, deployment status, drift state. This is the transcript-reader companion to the other read tools — combine it with: • `convostatus` for the live stack / config / pricing • `tfruns` for deployment history (apply / destroy / plan / drift) • `stackversions` for the stack-version ladder Use it when a user asks 'what did I say earlier?' or you need to retrace why the session ended up where it did. Read-only; never mutates session state. REQUIRES: session_id (format: sess_v2_...).

`convoopen`

WORKFLOW: Step 1 of 4 - Start infrastructure design conversation Open an InsideOut V2 session and receive the assistant's intro message. The response contains a clean message from Riley (the infrastructure advisor) - display it to the user. ⚠️ Riley will ask questions - forward these to the user, DO NOT answer on their behalf. CRITICAL: This tool returns a session_id in the response metadata. You MUST use this session_id for ALL subsequent tool calls (convoreply, tfgenerate, tfdeploy, etc.). ⚠️ The session_id includes a ?token=... suffix (format: sess_v2_xxx?token=yyy) which is part of the session credential — without it, downstream tools fall back to a tokenless connect URL that 401s. Always pass session_id verbatim to subsequent tools and to the user; do NOT shorten, paraphrase, or strip the ?token= portion when summarizing the session in chat or in your own scratch notes. Use when the user mentions keywords like: 'setup my cloud infra', 'provision infrastructure', 'deploy infra', 'start insideout', 'use insideout', or similar intent to begin infra setup. OPTIONAL: project_context (string) - General tech stack summary so Riley can skip discovery questions and jump to recommendations. The agent should confirm this with the user before sending. Include whichever apply: language/framework, databases/services, container usage, existing IaC, CI/CD platform, cloud provider, Kubernetes usage, what the project does. Example: 'Next.js 14 + TypeScript, PostgreSQL, Redis, Docker Compose, deployed to AWS ECS, GitHub Actions CI/CD, ~50k MAU'. NEVER include credentials, secrets, API keys, PII, source code, or internal URLs/IPs -- only general metadata summaries useful to a cloud architect agent. IMPORTANT: source (string) - You MUST set this to identify which IDE/tool you are. Auto-detect from your environment: 'claude-code', 'codex', 'antigravity', 'kiro', 'vscode', 'web', 'mcp'. If unsure, use the name of your IDE/tool in lowercase. Do NOT omit this — it controls the 'Open {IDE}' button on the credential connect screen. OPTIONAL: github_username (string) - GitHub username for deploy commit attribution. Pre-populates the GitHub username field on the connect page. 💡 TIP: Examine workflow.usage prompt for more context on how to properly use these tools.

`convoreply`

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.

`convostatus`

INSPECTION: View the current infrastructure stack for a session Returns the current state of the user's infrastructure design including: **Components** - Selected infrastructure services (VPC, databases, caching, etc.) • Shows what services the user has chosen (e.g., PostgreSQL, Redis, S3) • Includes architecture decisions (EKS vs EC2, monolith vs microservices) **Config** - Configuration details for each component • Database sizes, replica counts, storage amounts • Cache settings, queue configurations • Backup schedules and retention policies **Pricing** - Cost estimates (when available) • Monthly cost estimates per component • Total estimated monthly spend **Phase Indicators** - Where the user is in the design workflow: • hasComponents: User has selected infrastructure services • hasConfig: User has configured component details • hasPricing: Cost estimates have been calculated • hasTerraform: Ready for Terraform generation Use this tool when the user asks 'what is my current stack?', 'show my infrastructure', 'what have I selected?', or similar questions about their design progress. REQUIRES: session_id from convoopen response (format: sess_v2_...).

`credawait`

Wait for the user to securely connect their cloud account and subscribe to Luther Systems. Polls until credentials appear on the session. 🎯 USE THIS TOOL WHEN: tfdeploy returns an 'auth_required', 'no_credentials', or 'credentials_expired' error. The user needs to visit the connect URL to: 1. Connect their cloud credentials (AWS or GCP) 2. Sign up and subscribe to a Luther Systems plan (required for deployment) This secure connection allows InsideOut to deploy and manage infrastructure in the user's cloud account on their behalf. Credentials are handled securely and only used for deployment and management sessions. WORKFLOW: 1. FIRST: Present the connect URL and explanation to the user (from the tfdeploy error response) 2. THEN: Call this tool to begin polling for credentials 3. The user opens the URL in their browser to subscribe and add credentials 4. When credentials are found, inform the user and call tfdeploy to deploy IMPORTANT: Do NOT call this tool without first showing the connect URL to the user. The user needs to see the URL to complete the process. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: cloud ('aws' or 'gcp'), timeout (integer, seconds to wait, default 300, max 600).

`gcpinspect`

INSPECTION: Inspect GCP infrastructure for a deployed project ⚠️ **PREREQUISITE**: This tool requires a prior deployment ATTEMPT (successful or failed). Check convostatus for hasDeployAttempt=true before calling. Works even after failed deploys to inspect orphaned resources. Inspect deployed GCP resources after a deployment attempt. Use this tool when the user asks about the status or details of their deployed GCP infrastructure. It fetches temporary read-only credentials securely and queries the GCP API directly. RESPONSE TIERS (default is summary for token efficiency): - Summary (default): Key fields only (~500 tokens). Set detail=false, raw=false or omit both. - Detail: Full metadata for a specific resource. Set detail=true + resource filter. - Raw: Complete unprocessed API response. Set raw=true. REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: apigateway, bastion, billing, certificatemanager, cloudarmor, cloudbuild, cloudcdn, clouddeploy, clouddns, cloudfunctions, cloudkms, cloudlogging, cloudmonitoring, cloudrun, cloudsql, compute, firestore, gcs, gke, iam, identityplatform, loadbalancer, memorystore, pubsub, secretmanager, vertexai, vpc For a specific service's actions, call with action="list-actions". METRICS: Use list-metrics to see available Cloud Monitoring metrics for any service (no credentials needed — progressive disclosure). Use get-metrics to retrieve time-series data. Optional filters JSON: {"hours":6,"period":300}. Label breakdowns: Cloud Functions (by status), Load Balancer/API Gateway (by response_code_class), Cloud CDN (by cache_result). Secret Manager get-metrics returns operational health (version count, replication, create time) — no time-series. Bastion is an alias for Compute Engine metrics (SSH connection count not available as a GCP metric). BILLING: Use service=billing to inspect GCP billing. Actions: get-billing-info (check if billing enabled, which billing account), get-budgets (list budget alerts for the project — auto-fetches billing account). Requires roles/billing.viewer IAM role. Required IAM roles: Monitoring Viewer (roles/monitoring.viewer) for metrics, Secret Manager Viewer (roles/secretmanager.viewer) for secret health, Billing Viewer (roles/billing.viewer) for billing. EXAMPLES: - gcpinspect(session_id=..., service="compute", action="list-instances") - gcpinspect(session_id=..., service="gke", action="list-clusters") - gcpinspect(session_id=..., service="cloudsql", action="get-metrics", filters="{\"hours\":6}") - gcpinspect(session_id=..., service="billing", action="get-billing-info")

`gcpinspect_batch`

BATCH INSPECTION: run up to 32 GCP inspect probes in one call. ⚠️ **PREREQUISITE**: Same as gcpinspect — deploy attempt required. Check convostatus for hasDeployAttempt=true before calling. Use this when you need to check more than ~3 resources. The backend fetches Oracle credentials ONCE per batch and fans out probes against a single GCP credentials blob — a 12-resource health check is ~5–8× faster and 12× fewer Oracle round-trips than calling gcpinspect 12 times. BUDGETS: - Up to 32 sub-probes per call (subs array length). - 30s per-sub timeout; 60s total batch wall-clock. - Concurrency cap 8. - 512 KB response cap: subs past the cap keep their envelope (index/service/action/ok) but have result replaced with truncated=true. PARTIAL FAILURE IS EXPECTED. The response is an ordered results array; each entry has {index, service, action, ok, result, error}. Inspect each result — do NOT abort on the first error. A credential fetch failure leaves cred-less probes (list-actions, list-metrics) succeeding anyway. REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: apigateway, bastion, billing, certificatemanager, cloudarmor, cloudbuild, cloudcdn, clouddeploy, clouddns, cloudfunctions, cloudkms, cloudlogging, cloudmonitoring, cloudrun, cloudsql, compute, firestore, gcs, gke, iam, identityplatform, loadbalancer, memorystore, pubsub, secretmanager, vertexai, vpc For a specific service's actions, use gcpinspect (singular) with action="list-actions" — batch is not the place for discovery. Batch responses are always summarized (no detail/raw per-sub); use singular gcpinspect when you need full metadata or raw API output for one resource. EXAMPLES: - gcpinspect_batch(session_id=..., subs=[ {"service":"compute","action":"list-instances"}, {"service":"gke","action":"list-clusters"}, {"service":"cloudsql","action":"list-instances"}]) - gcpinspect_batch(session_id=..., subs=[ {"service":"compute","action":"get-metrics","filters":"{\"hours\":6}"}, {"service":"cloudrun","action":"get-metrics","filters":"{\"hours\":6}"}])

`help`

Get workflow guidance for using InsideOut infrastructure tools. Call help() for a compact overview, or help(section=...) for a detailed guide. Sections: workflow, tools, examples, inspect. Responses include hints with next_actions and related_tools.

`stackdiff`

Structured diff showing what would be deployed if the user ran tfdeploy now. Returns component-level changes (added/removed/modified), field-level details, and pricing deltas. Defaults (#1392): with no version arguments, compares the LAST SUCCESSFULLY DEPLOYED version against the user's CURRENT LIVE DESIGN (the same data the UI shows). Empty baseline if nothing has been deployed or after a destroy. Pending drafts are NOT used as the target — they go stale once the user edits past them; live IR via chat history is always current. Pass explicit `from_version` and/or `to_version` integers to compare any two saved versions (e.g. v3 → v5). REQUIRES: session_id from convoopen response (format: sess_v2_...).

`stackrollback`

Create a draft version by reverting to a previous version's config. Copies components, config, and pricing from the target version. If a draft already exists, updates it in-place (single-draft rule). Use `stackversions` first to find available version numbers. REQUIRES: session_id from convoopen response (format: sess_v2_...), version (target version number).

`stackversions`

List all stack versions for a session (newest first). Shows version history including version number, status (draft/confirmed/applied), change summaries, and timestamps. Use this tool to see the design history, review what changed between iterations, or find a version number to roll back to. REQUIRES: session_id from convoopen response (format: sess_v2_...).

`submit_feedback`

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

`tfdeploy`

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.

`tfdestroy`

DESTROY: Tear down previously deployed infrastructure Destroys infrastructure by calling the Oracle destroy endpoint for a session that has a prior successful deployment. IMPORTANT: This starts a long-running job. Use tfstatus/tflogs to monitor progress. SINGLE-FLIGHT: only one TF job per session at a time. If another job is already in flight, tfdestroy 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: force_new (boolean, default false) - bypass the single-flight guard. Use only when the existing run is provably wedged. PREREQUISITE: The session must have a prior successful deployment with a project_id. After destroy completes, the session is kept for historical record but hasDeployment is set to false.

`tfdrift`

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.

`tfgenerate`

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.

`tflogs`

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.

`tfoutputs`

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

`tfplan`

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.

`tfruns`

INSPECTION: List all Terraform deployment runs for a session Returns job IDs, statuses, types (apply/destroy), and timestamps for every run. Use this to see deployment history, find job IDs for log inspection, or check which deployments succeeded or failed. REQUIRES: session_id from convoopen response (format: sess_v2_...).

`tfstatus`

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.

Claude Desktop / Cursor

Paste into your MCP client config file to install this server.

{
    "mcpServers": {
        "insideout \u2014 riley infrastructure agent": {
            "insideout": {
                "type": "http",
                "url": "https://app.luthersystems.com/v1/insideout-mcp"
            }
        }
    }
}

McpServers

{
    "insideout": {
        "type": "http",
        "url": "https://app.luthersystems.com/v1/insideout-mcp"
    }
}

InsideOut by Luther Systems

> Cloud infrastructure automation. Describe your application in natural language and InsideOut will design, configure, deploy, and manage production-ready backend infrastructure -- in minutes, not weeks.

Works standalone or integrated directly into AI app builders via MCP.

---

Quick Install (30 seconds)

npx skills add luthersystems/insideout-agent-skills

Works with Claude Code, Codex, Cursor, Kiro, Windsurf, and 30+ other tools.

View on Skills.sh | Try the web app -- no install required.

---

What Problem Does InsideOut Solve?

Setting up cloud infrastructure is slow, error-prone, and requires deep DevOps expertise. Teams spend weeks on plumbing -- networking, security, storage, scaling configuration -- before writing a single line of product code.

InsideOut eliminates this. You describe your application; InsideOut handles the rest: architecture design, Terraform generation, cost estimation, deployment, and ongoing management.

Before InsideOut: Weeks of manual infrastructure setup, Terraform authoring, and cloud configuration.
With InsideOut: Backend infrastructure deployed in minutes, managed continuously.

| Capability | Manual Terraform | InsideOut |
|---|---|---|
| Time to deploy | Days to weeks | Minutes |
| Security defaults | Manual | Automatic |
| Cost visibility | Post-deploy billing | Pre-deploy estimates |
| Observability setup | Manual | Day one |
| AI app builder integration | None | Native (Claude Code, Codex, Kiro, Antigravity) |
| Terraform ownership | Yes | Yes (generated, exportable) |

---

What You Can Do

- Design AWS/GCP architectures conversationally
- Get real-time cost estimates before deploying
- Generate production-ready Terraform
- Deploy infrastructure directly from your tool
- Inspect environments and detect drift
- Monitor logs and manage resources over time

---

Quick Start

Once installed, just ask:

> "Build me a scalable backend for my golang microservices app on AWS with a DB and auth."

InsideOut will:
1. Propose an architecture (ECS, RDS, Cognito, ALB, VPC...)
2. Estimate monthly cost
3. Generate production-ready Terraform
4. Deploy to your AWS or GCP account

You: "I need infrastructure for an e-commerce platform, 1k monthly users on AWS" Riley: "I'd recommend ECS for your containers, RDS PostgreSQL for your database, ElastiCache Redis for sessions, and an ALB. Estimated cost: ~$350/month. Want me to adjust anything?" You: "Looks good, generate the Terraform" [Generates production-ready Terraform files] You: "Deploy it"

[Deploys to AWS, streams logs in real-time]

---

Who Is This For?

| User | Use case |
|---|---|
| Solo developers | Ship a production backend without DevOps expertise |
| Startup engineering teams | Move from idea to deployed infrastructure in minutes |
| AI app builders | Integrate infrastructure automation directly into AI-native development workflows |
| Enterprise teams | Standardise infrastructure with best practices and cost controls |
| DevOps / platform engineers | Faster architecture and IaC workflows |

If you'd rather describe what you want than manually wire it together -- this is for you.

---

Choose Your Path

| Path | Best for | Install |
|------|----------|---------|
| This repo (recommended for Codex) | Portable skill across multiple AI tools | npx skills add luthersystems/insideout-agent-skills |
| Claude Code plugin | Best native Claude Code experience | /plugin marketplace add luthersystems/insideout-claude-code |
| Kiro power | Best native Kiro experience | Add power from GitHub: luthersystems/insideout-power |
| Web app | No install required | Open in browser |

---

Installation (Detailed)

Recommended: Skills CLI

npx skills add luthersystems/insideout-agent-skills

Claude Code

For the full plugin experience (slash commands, agents, hooks, auto-approve):

/plugin marketplace add luthersystems/insideout-claude-code
/plugin install insideout

Codex

npx skills add luthersystems/insideout-agent-skills --agent codex

Activate by typing $insideout -- Codex will detect the missing MCP server and prompt you to install it automatically.

> Fallback: If the auto-install doesn't trigger, run: codex mcp add insideout --url https://app.luthersystems.com/v1/insideout-mcp

Cursor

npx skills add luthersystems/insideout-agent-skills --agent cursor

Then add the MCP server to your Cursor MCP config:

{
  "mcpServers": {
    "insideout": {
      "type": "http",
      "url": "https://app.luthersystems.com/v1/insideout-mcp"
    }
  }
}

Windsurf

npx skills add luthersystems/insideout-agent-skills --agent windsurf

Add MCP via Windsurf MCP Marketplace or manually in settings.

Kiro

For the full power experience (steering files, design pattern guides, auto-approve):

1. Open the Powers panel
2. Click Add power from GitHub
3. Enter: luthersystems/insideout-power

Antigravity

npx skills add luthersystems/insideout-agent-skills --agent antigravity

Then add the MCP server in Antigravity: "..." menu → MCP Servers → Manage MCP Servers → View raw config:

{
  "mcpServers": {
    "insideout": {
      "serverUrl": "https://app.luthersystems.com/v1/insideout-mcp"
    }
  }
}

> Note: Antigravity uses serverUrl, not url.

Manual Installation

git clone https://github.com/luthersystems/insideout-agent-skills.git
cp -r insideout-agent-skills ~/.agents/skills/insideout

The ~/.agents/skills/ directory is the standard cross-tool location. Most AI coding tools will detect skills here automatically.

---

Supported Services (60+)

| Category | AWS | GCP |
|----------|-----|-----|
| Compute | EC2, ECS, EKS, Lambda | Compute Engine, Cloud Run, GKE, Cloud Functions |
| Database | RDS PostgreSQL, DynamoDB, ElastiCache, OpenSearch | Cloud SQL, Firestore, Memorystore |
| Networking | VPC, ALB, CloudFront, API Gateway | VPC, Load Balancing, Cloud CDN, API Gateway |
| Storage | S3 | Cloud Storage |
| Security | WAF, KMS, Secrets Manager, Cognito | Cloud Armor, Cloud KMS, Secret Manager, Identity Platform |
| Messaging | SQS, MSK (Kafka) | Pub/Sub |
| Observability | CloudWatch, Managed Grafana | Cloud Logging, Cloud Monitoring |
| AI/ML | Bedrock | Vertex AI |
| CI/CD | CodePipeline, GitHub Actions | Cloud Build |
| Backup | AWS Backup | GCP Backups |

Architecture patterns: AI Stack, Microservices, Serverless. Azure support is upcoming.

---

Core Capabilities

Infrastructure from Description

Describe your application in natural language. InsideOut generates the architecture, configuration, and Terraform. Review, tweak, and deploy -- all from one place.

Cost Visibility Before Deployment

Get cost estimates for your exact stack before committing. No surprise bills; pricing is surfaced at design time.

Secure and Observable by Default

Security best practices applied automatically. Observability configured from day one -- no retroactive setup needed.

Full Terraform Ownership

You own the generated Terraform files. Use InsideOut defaults or override any setting. No lock-in; the output is standard infrastructure-as-code.

Managed Operations

Luther Systems sets up and manages critical infrastructure. Ongoing updates and operational support included.

---

How It Works

…

No reviews yet — be the first

Use Google, GitHub, or an email account so ratings stay tied to real people.

Email sign in

No reviews posted yet.

About

Details

Jump to

Setting up with Highlight

From the repository

awsinspect

awsinspect_batch

convoawait

convoinspect

convoopen

convoreply

convostatus

credawait

gcpinspect

gcpinspect_batch

help

stackdiff

stackrollback

stackversions

submit_feedback

tfdeploy

tfdestroy

tfdrift

tfgenerate

tflogs

tfoutputs

tfplan

tfruns

tfstatus

Claude Desktop / Cursor

McpServers

InsideOut by Luther Systems

Quick Install (30 seconds)

What Problem Does InsideOut Solve?

What You Can Do

Quick Start

Who Is This For?

Choose Your Path

Installation (Detailed)

Recommended: Skills CLI

Claude Code

Codex

Cursor

Windsurf

Kiro

Antigravity

Manual Installation

Supported Services (60+)

Core Capabilities

Infrastructure from Description

Cost Visibility Before Deployment

Secure and Observable by Default

Full Terraform Ownership

Managed Operations

How It Works

Install

More like this

Aws Kb Retrieval Server

Context 7

1Panel

🔎 GPT Researcher

Serena

FastMCP v2 🚀

`awsinspect`

`awsinspect_batch`

`convoawait`

`convoinspect`

`convoopen`

`convoreply`

`convostatus`

`credawait`

`gcpinspect`

`gcpinspect_batch`

`help`

`stackdiff`

`stackrollback`

`stackversions`

`submit_feedback`

`tfdeploy`

`tfdestroy`

`tfdrift`

`tfgenerate`

`tflogs`

`tfoutputs`

`tfplan`

`tfruns`

`tfstatus`