InsideOut (Riley) is an MCP server with 24 tools an agent can call, among them awsinspect, awsinspect_batch, convoawait. It answers at https://app.luthersystems.com/v1/insideout-mcp over streamable HTTP, and it listed its tools to an anonymous client, so no sign-in was needed for that. Our probes reached it 10 of 10 times since 5 September 2026; the last check, on 18 October 2026, succeeded.
Designs, prices, and deploys AWS/GCP cloud infrastructure from plain-English requirements.
Description as the publisher wrote it.
| Tool | What it does |
|---|---|
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 dep Inputs: session_id, service, action, filters, detail, raw |
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 resou Inputs: session_id, subs |
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 c Inputs: session_id, message_id, timeout |
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 Inputs: session_id |
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. Inputs: project_context, source, github_username |
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: Inputs: session_id, text, retry, timeout, project_context |
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 Inputs: session_id, job_id |
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' Inputs: session_id, cloud, timeout |
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 dep Inputs: session_id, service, action, filters, detail, raw |
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 resou Inputs: session_id, subs |
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 relat Inputs: section |
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 S Inputs: session_id, from_version, to_version |
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 availa Inputs: session_id, version |
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 i Inputs: session_id |
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 Insi Inputs: session_id, category, message, user_email, user_name, source |
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: T Inputs: session_id, sandbox, version, plan_id, project_id, ignore_drift |
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 mon Inputs: session_id, force_new |
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 st Inputs: session_id, force_new |
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_rea Inputs: session_id, include_code |
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 Inputs: session_id, job_id, timeout, last_event_id, tail |
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 ret Inputs: session_id, job_id, lifecycle |
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, p Inputs: session_id, sandbox, force_new |
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 suc Inputs: session_id |
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 Inputs: session_id, job_id |
Every block below points at https://app.luthersystems.com/v1/insideout-mcp. Pick your client and copy.
claude mcp add --transport http insideout-riley https://app.luthersystems.com/v1/insideout-mcp
{
"mcpServers": {
"insideout-riley": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://app.luthersystems.com/v1/insideout-mcp"]
}
}
}{
"mcpServers": {
"insideout-riley": {
"url": "https://app.luthersystems.com/v1/insideout-mcp"
}
}
}{
"servers": {
"insideout-riley": {
"type": "http",
"url": "https://app.luthersystems.com/v1/insideout-mcp"
}
}
}{
"context_servers": {
"insideout-riley": {
"url": "https://app.luthersystems.com/v1/insideout-mcp"
}
}
}{
"mcpServers": {
"insideout-riley": {
"serverUrl": "https://app.luthersystems.com/v1/insideout-mcp"
}
}
}{
"mcpServers": {
"insideout-riley": {
"url": "https://app.luthersystems.com/v1/insideout-mcp"
}
}
}name: InsideOut (Riley)
version: 0.0.1
schema: v1
mcpServers:
- name: InsideOut (Riley)
type: streamable-http
url: https://app.luthersystems.com/v1/insideout-mcp{
"mcpServers": {
"insideout-riley": {
"httpUrl": "https://app.luthersystems.com/v1/insideout-mcp"
}
}
}{
"mcpServers": {
"insideout-riley": {
"type": "http",
"url": "https://app.luthersystems.com/v1/insideout-mcp"
}
}
}{
"mcpServers": {
"insideout-riley": {
"url": "https://app.luthersystems.com/v1/insideout-mcp"
}
}
}goose://extension?url=https%3A%2F%2Fapp.luthersystems.com%2Fv1%2Finsideout-mcp&type=streamable_http&id=insideout-riley&name=InsideOut%20%28Riley%29
It answered our last check on 18 October 2026 in 534 ms. Over 10 checks since 5 September 2026 it answered 10. Status here comes from Neuronto's own probes, not from the publisher.
Yes. It is published by luthersystems.com and served from app.luthersystems.com, the vendor's own domain: https://app.luthersystems.com/v1/insideout-mcp.
24, as returned by the server's own tools/list on 31 August 2026: awsinspect, awsinspect_batch, convoawait, convoinspect, convoopen, convoreply, convostatus, credawait, and 16 more.
It answered our last check on 18 October 2026 in 534 ms. Over 10 checks since 5 September 2026 it answered 10.
Put the server under mcpServers in ~/.cursor/mcp.json with the URL https://app.luthersystems.com/v1/insideout-mcp. The exact JSON is above, with the same setup for Claude Code, Claude Desktop, VS Code, Windsurf, Zed, Gemini CLI and the rest.
It listed its tools to an anonymous client, so reading the tool list needs no key. Individual tools can still ask for credentials in their own inputs.
Publisher: com.luthersystems.insideout. Endpoint host: app.luthersystems.com. ARD identifier: urn:air:com.luthersystems.insideout:mcp:mcp.
First indexed 31 August 2026. The tools are exactly what the server returned; nothing on this page
is inferred from its name. Ranking in Neuronto search is never for sale.