Skip to main content
Glama
Sign In

InsideOut (Riley)

by com.luthersystems.app
OverviewDiscussionsAdmin

Send Message

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>",
      "text": "<text>"
    },
    "name": "convoreply"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesUser message to send to Riley. Forward verbatim what the user said ā€” do not summarize or rewrite.
retryNoWhen true, re-send the most recent user turn instead of submitting a new one.
timeoutNoMax seconds to wait for Riley's response. Default 50, max 55.
session_idYesSession 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.
project_contextNoOnly 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.

Output Schema

NameRequiredDescriptionDefault
hintsNoGuidance for the calling agent: what to do next and which tools relate to this result.
statusNoOutcome of the call: 'ok' (Riley replied), 'timeout' (still working; call convoawait), or 'pending_exists' (an earlier reply is still pending; call convoawait).
message_idNoID of Riley's reply message.
session_idNoSession ID this result belongs to (format sess_v2_*?token=*). Pass it back verbatim to later tools.
instructionNoPlain-language instruction for the agent when the reply is not ready yet.
next_actionNoTool to call next when the reply is not ready yet (for example 'convoawait').
terraform_readyNoTrue when Riley signalled that the design is final and tfgenerate can be called.
assistant_messageNoRiley's reply, cleaned of internal markers. Show it to the user.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+      ]
+    },
+    "instruction": {
+      "description": "Plain-language instruction for the agent when the reply is not ready yet.",
+      "type": "string"
+    },
+    "message_id": {
+      "description": "ID of Riley's reply message.",
+      "type": "string"
+    },
+    "next_action": {
+      "description": "Tool to call next when the reply is not ready yet (for example 'convoawait').",
+      "type": "string"
+    },
+    "session_id": {
+      "description": "Session ID this result belongs to (format sess_v2_*?token=*). Pass it back verbatim to later tools.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Outcome of the call: 'ok' (Riley replied), 'timeout' (still working; call convoawait), or 'pending_exists' (an earlier reply is still pending; call convoawait).",
+      "type": "string"
+    },
+    "terraform_ready": {
+      "description": "True when Riley signalled that the design is final and tfgenerate can be called.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • removedInput schema / properties / auto_accept
      Removed value: -{
-  "description": "When true, Riley skips setup confirmation gates and proceeds with defaults. Only affects the setup phase (not management, deploy, or destroy). Default true for MCP.",
-  "type": [
-    "null",
-    "boolean"
-  ]
-}
  3. Changed11 schema fields changed
    • addedInput schema / properties / auto_accept / description
      Added value: +"When true, Riley skips setup confirmation gates and proceeds with defaults. Only affects the setup phase (not management, deploy, or destroy). Default true for MCP."
    • addedInput schema / properties / project_context / description
      Added value: +"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."
    • addedInput schema / properties / retry / description
      Added value: +"When true, re-send the most recent user turn instead of submitting a new one."
    • addedInput schema / properties / session_id / description
      Added value: +"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."
    • addedInput schema / properties / session_id / pattern
      Added value: +"^sess_v2_[0-9A-Za-z]+\\?token=[0-9a-f]+$"
    • addedInput schema / properties / text / description
      Added value: +"User message to send to Riley. Forward verbatim what the user said ā€” do not summarize or rewrite."
    • addedInput schema / properties / text / maxLength
      Added value: +20000
    • addedInput schema / properties / text / minLength
      Added value: +1
    • addedInput schema / properties / timeout / description
      Added value: +"Max seconds to wait for Riley's response. Default 50, max 55."
    • addedInput schema / properties / timeout / maximum
      Added value: +55
    • addedInput schema / properties / timeout / minimum
      Added value: +1
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and openWorldHint=true, but the description goes well beyond them: it discloses that the call blocks for a response (timeout default 50, max 55), that the response is gated on server-side signals, and it carries a strong behavioral constraint ('DO NOT answer Riley's questions yourself... STOP and wait'). This is real operational context the annotations 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?

The workflow step is front-loaded and the sections are labeled, but the description is bloated: the 'do not answer Riley' warning is repeated three times in escalating caps, and the response-signal list restates gating rules already covered in the workflow section. Emoji-heavy ALL-CAPS formatting adds length without adding information.

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?

With an output schema present, return values need not be explained, yet the description usefully summarizes the key in-band signals ([TERRAFORM_READY], [[BUTTON_TF_*]]). Given this is a stateful, non-idempotent, open-world call, the description supplies the session requirements, blocking behavior, and downstream gating an agent needs to call it correctly.

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 genuine value: it flags session_id's provenance and exact-pass-back requirement, gives environment-specific timeout advice ('For Cursor, use 50'), and constrains project_context to genuinely new details with an explicit example. It stops short of 5 only because much of this overlaps the schema's own descriptions.

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?

The description states a specific verb and resource: 'Send a user message to the active InsideOut session and receive the assistant reply,' and adds the return semantics ('contains a clean message from Riley'). Combined with the 'Step 2 of 4' framing, an agent can distinguish this from convoopen, convostatus, and convoawait without opening any schema.

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?

Explicit routing is provided: the conversation ā†’ tfgenerate ā†’ tfdeploy phase order, the condition that unlocks tfgenerate ('when terraform_ready=true appears in THIS tool's response'), and per-signal instructions for tfplan, tfdeploy, and tfdestroy. It even names convostatus as the progress-checking alternative. Nothing about when to call this vs. siblings is left to inference.

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

All InsideOut (Riley) toolsInspect
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