InsideOut (Riley)

Start Design Session

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "convoopen"
  }
}

Input Schema

Name	Required	Description
`source`	No	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_username`	No	GitHub username used for deploy commit attribution; pre-fills the GitHub username field on the connect screen.
`project_context`	No	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.

Output Schema

Name	Required	Description
`hints`	No	Guidance for the calling agent: what to do next and which tools relate to this result.
`session_id`	No	Session ID this result belongs to (format sess_v2_?token=). Pass it back verbatim to later tools.
`assistant_message`	No	Riley's reply, cleaned of internal markers. Show it to the user.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "assistant_message": {
+      "description": "Riley's reply, cleaned of internal markers. Show it to the user.",
+      "properties": {
+        "text": {
+          "description": "The message text.",
+          "type": "string"
+        }
+      },
+      "type": [
+        "null",
+        "object"
+      ]
+    },
+    "hints": {
+      "description": "Guidance for the calling agent: what to do next and which tools relate to this result.",
+      "properties": {
+        "next_actions": {
+          "description": "Suggested next steps, in order, often as ready-to-run tool calls.",
+          "items": {
+            "description": "One suggested next step.",
+            "type": "string"
+          },
+          "type": [
+            "null",
+            "array"
+          ]
+        },
+        "related_tools": {
+          "description": "Names of tools that are useful after this result.",
+          "items": {
+            "description": "A tool name.",
+            "type": "string"
+          },
+          "type": [
+            "null",
+            "array"
+          ]
+        }
+      },
+      "type": [
+        "null",
+        "object"
+      ]
+    },
+    "session_id": {
+      "description": "Session ID this result belongs to (format sess_v2_*?token=*). Pass it back verbatim to later tools.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedMay 7, 2026

addedInput schema / properties / github_username / description

Added value: +"GitHub username used for deploy commit attribution; pre-fills the GitHub username field on the connect screen."

addedInput schema / properties / project_context / description

Added value: +"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."

addedInput schema / properties / source / description

Added value: +"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'."

First observedMay 5, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it discloses that the response carries an intro message from 'Riley' to relay verbatim, that questions must be forwarded rather than answered, and that a session_id with a ?token= credential suffix appears in metadata and must be passed unmodified to downstream tools or they 401. This is exactly the operational context annotations (readOnly=false, openWorld=true) cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the workflow position, which is good, but the body is heavy with emoji warnings and repeats the session_id/?token= instruction across two consecutive paragraphs. Every point is useful, yet the same message is stated more than once, costing structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a session-opening tool with an output schema, the description supplies everything an agent needs: the trigger, the return handling (relay message, forward questions), the credential-passing contract for all downstream tools, and full parameter guidance. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it tells the agent to confirm project_context with the user before sending and enumerates what to include and explicitly exclude (secrets, PII, source code), and explains source auto-detection and its effect on the connect button.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Open an InsideOut V2 session and receive the assistant's intro message.' It is placed within a numbered workflow (Step 1 of 4) and clearly distinguished from siblings like convoreply, convostatus, and tfgenerate, which are named as downstream steps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger conditions ('setup my cloud infra', 'provision infrastructure', 'start insideout') and positions itself as the entry point of a 4-step workflow, so the agent knows both when to call it and how it relates to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All InsideOut (Riley) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?