Loading ToolBench

Reading the current corpus…

ryx-sidekick-lite MCP server · F · ToolBench

ryx-sidekick-lite

AI coding assistant for Unity. Run the Claude Code CLI inside the Editor with streaming chat, project context, and safe edits.

<=2025-11-2513 tools

29/100

Definition Quality29

Protocol Readiness12

Supportability40

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Ryx Sidekick is a Unity Editor plugin (not a standard MCP server). Tool definitions are inferred from renderer classes rather than explicitly registered via MCP protocol. Schemas are partially visible but lack formal JSON Schema structure. Descriptions exist but are generic (10-50 chars). Many tools accept multiple parameter aliases (command/cmd, file_path/filePath/path) which signals poor parameter design. No input validation, error recovery guidance, or output schema documentation visible. The bash tool is destructive with no confirmation pattern. File tools (read/write/edit) lack permission gates. Overall structure suggests a custom agent framework, not MCP-compliant.

Tools (13)

ask_user_questionread only33/100

Ask the user a question and wait for response

bashdestructive45/100

Execute bash commands with streaming output and terminal input support

editwrite43/100

Edit file contents using old_string/new_string replacement

exit_plan_moderead only30/100

Exit plan mode and return to normal operation

implement_planwrite30/100

Execute a plan with structured steps

mcpirreversible22/100

Call external MCP (Model Context Protocol) server tools

readread only50/100

Read file contents with optional line range specification

searchread only42/100

Search for files or patterns in a directory

taskwrite28/100

Create and manage sub-agent tasks with status tracking

Issues (5)

CRITICALtool ↗

Tool definitions inferred from renderer classes, not explicitly registered via MCP protocol. No formal tool registration visible in source.

mcpask_user_questionimplement_planexit_plan_modetasktask_createtask_update

HIGHconstrained-input ↗

Multiple parameter aliases (command/cmd, file_path/filePath/path) indicate poor parameter design. Should use single canonical names with clear type suffixes (file_path, not path).

bashreadwriteeditsearch

HIGHconfirmation-request ↗

Destructive tools (bash, write, edit) lack confirmation patterns, dry-run support, or permission gates. No error recovery guidance.

bashwriteedit

HIGHresponse-shaper ↗

Recommendations

Migrate to explicit MCP tool registration with formal JSON Schema. Each tool must declare name, description (50-200 chars), and input schema with typed, described parameters.
Consolidate parameter aliases into single canonical names. Use verb_noun_type naming: file_path (not path/filePath), search_pattern (not pattern/query/regex/glob), root_directory (not root/cwd/folder).
Add confirmation patterns for destructive tools (bash, write, edit). Implement dry-run mode or require explicit confirmation before execution. Return actionable error messages with recovery steps.
Document output schemas for all tools. Specify return type (object/array), field names, types, and which fields enable chaining to downstream tools (e.g., file_path from search enables read/write).
Expand tool descriptions to 100-200 characters. Answer: What does it do? When should the LLM call it? What does it return? Include dependency hints (e.g., 'Call search() first if you only have a pattern').

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

29/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	29	<=2025-11-25	v2