Skip to main content
Glama

InsideOut (Riley)

by com.luthersystems.app

View Session Stack Status

convostatus
Read-only

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idNoOptional. Specific job ID to inspect. When omitted, returns the status of the latest job for the session.
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.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description reinforces a read-only inspection role. It adds context about data availability (pricing when available), phase indicators, and that the session_id is a credential that should not be altered—useful beyond annotations.

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?

The description is well-structured with markdown sections and front-loaded purpose. It is somewhat lengthy but every section contributes meaningful detail about return contents and usage, so it earns its place.

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?

Given the tool's read-only nature, no output schema, and simple parameter set, the description covers return content comprehensively (components, config, pricing, phases) and mentions constraints (required session_id format). Minor gaps like error behavior or further alternatives prevent a 5.

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 baseline is 3. The description adds meaning by emphasizing that session_id must be passed exactly as returned (including token suffix) and explaining job_id's optional role—valuable behavior beyond schema 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 clearly states the verb+resource: 'View the current infrastructure stack for a session' and breaks down the returned content (Components, Config, Pricing, Phase Indicators). This distinguishes it from sibling inspection tools like awsinspect or convoinspect, which focus on different resources.

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?

Provides explicit when-to-use guidance with example user queries ('what is my current stack?') and notes the required session_id. While it does not list alternatives or exclusions, the context is clear enough for an agent to select this tool appropriately.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, with clear domain prefixes (convo*, tf*, stack*, aws/gcp inspect) separating conversation, deployment, versioning, and cloud inspection. The batch variants (awsinspect_batch, gcpinspect_batch) are explicitly scoped as higher-throughput versions of their singular counterparts, so no ambiguity exists.

Naming Consistency4/5

The naming is mostly consistent: lowercase concatenated verb_noun patterns dominate (convoopen, tfdeploy, stackrollback, awsinspect). However, submit_feedback uses snake_case, and help stands alone as a generic utility, breaking the otherwise uniform lowercase-concatenated style.

Tool Count4/5

24 tools is on the heavier side, but the count is justified by the breadth of the domain: conversation workflow, multi-cloud inspection, Terraform lifecycle, stack versioning, and utilities. Each tool fills a distinct role, so while slightly high, the count is not bloated.

Completeness5/5

The tool surface covers the full infrastructure lifecycle: conversation and design (convoopen/convoreply/convostatus), Terraform generation and deployment (tfgenerate/tfplan/tfdeploy), monitoring (tfstatus/tflogs), teardown (tfdestroy), drift detection, stack versioning, and cloud inspection. No critical dead ends; only a missing explicit cancel/abort for running jobs is a minor gap.

Resources