Skip to main content
Glama
Sign In

InsideOut (Riley)

by com.luthersystems.app
OverviewDiscussionsAdmin

Workflow Guide

help
Read-only

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.

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": "help"
  }
}

Input Schema

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

Output Schema

NameRequiredDescriptionDefault
dirtyNoTrue when the server was built from a modified tree.
hintsNoGuidance for the calling agent: what to do next and which tools relate to this result.
sectionNoGuide section returned, when help(section=...) was called.
versionNoServer version.
base_urlNoInsideOut backend URL the server talks to.
transportNoMCP transport in use (for example 'stdio' or 'http').
build_timeNoServer build time.
git_commitNoGit commit the server was built from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "base_url": {
+      "description": "InsideOut backend URL the server talks to.",
+      "type": "string"
+    },
+    "build_time": {
+      "description": "Server build time.",
+      "type": "string"
+    },
+    "dirty": {
+      "description": "True when the server was built from a modified tree.",
+      "type": "boolean"
+    },
+    "git_commit": {
+      "description": "Git commit the server was built from.",
+      "type": "string"
+    },
+    "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"
+      ]
+    },
+    "section": {
+      "description": "Guide section returned, when help(section=...) was called.",
+      "type": "string"
+    },
+    "transport": {
+      "description": "MCP transport in use (for example 'stdio' or 'http').",
+      "type": "string"
+    },
+    "version": {
+      "description": "Server version.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / section / description
      Added value: +"Optional section to focus the response. One of: 'workflow', 'tools', 'examples', 'inspect'. When omitted, returns a compact overview (~500 tokens)."
    • addedInput schema / properties / section / enum
      Added value: +[
+  "workflow",
+  "tools",
+  "examples",
+  "inspect"
+]
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: responses carry hints with next_actions and related_tools, telling the agent to expect follow-up suggestions.

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

Conciseness4/5

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

Four short, front-loaded sentences: purpose first, then invocation modes, section list, and response shape. Every sentence carries information, though the section enumeration overlaps with the schema.

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

Completeness4/5

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

An output schema exists, so return values need no prose, and the description still notes the hint structure. For a single optional-enum guidance tool this is sufficient; only a note on when to reach for help is absent.

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

Parameters3/5

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

Schema coverage is 100% and the single enum parameter is fully documented in the schema, including the omitted-behavior default. The description merely restates the section names, adding no syntax or meaning beyond the structured field. Baseline 3 applies.

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 ('Get workflow guidance') and scopes it to the InsideOut infrastructure toolset. This clearly separates it from every sibling, all of which are operational tools (tfdeploy, awsinspect, etc.) rather than meta/guidance.

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

Usage Guidelines4/5

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

Gives concrete invocation guidance: help() for a compact overview vs help(section=...) for a detailed guide, and enumerates the four sections. There are no competing alternatives to exclude, but it also doesn't state when in an agent's workflow it should be called.

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