Skip to main content
Glama
Ryan6-VRC

vrc-mcp-proxy

by Ryan6-VRC
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

vrc-mcp-proxy

Developed in the Atelier workspace.

An owned stdio MCP interception proxy that wraps the pinned MCP-for-Unity server (version pinned in src/vrc_mcp_proxy/config.py, via uvx) and corrects a handful of ways its transport lies to the model — a snippet silently executed twice by a connection-level retry, a timeout that doesn't mean the work didn't run, a target-lookup miss that only means the object was inactive. It also narrows the exposed tool surface to an allowlist and refuses execute_code snippets that can't compile in a method body.

Some lies are refused rather than corrected, because the truth never reaches this process. read_console truncates every console entry to its first line inside Unity, so a multi-line diagnostic's payload is already gone; the refusal routes to ReportConsole (com.ryan6vrc.agent-tools), which reads UnityEditor.LogEntries directly. manage_asset's move/rename discards AssetDatabase.MoveAsset's return value and substitutes a verdict that reports failure on moves that landed; the refusal routes to that API, whose empty-or-error string separates the cases nothing downstream can. A lie the proxy cannot see is a lie it must not appear to have handled.

It is a thin line-based JSON-RPC relay, not an MCP-SDK re-serve: it spawns the pinned server as a subprocess and passes every message through untouched except at named interception points. See docs/design.md for the full rationale and the per-failure verdicts, and docs/bump-runbook.md for moving the upstream pin.

Every interception point below runs inside a contained region, so one raising transform cannot take the relay down and leave the session mute. Containment is always on and has no VRC_MCP_PROXY_DISABLE name — it is not a behavior in the table's sense. docs/design.md §Three standing rules owns what a caller is told when a region fails, and which classes fail open rather than loud.

Behaviors

Behavior

Point

What it does

canary

tools/list resp

Validates upstream schemas against the committed baseline; refuses calls to a tool whose schema drifted.

allowlist

tools/list resp + tools/call req

Exposes only the allowlisted tools; refuses the rest, naming the one-line fix.

execute_code_using_refusal

tools/call req

