Designs, prices, and deploys AWS/GCP cloud infrastructure from plain-English requirements.
healthy
status
24
tools exposed
10480ms
connect latency
0fa2082bef5e
schema fingerprint
Tools (24)
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 re
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
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
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:
• `
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
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 question
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)
• In
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. Conn
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 re
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
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 LIV
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 r
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.
REQUI
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 iss
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
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
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
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 c
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 pagina
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 s
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
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 respo
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 dep
Endpoint
https://app.luthersystems.com/v1/insideout-mcp Category: Cloud & Infra · Last checked: 2026-07-30T13:03:42Z
Monitor your own MCP server
Get alerted the moment yours goes down, a tool schema drifts, or an upstream silently breaks.
What this means. This server responded to the MCP handshake and listed its tools without authentication. The schema fingerprint lets us flag if tool signatures silently change (schema drift) between checks.