# InsideOut (Riley) (remote · app.luthersystems.com)

Designs, prices, and deploys AWS/GCP cloud infrastructure from plain-English requirements.

- Trust score: 66/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `app.luthersystems.com`: 66/100 (this document), [markdown](https://verifymcp.io/servers/com-luthersystems-insideout-mcp/v1-insideout-mcp.md), [page](https://verifymcp.io/servers/com-luthersystems-insideout-mcp/v1-insideout-mcp)
- oci · `docker.io/luthersystems/insideout-mcp:v0.36.3`: 36/100, [markdown](https://verifymcp.io/servers/com-luthersystems-insideout-mcp/docker-io-luthersystems-insideout-mcp-v0-36-3.md), [page](https://verifymcp.io/servers/com-luthersystems-insideout-mcp/docker-io-luthersystems-insideout-mcp-v0-36-3)

## Channel facts

- Endpoint: `https://app.luthersystems.com/v1/insideout-mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.36.3`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (tfdeploy).
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 72/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 10016 tokens (~417/item across 24 items; 24 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-luthersystems-insideout-mcp https://app.luthersystems.com/v1/insideout-mcp
```

### Codex

```toml
[mcp_servers.com-luthersystems-insideout-mcp]
url = "https://app.luthersystems.com/v1/insideout-mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-luthersystems-insideout-mcp": {
      "type": "remote",
      "url": "https://app.luthersystems.com/v1/insideout-mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-luthersystems-insideout-mcp --url https://app.luthersystems.com/v1/insideout-mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-luthersystems-insideout-mcp:
    url: "https://app.luthersystems.com/v1/insideout-mcp"
```

### Other

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

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 65, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 65, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 63, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 62)

First indexed and scored.

## MCP tools (24)

### `awsinspect` (~857 tokens)

Inspect AWS Infrastructure

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", a…

Input parameters:

- `action` (string, required): 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'…
- `detail` (boolean, required): When true, returns full metadata for a single resource (requires a resource ID in filters). When false (default), returns a summary.
- `filters` (string, required): 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.
- `raw` (boolean, required): When true, returns the unprocessed AWS API response. Escape hatch for fields the summarized response doesn't surface.
- `service` (string, required): 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.
- `session_id` (string, required): 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.…

### `awsinspect_batch` (~709 tokens)

Batch-Inspect AWS Infrastructure

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…

Input parameters:

- `session_id` (string, required): 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.…
- `subs` (null|array, required): 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 tota…

### `convoawait` (~216 tokens)

Await Pending Response

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.

Input parameters:

- `message_id` (string): Optional message ID from a convoreply timeout error. Not required for normal turn-based flow.
- `session_id` (string, required): 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.
- `timeout` (null|integer): Max seconds to wait. Default 50, max 55.

### `convoinspect` (~220 tokens)

Inspect Session Transcript

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

Input parameters:

- `session_id` (string, required): 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` (~689 tokens)

Start Design Session

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…

Input parameters:

- `github_username` (string): GitHub username used for deploy commit attribution; pre-fills the GitHub username field on the connect screen.
- `project_context` (string): 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 clou…
- `source` (string): 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', 'copilo…

### `convoreply` (~667 tokens)

Send Message

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 workflo…

Input parameters:

- `project_context` (string): 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.
- `retry` (null|boolean): When true, re-send the most recent user turn instead of submitting a new one.
- `session_id` (string, required): 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.
- `text` (string, required): User message to send to Riley. Forward verbatim what the user said — do not summarize or rewrite.
- `timeout` (null|integer): Max seconds to wait for Riley's response. Default 50, max 55.

### `convostatus` (~343 tokens)

View Session Stack Status

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

Input parameters:

- `job_id` (string): Optional. Specific job ID to inspect. When omitted, returns the status of the latest job for the session.
- `session_id` (string, required): 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.

### `credawait` (~389 tokens)

Await Cloud Credentials

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

Input parameters:

- `cloud` (string): Cloud provider whose credentials are awaited: 'aws' or 'gcp'. Defaults to 'aws'.
- `session_id` (string, required): 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.
- `timeout` (null|integer): Max seconds to wait for the user to complete the browser-based credential connect flow. Default 300, max 600.

### `gcpinspect` (~886 tokens)

Inspect GCP Infrastructure

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…

Input parameters:

- `action` (string, required): Operation on the service. Examples: 'list-instances' (compute), 'list-buckets' (storage), 'list-clusters' (gke), 'list-actions' (discovery), 'list-metrics' / 'get-metrics' (Cloud Monitoring).
- `detail` (boolean, required): When true, returns full metadata for a single resource. When false (default), returns a summary.
- `filters` (string, required): 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.
- `raw` (boolean, required): When true, returns the unprocessed GCP API response. Escape hatch for fields the summarized response doesn't surface.
- `service` (string, required): GCP service to query. Examples: 'compute', 'storage', 'cloudsql', 'gke', 'cloudrun', 'pubsub', 'firestore'. Use action='list-actions' to discover supported actions for a service.
- `session_id` (string, required): 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.…

### `gcpinspect_batch` (~689 tokens)

Batch-Inspect GCP Infrastructure

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","filte…

Input parameters:

- `session_id` (string, required): 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.…
- `subs` (null|array, required): 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 tota…

### `help` (~94 tokens)

Workflow Guide

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.

Input parameters:

- `section` (string): Optional section to focus the response. One of: 'workflow', 'tools', 'examples', 'inspect'. When omitted, returns a compact overview (~500 tokens).

### `stackdiff` (~266 tokens)

Compare Stack Versions

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

Input parameters:

- `from_version` (null|integer): Starting stack version number for the diff. Defaults to the latest applied version.
- `session_id` (string, required): 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.
- `to_version` (null|integer): Ending stack version number for the diff. Defaults to the current draft.

### `stackrollback` (~162 tokens)

Rollback Stack Version

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

Input parameters:

- `session_id` (string, required): 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.
- `version` (integer, required): Target stack version number to roll back to. Use stackversions to list available versions.

### `stackversions` (~139 tokens)

List Stack Versions

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

Input parameters:

- `session_id` (string, required): 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` (~446 tokens)

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

Input parameters:

- `category` (string, required): Feedback category. One of: bug_report, feature_request, general_feedback, question.
- `initiator` (string): Optional originator: 'user' (human triggered) or 'agent' (automated).
- `message` (string, required): Feedback content. Free-form text describing the issue, request, or comment.
- `session_id` (string, required): 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.…
- `source` (string): Optional source channel: 'mcp', 'cli', or 'web'.
- `user_email` (string): Optional email address for follow-up.
- `user_name` (string): Optional display name for attribution.

### `tfdeploy` (~607 tokens)

Deploy Infrastructure

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.

Input parameters:

- `force_new` (null|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.
- `ignore_drift` (null|boolean): When true, proceed with deploy even if drift is detected on the existing stack.
- `plan_id` (string): Apply a previously created plan from tfplan. When set, project_id should also be provided.
- `project_id` (string): Project ID returned by tfplan. Required alongside plan_id.
- `sandbox` (null|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.
- `session_id` (string, required): 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.
- `version` (null|integer): Deploy a specific stack version number. Defaults to the current draft.

### `tfdestroy` (~291 tokens)

Destroy Infrastructure

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.

Input parameters:

- `force_new` (null|boolean): When true, bypass the single-flight guard and force a new destroy even if another job is in flight.
- `session_id` (string, required): 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.…

### `tfdrift` (~292 tokens)

Check Infrastructure Drift

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.

Input parameters:

- `force_new` (null|boolean): When true, bypass the single-flight guard and force a new drift check even if another job is in flight.
- `session_id` (string, required): 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.

### `tfgenerate` (~487 tokens)

Generate Terraform

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.

Input parameters:

- `include_code` (null|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).
- `session_id` (string, required): 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.…

### `tflogs` (~486 tokens)

Fetch Deploy Logs

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.

Input parameters:

- `job_id` (string): Optional. Target a specific job. Use tfruns to discover job IDs. When omitted, streams the latest job for the session.
- `last_event_id` (string): Resume cursor for pagination. Pass back the last_event_id from a previous tflogs response to fetch only newer entries.
- `session_id` (string, required): 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.
- `tail` (null|integer): Return only the last N log entries. Use 0 (or omit) for all available entries.
- `timeout` (null|integer): Max seconds to collect logs. Default 50, max 55.

### `tfoutputs` (~257 tokens)

Get Deploy Outputs

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

Input parameters:

- `job_id` (string): Optional. Specific job ID to fetch outputs from. When omitted, returns outputs from the latest successful apply.
- `lifecycle` (string): 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, r…
- `session_id` (string, required): 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.

### `tfplan` (~343 tokens)

Preview Infrastructure Plan

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.

Input parameters:

- `force_new` (null|boolean): When true, bypass the single-flight guard and force a new plan even if one is already running.
- `sandbox` (null|boolean): When true, plan against the sandbox stack; when false (default), plan the real generated Terraform.
- `session_id` (string, required): 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.

### `tfruns` (~153 tokens)

List Deploy Runs

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

Input parameters:

- `session_id` (string, required): 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.…

### `tfstatus` (~328 tokens)

Check Deploy Status

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.

Input parameters:

- `job_id` (string): Optional. Specific job ID to inspect. When omitted, returns the status of the latest job for the session.
- `session_id` (string, required): 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.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-luthersystems-insideout-mcp/v1-insideout-mcp#diagnostics

## Score history

- 2026-08-03: 66
- 2026-08-02: 66
- 2026-08-01: 65
- 2026-07-31: 65
- 2026-07-30: 65
- 2026-07-29: 64
- 2026-07-28: 64
- 2026-07-27: 63
- 2026-07-26: 62

## Links

- Remote endpoint: https://app.luthersystems.com/v1/insideout-mcp
- Repository: https://github.com/luthersystems/insideout-agent-skills
- Website: https://insideout.luthersystems.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-luthersystems-insideout-mcp/v1-insideout-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-luthersystems-insideout-mcp/v1-insideout-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/com-luthersystems-insideout-mcp/v1-insideout-mcp