Refuses snippets with top-level using directives (they can't live in a method body).

execute_code_idempotency_guard

tools/call req

Wraps snippets in a SessionState guard so an upstream transport re-send returns the cached result instead of running twice.

manage_asset_mutation_guard

tools/call req

Refuses manage_asset move/rename and redirects to AssetDatabase.MoveAsset via execute_code, which returns the empty-or-error string upstream discards. Upstream reports failure on moves that landed, and resolves a bare destination to Assets/<name> rather than beside the source. Every other action forwards, delete included — upstream reports that one honestly.

manage_gameobject_inactive_note

tools/call resp

On a manage_gameobject target-lookup miss, appends the note that the bridge's lookup is active-only for every action but modify + set_active:true — instanceId included — and names the two routes that do reach an inactive target. Diagnostic only: the tool has no include_inactive argument to inject.

timeout_notes

tools/call resp

Appends a note to timeout errors: the work may have run; verify on disk before retrying.

execute_code_compile_notes

tools/call resp

On an execute_code compile failure — from execute or replay, which is where a failed entry genuinely recompiles — appends one note per trap for three compile errors: a name two pre-imported namespaces both define (Object, Random), a type used where a value belongs (usually an attempted static-class alias), and a name that resolved to nothing — a typo, or a type outside the six pre-imported namespaces used unqualified (the agent/avatar tool doors and UnityEditor.SceneManagement are the common ones). The first two were lifted out of docs/unity.md; the third that doc never described. Matches both compiler dialects — Roslyn and CodeDom word and quote the first two incompatibly, and differ only in quoting on the third. Diagnostic only: it never rewrites the payload.

execute_code_prelude_offset_note

tools/call resp

On an execute compile failure, discloses that the reported line numbers count the proxy's own injected prelude (11 lines with both guards live), gives the subtraction, and names the bands that are not the caller's code at all — the preamble at or below the offset, and, when the idempotency wrapper is on, the trailer past their last line where a snippet with unbalanced braces reports. States the offset rather than correcting it: rewriting third-party compiler prose would emit a wrong line number as fact. Silent when nothing is injected, and on replay, where the stored snippet carries the original call's prelude and this process no longer knows its size.

execute_code_watchdog

tools/call req + timer

Per-call timer on an execute_code action:"execute" (default 120s, VRC_MCP_PROXY_EXECUTE_TIMEOUT_S). On expiry synthesizes a labeled timeout routing to compiler:"codedom" (→ editor restart if C#7+/mutating) and drops the late real response. Bounds the Roslyn background-compile hang; does not replace timeout_notes (the ~36s main-thread-block bounce).

instance_guard

tools/call req

Refuses an unpinned call while 2+ Unity editors are live (probe-free heartbeat count), naming them and set_active_instance. Exempts set_active_instance itself.

execute_code_venue_guard

tools/call req + resp

Prepends an exact Application.dataPath check against the pinned Editor's own heartbeat path, ahead of the idempotency guard's state write: a snippet that lands in a different Editor returns [proxy-venue-misroute] having run nothing there, and the response half rewrites that (success-shaped) payload into an error. Never guesses a venue — but a pin that is set and resolves to none or several is refused rather than forwarded unguarded (an unpinned call is instance_guard's business, and an empty heartbeat directory forwards, since "wrong pin" and "can't see any editor" are indistinguishable there). The session pin is stored canonically as Name@hash, so a bare-port pin can't strand later resolves on the freshness-filtered path. Bounds upstream's instance-agnostic port-scan fallback on retry; execute_code is the only tool able to carry the probe.

proxy_project_root

tools/call resp (set_active_instance)

On a successful pin, surfaces the resolved project root as proxy_project_root in the result (or "unresolved") — a wrong pin is then legible from the tool result itself, not just from a later instance_guard refusal. Independently disableable from instance_guard. A pin is "successful" only if the payload says so: upstream reports a missed pin as success:false with no isError, so that shape neither commits the session pin nor earns this key.

instance_not_found_note

tools/call resp

On an upstream instance-not-found error, when this machine's heartbeat files still name that instance, appends what the proxy can measure — the heartbeat's age and reason — and the cure that follows from it. Upstream drops an instance whose port fails a 0.3s framed ping, so a fresh ready heartbeat beside this error means the probe missed and a bare re-pin fixes it; a reloading heartbeat past upstream's 60s grace means wait, not re-pin; a stale one means the proxy cannot tell, and says so. Silent when no heartbeat matches — upstream may simply be right.

execute_code_safety_off

tools/call req

Sends safety_checks:false on an action:"execute" snippet the caller left unset, retiring the bridge's blocked-pattern list. That list is a path-blind substring match: it fires on cleanup under the disposable pile, misses the operations that actually destroy work here, and advertises its own bypass in the refusal. An explicit safety_checks (either value) is left alone.

manage_scene_arg_guard

tools/call req

Refuses a manage_scene call that scopes on an argument its action doesn't read — get_hierarchy with target (it reads parent) and the other curated confusable pairs — naming the argument that works. Upstream accepts and silently drops these: get_hierarchy returns the full root list with "scope":"roots", which reads as if the target held those roots.

manage_scene_discard_guard

tools/call req

Refuses a manage_scene load or create that has not declared additive. Both open Single, which closes every loaded scene, while upstream's unsaved-work gate reads only the active one — load checks the active scene alone, create checks nothing at all — so an additively-loaded dirty scene is discarded with no error and no prompt. The refusal hands back get_loaded_scenes, which reports per-scene isDirty: exactly the state the two handlers fail to consult, so additive=false means "I looked" rather than "I read the error message". additive=true is refused wherever upstream would silently drop it — on create, which has no additive mode, and on a buildIndex load, which never reaches the additive branch — and is consumed rather than forwarded on create. Covers the manage_scene door only: a raw OpenScene/NewScene over execute_code is unguarded, and the refusal says so.

manage_asset_search_pattern_note

tools/call resp

On a manage_asset search whose search_pattern carries one of a curated set of asset extensions, appends the note that AssetDatabase.FindAssets matches an asset's name with the extension excluded — so a .mat in the pattern never selects by type, and where names do embed that literal text it returns confidently wrong hits (measured: *.fbx over Assets returned 13 assets, every one a .json log). Names the cure, filter_type. Fires on hits and on zero alike, because the non-zero arm is the dangerous one. Silent on a dotted t:/l: filter term (upstream's own field description recommends putting those here) and on a reverse-DNS package id, whose last segment collides with real extensions — com.unity ends in .unity. A missed extension costs the note and nothing else, which is why the set is curated rather than "any dot". Diagnostic only.

manage_asset_search_scope_note

tools/call resp

On a manage_asset search whose folder scope upstream dropped, appends whichever of three things establishes it: the sanitizer provably cannot resolve the path (a .. traversal, a drive-qualified absolute path — decidable from the request alone, so this arm works with no venue), or hits came back outside the requested folder, or an empty result sits over a folder absent from the pinned venue. A scope merely naming a root outside Assets/ (Packages/…) only sharpens the wording once one of the latter two corroborates it — Assets/Packages/… is a layout real venues have, and a confident note on a correctly-scoped call is the expensive failure here. Upstream sets folderScope = null for any path that isn't a valid folder and searches the whole project, warning to the Unity console only — the surface this proxy denies. Diagnostic only.

manage_camera_screenshot_output

tools/call req

Defaults a screenshot/screenshot_multiview with no output_folder to Assets/Agent/Scratch/Screenshots. Upstream's fallback is the venue's Assets/Screenshots, so unaugmented shots litter the Assets root with PNGs and .meta files. An explicit output_folder always wins.

Related MCP server: revula

Wiring it into .mcp.json

Keep the server key UnityMCP so every mcp__UnityMCP__* name and settings matcher survives unchanged:

{
  "mcpServers": {
    "UnityMCP": {
      "command": "uv",
      "args": ["run", "--project", "<path-to-this-repo>", "vrc-mcp-proxy"]
    }
  }
}

The proxy spawns the pinned upstream server itself; you do not point .mcp.json at uvx mcpforunityserver anymore.

Disabling a behavior

Each behavior is independently disableable at launch via one env var (comma- or space-separated names from the table above):

"env": { "VRC_MCP_PROXY_DISABLE": "manage_asset_mutation_guard,canary" }

Development

uv run pytest

Tests need no Unity: transforms are unit-tested as pure functions, and one end-to-end test relays the proxy against a scripted fake child process. The pin lives in exactly one place — src/vrc_mcp_proxy/config.py.

Available Tools

14 tools
debug_request_contextDebug Request ContextA
Read-only

Return the current FastMCP request context details (client_id, session_id, and meta dump).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

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. Description supplements by listing returned fields (client_id, session_id, meta dump). No behavioral surprises.

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?

Single sentence, zero fluff. Front-loaded with verb and key outputs.

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 zero parameters and an output schema present, the description lists all important return fields. No gaps.

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?

No parameters—schema coverage is 100% (empty object). Baseline 4 applies as description doesn't need to add param info.

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?

Clearly states it returns FastMCP request context details including specific fields (client_id, session_id, meta dump). Distinct from sibling tools like read_console or execute_code.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives, though the purpose is straightforward. Could mention it's for debugging or diagnosing request issues.

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

execute_codeExecute CodeA
Destructive

Execute arbitrary C# code inside the Unity Editor. The code runs as a method body with access to UnityEngine and UnityEditor namespaces. Use 'return' to send data back. Compiled in-memory — no script files created. Actions: execute (run code), get_history (list past executions), replay (re-run a history entry), clear_history. NOTE: safety_checks blocks known dangerous patterns but is not a full sandbox. Compiler options: 'auto' (Roslyn if available, else CodeDom), 'roslyn' (C# 12+, requires Microsoft.CodeAnalysis), 'codedom' (C# 6 only).

ParametersJSON Schema
NameRequiredDescriptionDefault
codeNo
indexNo
limitNoNumber of history entries to return (for 'get_history' action, 1-50). Default: 10.
actionYesAction to perform.
compilerNoCompiler backend for 'execute' action. 'auto' uses Roslyn if Microsoft.CodeAnalysis is installed, else falls back to CodeDom. 'roslyn' forces Roslyn (C# 12+). 'codedom' forces legacy CSharpCodeProvider (C# 6). Default: auto.auto
safety_checksNoEnable basic blocked-pattern checks (File.Delete, Process.Start, infinite loops, etc). Not a full sandbox — advanced bypass is possible. Default: true.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

The description adds behavioral context beyond the destructiveHint annotation: code runs as a method body, no script files created, safety_checks is not a full sandbox. This helps the agent understand execution constraints and risks.

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?

The description is concise and well-structured: main purpose first, then actions list, then safety note, then compiler options. Every sentence adds value with no redundancy.

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 complexity (6 parameters, multiple actions, compiler choices) and the presence of an output schema, the description covers all key aspects: purpose, actions, compiler options, and safety. Minor gaps in parameter details (code format) are acceptable given the output schema.

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 description coverage is 67% (code and index lack descriptions). The description adds clarity for compiler (roslyn/codedom) and safety_checks, but does not explain the 'code' parameter beyond 'arbitrary C# code' or the 'index' parameter for replay. The description partially compensates for schema gaps.

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 tool executes arbitrary C# code inside the Unity Editor, specifying namespaces, return usage, and in-memory compilation. It distinguishes from sibling tools like execute_menu_item by focusing on arbitrary code execution.

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?

The description lists four actions (execute, get_history, replay, clear_history) and implicitly guides when to use the tool (for running code). However, it does not explicitly state when not to use it or compare to alternatives like execute_menu_item.

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

execute_menu_itemExecute Menu ItemB
Destructive

Execute a Unity menu item by path.

ParametersJSON Schema
NameRequiredDescriptionDefault
menu_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
hintNo
errorNo
messageNo
successYes

TDQS

B3.2/5.0
Behavior3/5

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

The annotation 'destructiveHint: true' already indicates destructive behavior. The description adds no further context about what destruction entails (e.g., asset modification, settings changes) or potential side effects, but it does not contradict the annotation.

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 a single concise sentence, front-loading the key action and resource. It is efficient, though it could include more detail without becoming verbose.

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

Completeness2/5

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

Given the existence of an output schema and annotations, the description still feels incomplete. It does not clarify return values, error scenarios, or the scope of executable menu items, which is important for a potentially destructive action.

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

Parameters2/5

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

With 0% schema description coverage, the description must compensate. 'By path' adds some meaning but lacks specifics on format, examples, or valid values for 'menu_path', leaving the agent uncertain about what to provide.

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 'execute' and the resource 'Unity menu item', with the qualifier 'by path', making it specific and distinct from sibling tools like 'manage_asset' or 'execute_code'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as when to prefer 'execute_code' or 'manage_editor'. There are no prerequisites or context about appropriate scenarios.

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

find_gameobjectsA

Search for GameObjects in the scene by name, tag, layer, component type, or path. Returns instance IDs only (paginated). Then use mcpforunity://scene/gameobject/{id} resource for full data, or mcpforunity://scene/gameobject/{id}/components for component details. For CRUD operations (create/modify/delete), use manage_gameobject instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
cursorNoPagination cursor (offset for next page)
page_sizeNoNumber of results per page (default: 50, max: 500)
search_termYesThe value to search for (name, tag, layer name, component type, or path)
search_methodNoHow to search for GameObjectsby_name
include_inactiveNoInclude inactive GameObjects in search

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description fully bears the burden of behavioral disclosure. It discloses that the tool returns only instance IDs, is paginated, and suggests subsequent resource calls. It could explicitly state that it is read-only, but the guidance to use manage_gameobject for CRUD implies it. No contradictions.

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?

The description is concise (three sentences) with no redundant information. It is front-loaded with the core purpose, followed by return type and guidance, then the alternative tool. Every sentence adds 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?

Given the tool's complexity (5 parameters, pagination, multiple search methods) and the presence of an output schema, the description covers what the agent needs: what it does, what it returns, how to paginate, and when to choose an alternative. No gaps.

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 that the tool returns only instance IDs and page_size controls results, and by guiding to resources for full data. This contextualizes the parameters beyond the schema.

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 'Search' and the resource 'GameObjects', listing specific search methods (name, tag, layer, component type, path). It also distinguishes from the sibling 'manage_gameobject' tool, which handles CRUD operations.

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?

Explicitly tells when to use this tool (searching for GameObjects) and when not to (for CRUD, use manage_gameobject instead). Also explains pagination and directs to resources for full data, providing clear context for usage.

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

manage_assetManage AssetA
Destructive

Performs asset operations (import, create, modify, delete, etc.) in Unity.

Tip (payload safety): for action="search", prefer paging (page_size, page_number) and keep generate_preview=false (previews can add large base64 blobs).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAsset path (e.g., 'Materials/MyMaterial.mat') or search scope (e.g., 'Assets').
actionYesPerform CRUD operations on assets.
page_sizeNo
asset_typeNo
propertiesNo
destinationNo
filter_typeNo
page_numberNo
search_patternNo
generate_previewNoGenerate a preview/thumbnail for the asset when supported. Warning: previews may include large base64 payloads; keep false unless needed.
filter_date_afterNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior4/5

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

Annotations already indicate destructiveHint=true. The description adds a crucial safety tip about generate_preview's large base64 blobs and search paging, which goes beyond annotations. However, it does not detail other behavioral aspects like error handling or idempotency for each action.

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?

The description is very concise: one sentence for purpose, one focused tip. No redundant words, and the critical information (payload safety) is front-loaded in the tip. Every sentence adds value.

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

Completeness3/5

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

Given the tool's complexity (11 parameters, many actions) and the availability of an output schema, the description covers the core purpose and a key usage tip but lacks details on action-specific prerequisites, parameter interactions, or default behaviors. It is minimally adequate.

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

Parameters2/5

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

Schema description coverage is low (27%), and the description only provides semantics for a few parameters indirectly in the tip (page_size, page_number, generate_preview). Other important parameters like asset_type, properties, destination, and filter_type are not explained, leaving the agent guessing.

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 'Performs asset operations (import, create, modify, delete, etc.) in Unity.' It specifies the resource (assets) and the specific verb actions, distinguishing it from sibling tools like manage_gameobject or manage_camera which handle different entity types.

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?

The description provides contextual guidance via a tip for search operations (paging and preview generation), which helps avoid large payloads. While it does not explicitly contrast with alternatives, the scope ('asset operations') is clear from the name and list of actions, making it usable.

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

manage_cameraManage CameraA
Destructive

Manage cameras (Unity Camera + Cinemachine). Works without Cinemachine using basic Camera; unlocks presets, pipelines, and blending when Cinemachine is installed. Use ping to check Cinemachine availability.

SETUP:

  • ping: Check if Cinemachine is available

  • ensure_brain: Ensure CinemachineBrain exists on main camera

  • get_brain_status: Get Brain state (active camera, blend, etc.)

CAMERA CREATION:

  • create_camera: Create camera with preset (third_person, freelook, follow, dolly, static, top_down, side_scroller). Falls back to basic Camera without Cinemachine.

CAMERA CONFIGURATION:

  • set_target: Set Follow and/or LookAt targets on a camera

  • set_priority: Set camera priority for Brain selection

  • set_lens: Configure lens (fieldOfView, nearClipPlane, farClipPlane, orthographicSize, dutch)

  • set_body: Configure Body component (bodyType to swap, plus component properties)

  • set_aim: Configure Aim component (aimType to swap, plus component properties)

  • set_noise: Configure Noise component (amplitudeGain, frequencyGain)

EXTENSIONS:

  • add_extension: Add extension (extensionType: CinemachineConfiner2D, CinemachineDeoccluder, CinemachineImpulseListener, CinemachineFollowZoom, CinemachineRecomposer, etc.)

  • remove_extension: Remove extension by type

CAMERA CONTROL:

  • set_blend: Configure default blend (style: Cut/EaseInOut/Linear/etc., duration)

  • force_camera: Override Brain to use specific camera

  • release_override: Release camera override

  • list_cameras: List all cameras with status

CAPTURE:

  • screenshot: Capture a screenshot. By default (no camera specified) uses ScreenCapture API, which captures all render layers including Screen Space - Overlay UI canvases. Specifying a camera uses direct camera rendering, which EXCLUDES Screen Space - Overlay canvases (use only when you need a specific viewpoint without UI). Supports include_image=true for inline base64 PNG, batch='surround' for 6-angle contact sheet, batch='orbit' for configurable grid, view_target/view_position for positioned capture, and capture_source='scene_view' to capture the active Unity Scene View viewport.

  • screenshot_multiview: Shorthand for screenshot with batch='surround' and include_image=true.

ParametersJSON Schema
NameRequiredDescriptionDefault
batchNoBatch capture mode: 'surround' (6 angles) or 'orbit' (configurable grid).
actionYesThe camera action to perform.
cameraNoCamera to capture from (name, path, or instance ID). Omit to use ScreenCapture API (captures all layers including Screen Space Overlay UI). Specify only when you need a particular camera viewpoint; note that Screen Space - Overlay canvases will NOT appear in camera-rendered captures.
targetNoTarget camera (name, path, or instance ID).
orbit_fovNoCamera FOV in degrees for batch='orbit' (default 60).
propertiesNoAction-specific parameters (dict or JSON string).
view_targetNoTarget to focus on. GameObject name/path/ID or [x,y,z]. For game_view: aims camera at target. For scene_view: frames the Scene View on the target.
orbit_anglesNoNumber of azimuth samples for batch='orbit' (default 8, max 36).
include_imageNoIf true, return screenshot as inline base64 PNG. Default false.
output_folderNoOptional folder for screenshot output. Project-relative (e.g. 'Assets/Screenshots' or 'Captures') or absolute path inside the project. Overrides the user's Editor preference. If omitted, falls back to the Editor preference, then to the built-in default (Assets/Screenshots).
search_methodNoHow to find target.
view_positionNoWorld position [x,y,z] to place camera for positioned capture.
view_rotationNoEuler rotation [x,y,z] for camera. Overrides view_target if both provided.
capture_sourceNoScreenshot source. 'game_view' (default) captures the game/camera path; 'scene_view' captures the active Unity Scene View viewport.
max_resolutionNoMax resolution (longest edge px) for inline image. Default 640.
orbit_distanceNoCamera distance from target for batch='orbit' (default auto).
orbit_elevationsNoElevation angles in degrees for batch='orbit' (default [0, 30, -15]).
screenshot_file_nameNoScreenshot file name (optional). Defaults to timestamp.
screenshot_super_sizeNoScreenshot supersize multiplier (integer >= 1).

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description details behaviors like fallback to basic Camera, how extensions work, and the critical difference in screenshot capture (ScreenCapture API includes UI, camera rendering excludes Screen Space Overlay). No contradictions with 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 lengthy but well-structured into sections (SETUP, CAMERA CREATION, etc.), making it easy to navigate. Each sub-action gets a brief explanation. Slightly verbose but efficient given the tool's breadth.

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?

Given the tool's complexity (19 parameters, many actions), the description covers all sub-actions thoroughly. The screenshot details are especially complete, covering capture sources, batch modes, and parameter interactions. No output schema, but the description adequately explains what each action does.

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 meaningful context for key parameters like 'camera' (explains UI exclusion) and 'batch' (describes surround/orbit modes), enhancing the 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 it manages cameras (Unity Camera + Cinemachine) and lists all sub-actions (setup, creation, configuration, extensions, control, capture). The purpose is specific and distinguishes from sibling tools, none of which deal with cameras.

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?

The description provides explicit guidance: setup steps (ping to check Cinemachine), when to use screenshot with camera parameter vs without (UI capture), and shorthand for screenshot_multiview. It also explains fallback behavior without Cinemachine.

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

manage_editorManage EditorA

Controls and queries the Unity editor's state and settings. Read-only actions: telemetry_status, telemetry_ping. Modifying actions: play, pause, stop, set_active_tool, add_tag, remove_tag, add_layer, remove_layer, deploy_package, restore_package, undo, redo. For prefab editing (open/save/close prefab stage), use manage_prefabs. deploy_package copies the configured MCPForUnity source folder into the project's installed package location (triggers recompile, no confirmation dialog). restore_package reverts to the pre-deployment backup. undo/redo perform Unity editor undo/redo and return the affected group name.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesGet and update the Unity Editor state. deploy_package copies the configured MCPForUnity source into the project's package location (triggers recompile). restore_package reverts the last deployment from backup. undo/redo perform editor undo/redo. For prefab editing (open/save/close prefab stage), use manage_prefabs.
tag_nameNo
tool_nameNo
layer_nameNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations beyond title, the description carries the burden. It discloses that deploy_package triggers recompile with no confirmation, restore_package reverts, and undo/redo return affected group name. However, it does not detail side effects for actions like play/pause or permissions needed, leaving gaps.

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 a single, relatively concise paragraph that front-loads the general purpose and lists actions. It is dense but not overly long, though it could benefit from structured bullets or grouping of actions.

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

Completeness2/5

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

Despite having an output schema (not shown), the description does not explain return values for most actions. It covers telemetry_status/ping as read-only but omits specifics, and for modifying actions, only undo/redo mention return values. This leaves significant gaps given the tool's complexity.

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

Parameters2/5

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

Schema description coverage is only 25% (only action described). The description repeats the action list but does not explain how tag_name, tool_name, and layer_name relate to specific actions. This fails to compensate for the low schema coverage, leaving agents unsure of which parameters to use.

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 it controls and queries the Unity editor state and settings, listing read-only and modifying actions. It distinguishes from the sibling manage_prefabs tool for prefab editing, providing a specific verb-resource combination.

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?

The description explicitly states to use manage_prefabs for prefab editing, providing an alternative. However, it does not offer guidance on when to use this tool versus other sibling tools like manage_gameobject or execute_menu_item, leaving some ambiguity.

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

manage_gameobjectManage GameObjectA
Destructive

Performs CRUD operations on GameObjects. Actions: create, modify, delete, duplicate, move_relative, look_at. NOT for searching — use the find_gameobjects tool to search by name/tag/layer/component/path. NOT for component management — use the manage_components tool (add/remove/set_property) or mcpforunity://scene/gameobject/{id}/components resource (read).

ParametersJSON Schema
NameRequiredDescriptionDefault
tagNo
nameNo
layerNo
scaleNo
actionNo
offsetNo
parentNo
targetNo
distanceNo
new_nameNo
positionNo
rotationNo
directionNo
is_staticNo
look_at_upNo
set_activeNo
prefab_pathNo
world_spaceNo
prefab_folderNo
search_methodNo
look_at_targetNo
primitive_typeNo
save_as_prefabNo
reference_objectNo
components_to_addNo
component_propertiesNo
components_to_removeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, and the description lists 'delete' as an action, which aligns. However, the description does not add further behavioral context such as which actions are irreversible, permission requirements, or side effects beyond what annotations already provide.

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 concise with two sentences, front-loading the main function and exclusions. However, the lack of parameter description means it is not fully informative, reducing efficiency.

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

Completeness2/5

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

Despite having an output schema, the tool has 27 parameters with no schema descriptions and the description does not explain parameter usage per action. For a tool with high complexity, the description is incomplete, missing essential guidance on how to invoke each action.

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

Parameters1/5

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

The schema has 27 parameters with 0% description coverage. The tool description names the actions but does not describe any parameter semantics, leaving the agent to guess which parameters apply to each action. This is a critical omission for a complex tool with many parameters.

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 tool performs CRUD operations on GameObjects and lists the specific actions (create, modify, delete, duplicate, move_relative, look_at). It explicitly distinguishes from sibling tools like find_gameobjects and manage_components, making the purpose unambiguous.

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?

The description provides explicit when-not-to-use guidance, directing to use find_gameobjects for searching and manage_components for component management. This clearly differentiates the tool's scope from alternatives, even though manage_components is not in the sibling list.

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

manage_packagesManage PackagesA
Destructive

Manage Unity packages: query, install, remove, embed, and configure registries.

QUERY (read-only):

  • list_packages: List all installed packages

  • search_packages: Search Unity registry by keyword

  • get_package_info: Get details about a specific installed package

  • ping: Check package manager availability

  • status: Poll async job status (job_id required for list/search; optional for add/remove/embed)

INSTALL/REMOVE:

  • add_package: Install a package (name, name@version, git URL, or file: path)

  • remove_package: Remove a package (checks dependents; use force=true to override)

REGISTRIES:

  • list_registries: List all scoped registries

  • add_registry: Add a scoped registry (e.g., OpenUPM)

  • remove_registry: Remove a scoped registry

UTILITY:

  • embed_package: Copy package to local Packages/ for editing

  • resolve_packages: Force re-resolution of all packages

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoRegistry URL for add_registry.
nameNoRegistry name for add_registry/remove_registry.
forceNoForce removal even if other packages depend on it.
queryNoSearch query for search_packages.
actionYesThe package action to perform.
job_idNoJob ID for polling status.
scopesNoRegistry scopes for add_registry.
packageNoPackage identifier (name, name@version, git URL, or file: path).

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

The description discloses behavioral traits beyond annotations, including the possibility of destructive actions (remove with force) and async job polling for status. Annotations already indicate destructiveHint=true, and the description adds context about dependent checking and embedding behavior. No contradictions.

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 sections and bullet points, front-loading the overall purpose. It is concise given the tool's complexity, though a few redundant phrases could be trimmed. Each sentence adds value.

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 complexity (8 parameters, many sub-actions), the description covers all major behaviors, including read-only vs. write operations and async polling. It omits details like error handling, but with an output schema present, return values are not required to be described.

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?

Input schema coverage is 100% with clear descriptions for all 8 parameters. The description adds minimal extra meaning beyond grouping parameters to actions (e.g., job_id for status). Since schema already covers meaning, the baseline of 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?

The description clearly states the tool's purpose: 'Manage Unity packages: query, install, remove, embed, and configure registries.' It uses a specific verb-resource scope and lists distinct sub-actions, distinguishing itself from sibling tools which focus on debugging, code execution, or scene management.

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?

The description provides explicit guidance on when to use each sub-action (e.g., 'QUERY (read-only)' vs 'INSTALL/REMOVE') and includes caveats like 'use force=true to override' for removal. However, it does not explicitly compare to sibling tools or state prerequisites, though the context makes usage clear.

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

manage_sceneManage SceneA
Destructive

Performs CRUD operations on Unity scenes. Read-only actions: get_hierarchy, get_active, get_build_settings, get_loaded_scenes, scene_view_frame. Modifying actions: create (with optional template), load (with optional additive flag), save, close_scene, set_active_scene, move_to_scene, validate (with optional auto_repair). For build settings management (add/remove/enable scenes), use manage_build(action='scenes'). For screenshots, use manage_camera (screenshot, screenshot_multiview actions).

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNo
pathNo
actionYesPerform CRUD operations on Unity scenes and control the Scene View camera.
cursorNo
parentNo
targetNo
additiveNo
templateNo
max_depthNo
max_nodesNo
page_sizeNo
scene_nameNo
scene_pathNo
auto_repairNo
build_indexNo
remove_sceneNo
include_transformNo
scene_view_targetNo
max_children_per_nodeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already include destructiveHint: true, indicating modification potential. The description adds context by categorizing actions as read-only or modifying and lists specific modifying actions (create, load, save, etc.). While it doesn't detail side effects or auth needs, it provides sufficient behavioral context beyond the annotation.

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?

The description is concise and well-structured: a single sentence for the main purpose, followed by a clear list of actions grouped by read-only/modifying, and then references to sibling tools. No unnecessary words.

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

Completeness3/5

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

Given the complexity (19 parameters, 12 actions, output schema present), the description covers action semantics and sibling differentiation well. However, it lacks details on parameter usage and expected results for specific actions, which would help complete the picture for an agent.

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

Parameters2/5

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

Schema description coverage is only 5% (only the action parameter has a meaningful description). The tool description mentions a few parameters in context (template, additive, auto_repair) but does not explain the majority of the 19 parameters, leaving the agent to infer their roles from action names alone.

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 'Performs CRUD operations on Unity scenes' and explicitly lists all supported actions, distinguishing between read-only and modifying operations. It also references sibling tools (manage_build, manage_camera) for specific use cases, making the purpose unambiguous.

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?

The description provides explicit guidance on when to use this tool versus alternatives (e.g., 'For build settings management... use manage_build', 'For screenshots, use manage_camera'). It also separates read-only from modifying actions, helping the agent choose appropriately.

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

read_consoleRead ConsoleA

Gets messages from or clears the Unity Editor console. Defaults to 10 most recent entries. Use page_size/cursor for paging. Note: For maximum client compatibility, pass count as a quoted string (e.g., '5'). The 'get' action is read-only; 'clear' modifies ephemeral UI state (not project data).

ParametersJSON Schema
NameRequiredDescriptionDefault
countNo
typesNo
actionNo
cursorNo
formatNo
page_sizeNo
filter_textNo
include_stacktraceNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior5/5

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

Transparently discloses the read-only nature of 'get' and the ephemeral UI modification of 'clear', plus a compatibility note about passing count as string. No annotations to contradict.

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?

Concise two-sentence description with front-loaded purpose, defaults, and paging. Every sentence adds value without waste.

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

Completeness3/5

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

With 8 parameters and no schema descriptions, the description partially covers behavior but lacks details for many parameters. Output schema exists, so return value explanation is not required, but parameter coverage is incomplete.

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

Parameters2/5

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

Schema coverage is 0%, so the description must compensate. It only explains a few parameters (count, page_size, cursor, action), leaving types, filter_text, format, include_stacktrace, and other parameter semantics undescribed.

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 explicitly states the tool's resource (Unity Editor console) and both main actions (get/clear), making it clear and distinct from sibling 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?

Provides clear guidance on default behavior (10 most recent entries), pagination (page_size/cursor), and when to use 'get' vs 'clear'. Does not contrast with siblings but is sufficient for standalone usage.

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

refresh_unityRefresh UnityA
Destructive

Request a Unity asset database refresh and optionally a script compilation. Can optionally wait for readiness.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoRefresh modeif_dirty
scopeNoRefresh scopeall
compileNoWhether to request compilationnone
wait_for_readyNoIf true, wait until editor_state.advice.ready_for_tools is true

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

Annotations include destructiveHint: true, indicating destructiveness. The description adds the optional waiting behavior but does not elaborate on the destructive nature (e.g., what gets destroyed, unsaved changes). This is minimal added 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?

The description is two sentences, concise, and front-loaded with the primary action. Every sentence adds value without redundancy.

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 4 optional parameters and available output schema, the description covers the core functionality (refresh, compile, wait). It is complete enough, though it could briefly mention the destructive impact.

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 description coverage is 100%, so the schema already documents all four parameters. The tool description does not add any parameter-specific meaning beyond what the schema provides. Baseline 3.

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 tool requests a Unity asset database refresh and optionally a script compilation, with an option to wait for readiness. The verb 'request' and resource 'Unity asset database refresh' are specific and distinguish it from sibling tools like manage_asset or execute_code.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or contrast with related tools (e.g., manage_asset for individual assets).

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

set_active_instanceSet Active InstanceA

Set the active Unity instance for this client/session. Accepts Name@hash, hash prefix, or port number (stdio only).

ParametersJSON Schema
NameRequiredDescriptionDefault
instanceYesTarget instance (Name@hash, hash prefix, or port number in stdio mode)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

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

With no annotations beyond title, the description carries the burden. It discloses input constraints (port number for stdio only) but fails to mention potential side effects, required permissions, or what happens if the target instance is not found. The presence of an output schema mitigates some need for return value explanation.

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?

Two sentences only: first states purpose, second details input formats. No unnecessary words, well-structured for quick comprehension.

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 low complexity (single parameter, no enums, output schema present), the description is adequate. It covers purpose and input formats, though it lacks mention of error behavior or return value specifics (possibly covered by output schema).

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 parameter description in the schema matches the tool description. The description adds no new semantic meaning beyond what the schema provides, so baseline 3 is appropriate.

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 action ('Set the active Unity instance') and the scope ('for this client/session'). It distinguishes itself from sibling tools which manage different aspects of Unity (e.g., managing scenes, assets, editor).

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?

The description explains the accepted input formats (Name@hash, hash prefix, or port number for stdio) which guides usage. However, it does not explicitly state when to use or not use this tool, nor does it mention alternatives, but with no direct sibling conflict this is less critical.

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

unity_reflectUnity ReflectA
Read-only

Inspect Unity's live C# API via reflection. Use this to verify that classes, methods, and properties exist before writing C# code — training data may be wrong or outdated.

Actions:

  • get_type: Member summary (names only) for a class. Requires class_name.

  • get_member: Full signature detail for one member. Requires class_name + member_name.

  • search: Type name search across loaded assemblies. Requires query. Optional scope.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoSearch query for type name search.
scopeNoAssembly scope for search: unity, packages, project, all.
actionYesThe reflection action to perform.
class_nameNoFully qualified or simple C# class name.
member_nameNoMethod, property, or field name to inspect.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds valuable behavioral context: it uses reflection, is live, and actions are for inspection only (e.g., 'Member summary (names only)'). No contradictions.

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?

The description is very concise: three short paragraphs. First paragraph states purpose and use case. Second paragraph lists three actions with their requirements. No redundant information. Every sentence adds 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?

Given the tool's complexity (5 parameters, 1 required, output schema exists), the description is complete. It covers the three possible actions and their parameter requirements. The output schema exists, so describing return format is unnecessary. The 100% schema coverage and sibling context further reduce the need for additional detail.

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

Parameters5/5

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

Schema coverage is 100%, with descriptions for each parameter. However, the description goes beyond schema by explaining the purpose of each action and which parameters are required for that action (e.g., 'Requires class_name' for get_type). This adds significant semantic meaning beyond the schema's generic 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 tool's purpose: 'Inspect Unity's live C# API via reflection.' It also lists specific actions (get_type, get_member, search) and their inputs, distinguishing it from sibling tools like execute_code or manage_gameobject which perform different operations. The verb 'verify existence before writing C# code' is specific and actionable.

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?

The description explains when to use: 'before writing C# code to verify that classes, methods, and properties exist' and that 'training data may be wrong or outdated.' It implies when not to use (e.g., not for executing code or modifying objects) but does not explicitly list alternatives. The context is clear and helpful.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 14 tool updatesv0.1.0
    • First observeddebug_request_context
    • First observedexecute_code
    • First observedexecute_menu_item
    • First observedfind_gameobjects
    • First observedmanage_asset
    • First observedmanage_camera
    • First observedmanage_editor
    • First observedmanage_gameobject
    • First observedmanage_packages
    • First observedmanage_scene
    • First observedread_console
    • First observedrefresh_unity
    • First observedset_active_instance
    • First observedunity_reflect
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct operation (debugging, code execution, game object CRUD, scene management, etc.) with no overlap. Descriptions clearly differentiate similar-sounding tools like manage_gameobject vs find_gameobjects.

Naming Consistency4/5

Most tools use a verb_noun pattern (e.g., execute_code, find_gameobjects, manage_scene). The only exception is unity_reflect (noun_verb), but it's a single deviation from an otherwise consistent convention.

Tool Count5/5

14 tools cover a broad range of Unity editor operations without being overwhelming. The count is well-suited for the server's purpose of comprehensive editor control via MCP.

Completeness4/5

The tool surface covers core workflows like CRUD on game objects, scenes, assets, packages, camera control, and editor state. Minor gaps exist (e.g., no dedicated animation or UI tools), but the set is functional and extendable.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ryan6-VRC/vrc-mcp-proxy'

If you have feedback or need assistance with the MCP directory API, please join our Discord server