Designs, prices, and deploys AWS/GCP cloud infrastructure from plain-English requirements.
Design, price, and deploy AWS and GCP infrastructure from plain-English specifications.
Topics
ai-agentmcp-server
Captured live from the server via tools/list.
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)
Parameters (6)
session_idstringrequired
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. The session must have an AWS deploy attempt before inspect probes will succeed.
servicestringrequired
AWS service to query. Examples: 'ec2', 'rds', 'vpc', 's3', 'lambda', 'eks', 'ecs', 'cost-explorer'. Use action='list-actions' to discover the supported actions for a service.
actionstringrequired
Operation on the service. Examples: 'describe-instances' (ec2), 'list-buckets' (s3), 'list-keys' (kms), 'get-cost-summary' (cost-explorer), 'list-actions' (discovery), 'list-metrics' / 'get-metrics' (CloudWatch).
filtersstringrequired
Optional JSON-encoded filter object passed through to the underlying AWS API. Examples: '{"hours":6}' for metric windows, '{"days":7,"granularity":"DAILY"}' for cost queries.
detailbooleanrequired
When true, returns full metadata for a single resource (requires a resource ID in filters). When false (default), returns a summary.
rawbooleanrequired
When true, returns the unprocessed AWS API response. Escape hatch for fields the summarized response doesn't surface.
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}"}])
Parameters (2)
session_idstringrequired
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. The session must have an AWS deploy attempt before inspect probes will succeed.
subsnull | arrayrequired
Up to 32 sub-probes, each with {service, action, filters?, detail?, raw?}. The backend fetches credentials once per batch and fans out probes in parallel (concurrency 8, 30s per-sub timeout, 60s total wall clock). Partial failure is expected — inspect each result.ok independently.
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.
Parameters (3)
session_idstringrequired
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.
message_idstring
Optional message ID from a convoreply timeout error. Not required for normal turn-based flow.
timeoutnull | integer
Max seconds to wait. Default 50, max 55.
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_...).
Parameters (1)
session_idstringrequired
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.
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.
Parameters (3)
project_contextstring
Optional tech-stack summary so Riley can skip discovery questions (e.g. 'Next.js 14 + Postgres on AWS, ~50k MAU'). No PII, secrets, file paths, or source code — only general metadata useful to a cloud architect.
sourcestring
IDE/tool identifier so the connect screen can show the right 'Open {IDE}' button. Use lowercase: 'claude-code', 'codex', 'antigravity', 'kiro', 'cursor', 'vscode', 'windsurf', 'zed', 'aider', 'copilot', 'web', 'mcp'.
github_usernamestring
GitHub username used for deploy commit attribution; pre-fills the GitHub username field on the connect screen.
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.
Parameters (5)
session_idstringrequired
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.
textstringrequired
User message to send to Riley. Forward verbatim what the user said — do not summarize or rewrite.
retrynull | boolean
When true, re-send the most recent user turn instead of submitting a new one.
timeoutnull | integer
Max seconds to wait for Riley's response. Default 50, max 55.
project_contextstring
Only NEW project details revealed after convoopen (e.g. user mentions a new constraint mid-conversation). Don't re-send context already provided in convoopen. No PII or secrets.
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_...).
Parameters (2)
session_idstringrequired
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.
job_idstring
Optional. Specific job ID to inspect. When omitted, returns the status of the latest job for the session.
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).
Parameters (3)
session_idstringrequired
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.
cloudstring
Cloud provider whose credentials are awaited: 'aws' or 'gcp'. Defaults to 'aws'.
timeoutnull | integer
Max seconds to wait for the user to complete the browser-based credential connect flow. 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")
Parameters (6)
session_idstringrequired
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. The session must have a GCP deploy attempt before inspect probes will succeed.
servicestringrequired
GCP service to query. Examples: 'compute', 'storage', 'cloudsql', 'gke', 'cloudrun', 'pubsub', 'firestore'. Use action='list-actions' to discover supported actions for a service.
actionstringrequired
Operation on the service. Examples: 'list-instances' (compute), 'list-buckets' (storage), 'list-clusters' (gke), 'list-actions' (discovery), 'list-metrics' / 'get-metrics' (Cloud Monitoring).
filtersstringrequired
Optional JSON-encoded filter object passed through to the underlying GCP API. Examples: '{"hours":6}' for metric windows, '{"zone":"us-central1-a"}' for zone-scoped queries.
detailbooleanrequired
When true, returns full metadata for a single resource. When false (default), returns a summary.
rawbooleanrequired
When true, returns the unprocessed GCP API response. Escape hatch for fields the summarized response doesn't surface.
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}"}])
Parameters (2)
session_idstringrequired
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. The session must have a GCP deploy attempt before inspect probes will succeed.
subsnull | arrayrequired
Up to 32 sub-probes, each with {service, action, filters?, detail?, raw?}. The backend fetches credentials once per batch and fans out probes in parallel (concurrency 8, 30s per-sub timeout, 60s total wall clock). Partial failure is expected — inspect each result.ok independently.
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.
Parameters (1)
sectionstring
Optional section to focus the response. One of: 'workflow', 'tools', 'examples', 'inspect'. When omitted, returns a compact overview (~500 tokens).
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_...).
Parameters (3)
session_idstringrequired
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.
from_versionnull | integer
Starting stack version number for the diff. Defaults to the latest applied version.
to_versionnull | integer
Ending stack version number for the diff. Defaults to the current draft.
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).
Parameters (2)
session_idstringrequired
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.
versionintegerrequired
Target stack version number to roll back to. Use stackversions to list available versions.
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_...).
Parameters (1)
session_idstringrequired
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.
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')
Parameters (7)
session_idstringrequired
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. Identifies the conversation the feedback is about.
categorystringrequired
Feedback category. One of: bug_report, feature_request, general_feedback, question.
messagestringrequired
Feedback content. Free-form text describing the issue, request, or comment.
user_emailstring
Optional email address for follow-up.
user_namestring
Optional display name for attribution.
sourcestring
Optional source channel: 'mcp', 'cli', or 'web'.
initiatorstring
Optional originator: 'user' (human triggered) or 'agent' (automated).
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.
Parameters (7)
session_idstringrequired
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.
sandboxnull | boolean
When true (default for MCP), deploys a small sandbox stack instead of the real generated Terraform. Set false to deploy the actual user stack.
versionnull | integer
Deploy a specific stack version number. Defaults to the current draft.
plan_idstring
Apply a previously created plan from tfplan. When set, project_id should also be provided.
project_idstring
Project ID returned by tfplan. Required alongside plan_id.
ignore_driftnull | boolean
When true, proceed with deploy even if drift is detected on the existing stack.
force_newnull | boolean
When true, bypass the session-level single-flight guard and start a new deploy even if another job is in flight. Use only when an existing run is provably wedged.
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.
Parameters (2)
session_idstringrequired
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. The deployed stack for this session will be torn down.
force_newnull | boolean
When true, bypass the single-flight guard and force a new destroy even if another job is in flight.
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.
Parameters (2)
session_idstringrequired
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.
force_newnull | boolean
When true, bypass the single-flight guard and force a new drift check even if another job is in flight.
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.
Parameters (2)
session_idstringrequired
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_codenull | boolean
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).
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.
Parameters (5)
session_idstringrequired
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.
job_idstring
Optional. Target a specific job. Use tfruns to discover job IDs. When omitted, streams the latest job for the session.
timeoutnull | integer
Max seconds to collect logs. Default 50, max 55.
last_event_idstring
Resume cursor for pagination. Pass back the last_event_id from a previous tflogs response to fetch only newer entries.
tailnull | integer
Return only the last N log entries. Use 0 (or omit) for all available entries.
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').
Parameters (3)
session_idstringrequired
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.
job_idstring
Optional. Specific job ID to fetch outputs from. When omitted, returns outputs from the latest successful apply.
lifecyclestring
Optional Oracle deploy-step filter for the outputs. Common values are 'provision', 'cloud-provision', 'k8s-provision' — these correspond to the lifecycle stages of the deployed stack. When omitted, returns outputs from all lifecycle steps.
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.
Parameters (3)
session_idstringrequired
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.
sandboxnull | boolean
When true, plan against the sandbox stack; when false (default), plan the real generated Terraform.
force_newnull | boolean
When true, bypass the single-flight guard and force a new plan even if one is already running.
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_...).
Parameters (1)
session_idstringrequired
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. Returns the deployment-job history (apply / destroy / plan / drift) for this session.
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.
Parameters (2)
session_idstringrequired
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.
job_idstring
Optional. Specific job ID to inspect. When omitted, returns the status of the latest job for the session.
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.
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:
Propose an architecture (ECS, RDS, Cognito, ALB, VPC...)
Estimate monthly cost
Generate production-ready Terraform
Deploy to your AWS or GCP account
code
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.
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
InsideOut uses a multi-agent AI system behind a single MCP server:
Agent
Role
Riley
Infrastructure advisor -- leads the design conversation
Hippo
Cost estimation and pricing optimization
Joy
User experience and requirement gathering
Etch
Terraform code generation
Core
Architecture validation and best practices
Axel
Deployment orchestration
From your perspective, you're talking to Riley. The other agents work behind the scenes. These capabilities are exposed as tools inside your AI environment, so you use them conversationally.
Security & Auth Model
No API key required to install or use the skill
The MCP server runs remotely over HTTPS -- no local binary needed
Cloud credentials are only required at deployment time, via a browser-based connect flow
You control what gets deployed into your cloud accounts
You can review all generated Terraform before deploying
See SECURITY.md for detailed data flow documentation.
Terraform Presets and Modules
InsideOut uses a library of battle-tested, standard Terraform modules composed for common infrastructure patterns.
Standard Modules -- underlying Luther Enterprise infrastructure modules
FAQ
Can I use InsideOut without the InsideOut UI?
Yes. InsideOut integrates with Claude Code, Codex, Kiro, Antigravity, and any MCP-compatible AI development environment, allowing you to design, price, and deploy infrastructure directly from your editor without opening the InsideOut interface.
Do I own the generated Terraform?
Yes. InsideOut generates standard Terraform files that you own and can export, modify, or use independently of the platform.
Can I override the default configuration?
Yes. InsideOut applies best-practice defaults but every setting is overridable. You control the final configuration before deployment.
What clouds does InsideOut support?
AWS and Google Cloud Platform. AWS has the deepest support with the widest range of resource types. Azure support is upcoming.
Is InsideOut suitable for AI application backends?
Yes. InsideOut explicitly supports AI stack architectures and is designed to work within AI-native development environments like Claude Code, Codex, Kiro, Antigravity, and other MCP-compatible tools.
How does pricing work?
Cost estimates for your exact stack are surfaced before deployment. Contact Luther Systems for platform pricing: contact@luthersystems.com
Luther Systems is an enterprise infrastructure and automation company founded in 2015, headquartered in London, UK. Our mission is to accelerate the advent of the automated enterprise.
Founded by a team who spent years automating complex processes for some of the world's largest financial institutions, Luther Systems builds platforms that bring enterprise-grade infrastructure and operations to teams of every size.
