vrc-mcp-proxy

by Ryan6-VRC

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vrc-mcp-proxy MCP server](https://glama.ai/mcp/servers/Ryan6-VRC/vrc-mcp-proxy/badges/card.svg)](https://glama.ai/mcp/servers/Ryan6-VRC/vrc-mcp-proxy)

Score Badge

Copy to your README.md:

[![vrc-mcp-proxy MCP server](https://glama.ai/mcp/servers/Ryan6-VRC/vrc-mcp-proxy/badges/score.svg)](https://glama.ai/mcp/servers/Ryan6-VRC/vrc-mcp-proxy)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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