InsideOut (Riley)

Submit Feedback

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 Schema

TableJSON Schema

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

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only provide openWorldHint and destructiveHint, so the description carries the burden of behavioral context. It adds meaningful detail: initiator semantics ('user' vs 'agent'), the credential warning to never strip the session_id token suffix, and the source default. It doesn't describe post-submission behavior, but still adds substantial value 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.

Conciseness5/5

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

Front-loaded with a clear purpose statement, then structured requirements, categories, initiator explanation, and concrete examples. Every section earns its place and the length is justified by the added explanatory value.

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 7-parameter feedback tool with full schema documentation and no output schema, the description covers required and optional fields, category enumerations, initiator flow, and an important credential-handling caveat. It is complete enough for an agent to invoke the tool correctly without additional clarification.

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. The description adds value by explaining the initiator field with concrete examples, noting source default 'mcp', and emphasizing the exact session_id format with token suffix. It largely restates schema information but enriches it with usage context.

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?

Description explicitly states 'Submit feedback, bug reports, or feature requests to Luther Systems' and lists categories such as bug_report and feature_request. This gives a specific verb + resource and clearly distinguishes it from all sibling infrastructure tools.

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?

Description says 'Use this tool to forward user feedback directly to the Luther Systems team' and provides examples for both user and agent initiators. It does not explicitly state when not to use the tool or mention alternatives, but the context and examples make intended usage clear.

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

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

Need Help?