The unity-super-mcp server provides 15 tools for AI-driven Unity project management, covering UGS LiveOps, build-size analysis, and store compliance.
🎮 UGS LiveOps (8 tools)
Get project info – Retrieve UGS project status, environment details, and a quick Economy check
List Economy catalog – View all currencies, inventory items, and shops (optionally including archived entries)
Create currencies – Add new currencies with optional initial value and max cap
Create inventory items – Add INVENTORY or VIRTUAL_GOOD items with custom properties and stack limits
Create shops – Set up shops with items and their associated currency costs
Read Cloud Save data – Fetch a specific player's Cloud Save key/value data by player ID
List Cloud Code modules – View all deployed Cloud Code modules in the project
Deploy Cloud Code modules – Upload and deploy JavaScript Cloud Code modules via base64 file content
📦 Build & Compliance (7 tools)
Full health check – One-call parallel scan covering size, bloat, compliance, and UGS status (recommended entry point)
Build size report – Top largest assets, size breakdown by file extension, and total project size
Bloat analysis – Detect duplicate files, files over 10MB, Resources/ folder abuse, and unoptimized textures
Fix texture imports – Generate a C# Editor script for texture import fixes, or directly patch .meta files with apply=true
Find orphaned assets – Heuristic GUID-based scan for assets not referenced by any scene or prefab
Compliance check – Verify iOS/Android compliance including target SDK version, permissions, and StreamingAssets bloat
Provides tools to interact with Unity Gaming Services (Economy, Cloud Save, Cloud Code) and perform build analysis and store-compliance checks for Unity projects.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@unity-super-mcp run a health check on my Unity project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
One MCP server for Unity Gaming Services LiveOps, build-size analysis, and store compliance.
An MCP server that gives an AI agent 15 tools over a Unity project: Unity Gaming Services LiveOps (Economy, Cloud Save, Cloud Code), build-size and bloat analysis, and store-compliance checks — one install instead of four.
Why this exists (read me first). This was built in a single sitting to win a bet — whether an agent could usefully drive UGS end-to-end. This is the receipt. I build MCP servers and agent infrastructure; I am not a game developer and this is not a pivot into games. It's here as a demonstration of MCP tool design, not a maintained product.
Built entirely through a text-only chat with a mobile AI assistant (no file uploads, no IDE), then verified: the server type-checks clean and boots. Treat it as a reference implementation.
npx -y unity-super-mcp{
"mcpServers": {
"unity-super": {
"command": "npx",
"args": ["-y", "unity-super-mcp"],
"env": {
"UNITY_PROJECT_PATH": "/path/to/MyGame",
"UNITY_PROJECT_ID": "your-project-id",
"UNITY_SERVICE_KEY_ID": "your-key-id",
"UNITY_SERVICE_SECRET": "your-secret",
"UNITY_ENV_ID": "production"
}
}
}
}No UGS credentials? Set only UNITY_PROJECT_PATH and you still get the 7 build/compliance tools. The UGS tools report "not configured" instead of failing.
Related MCP server: Unity x Claude MCP Server
Tool | What it does |
| Project + environment readout |
| List currencies, items, purchases |
| Create a currency |
| Create an inventory item |
| Create a shop with items and costs |
| Read a player's Cloud Save data |
| List deployed Cloud Code modules |
| Deploy a Cloud Code module |
Tool | What it does |
| Run this first — fans the core checks out in parallel, returns a summary + next actions |
| Top largest assets, size by extension, total project size |
| Duplicates, oversized files, |
| Generates a C# editor script for texture-import fixes (or edits |
| Unreferenced-asset heuristic |
| Android target SDK, iOS, StreamingAssets bloat |
super_health_check is the intended entry point: one call, whole-project readout.
assets_find_orphans is heuristic — verify with AssetDatabase.GetDependencies before deleting anything.
Requires Node 18+.
MIT. Do what you like with it.
Find potential orphaned assets not referenced by scenes/prefabs (heuristic guid search)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'heuristic guid search' and 'potential orphaned assets', setting expectations for inexact results, but does not disclose read-only nature, permissions, or other behavioral traits. No annotations are provided to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main purpose. Every word is informative; no redundancy or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is mostly adequate. It specifies the scope (scenes/prefabs) and search method, but lacks details on return format or what constitutes an orphan beyond those references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description doesn't need to explain parameter semantics. It adds value by hinting at the search algorithm (heuristic guid search).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds orphaned assets not referenced by scenes/prefabs using a heuristic guid search. It uses a specific verb and resource, and is distinct from sibling tools which focus on builds, cloudcode, and economy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identifying unused assets but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. No comparison to other tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find bloat: duplicates, huge files >10MB, Resources/ abuse, unoptimized textures
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Absent annotations, the description only lists what it finds but does not disclose whether the tool is read-only, requires specific permissions, or any side effects. For an analysis tool, this is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence listing bloat types, no fluff. However, it could benefit from a slightly more structured format (e.g., bullet list).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description should explain what users get back (e.g., a report). It lacks details about the output format or how results are presented, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds no parameter info, which is acceptable since there are none to document. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' and lists concrete types of bloat (duplicates, huge files >10MB, Resources/ abuse, unoptimized textures), clearly distinguishing it from sibling tools like assets_find_orphans or build_check_compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, but the description implies it should be used for identifying bloat in a build. No exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check iOS/Android compliance (Target SDK, permissions, StreamingAssets bloat)
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions what aspects are checked. It does not disclose whether the tool modifies state, requires network access, or is read-only. The implied 'check' suggests non-destructive behavior, but it's not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure and essential details. It fails to provide a useful overview or key information like expected output or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description is insufficient. It does not explain what the compliance check produces (pass/fail, report, etc.), how to interpret results, or what actions to take if non-compliant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description adds no meaning beyond the enum values already in the schema. The 'platform' parameter's role is clear from the schema, but the description does not elaborate on how to use it or its impact on the check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks iOS/Android compliance for Target SDK, permissions, and StreamingAssets bloat. The verb 'Check' and resource 'compliance' are specific, and it broadly distinguishes from siblings like 'build_analyze_bloat' which might focus on general bloat analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Siblings such as 'super_health_check' or 'build_analyze_bloat' could overlap, but the description does not clarify specific contexts, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate fix for texture imports. Returns C# Editor script. If apply=true, edits .meta directly
| Name | Required | Description | Default |
|---|---|---|---|
| rule | No | UI max 1024 crunch, others max 2048 | |
| apply | No | ||
| targetFolder | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses conditional behavior (script vs .meta edit) and the effect of the 'apply' parameter. However, it lacks details on potential side effects, permissions required, or reversibility of .meta edits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the core action and dual behavior. It is front-loaded and efficient, but could be structured slightly better (e.g., separate conditional outcomes) without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, annotations, or required parameters, the description covers main functionality but omits details like return format of the script, scope when targetFolder is omitted, and any preconditions. It is adequate but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by explaining the 'rule' parameter with an example default and the 'apply' parameter's effect. However, 'targetFolder' remains unexplained, and parameter semantics are only partially covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('generate fix'), target resource ('texture imports'), and key behaviors ('returns C# Editor script' and 'edits .meta directly'). It distinguishes from sibling tools which focus on analysis, compliance, or other tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention prerequisites or when not to use it. It assumes the user already knows they need to fix texture imports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan project and return top largest assets, size by extension, total size
| Name | Required | Description | Default |
|---|---|---|---|
| topN | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but omits whether the operation is read-only, any side effects, performance impact, or required context. It does not disclose if 'scan' modifies data or just queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the tool's output deliverables without redundancy. However, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and incomplete parameter documentation, the description fails to provide sufficient context about the report format, asset types included, or how 'top largest' is defined. The sibling tools suggest build analysis but no explicit link.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% and the description adds no explanation for the only parameter 'topN'. The default value is present but meaning, constraints (e.g., min/max), and behavior are undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions scanning a project and returning top largest assets, size by extension, and total size, but uses the vague verb 'scan'. It somewhat distinguishes from siblings like 'build_analyze_bloat' but could be more specific about the exact resource being reported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'build_analyze_bloat'. No exclusions or prerequisites are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy Cloud Code module from JS files (base64 upload + deploy)
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| moduleName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full weight. It only states the operation, but does not disclose key behaviors such as idempotency, overwrite behavior, error handling, or required permissions. The phrase 'base64 upload + deploy' hints at encoding but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is very concise, but it sacrifices essential information. It is front-loaded with the purpose, but critical details about parameters and behavior are missing, making it inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the input schema (2 required params) and lack of output schema or annotations, the description should at least clarify parameter semantics and constraints. It fails to do so, leaving gaps that an agent would need to fill via trial and error or external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain the parameters. The description mentions 'base64 upload' but the schema does not enforce base64 encoding, creating a potential contradiction. 'files' and 'moduleName' are not elaborated, so the agent must guess their meaning and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deploy Cloud Code module') and the source ('from JS files (base64 upload + deploy)'). It uses a specific verb and resource, and is distinguishable from sibling tools like 'cloudcode_list_modules' which lists rather than deploys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, prerequisites, or when not to use it. Sibling tools like 'cloudcode_list_modules' suggest possible pre-conditions but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Cloud Code modules
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states 'list' without explaining read-only nature, pagination, authentication requirements, or return format. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single concise phrase that earns its place. Could be slightly more descriptive (e.g., 'all modules'), but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is adequate for a simple list operation but lacks any return value or behavior details. Not completely insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% by default. Baseline score of 4 applies as there is no need for parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list' and resource 'Cloud Code modules'. Distinguishes from sibling 'cloudcode_deploy_module' which implies deployment, not listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives provided. Usage is implied by the tool name and description, but lacks guidance on when to prefer this over other list tools like economy_list_catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Cloud Save data for a playerId
| Name | Required | Description | Default |
|---|---|---|---|
| playerId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'Get' implying read-only, but does not mention authentication, rate limits, error conditions, or any side effects. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is efficient, though it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema or annotations, the description is insufficient. It does not explain return values, success/error scenarios, or any behavioral context needed for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds little beyond the schema property name 'playerId'. It says 'for a playerId' but does not clarify format, constraints, or source. Schema description coverage is 0%, so the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a specific verb 'Get' and resource 'Cloud Save data' scoped to a playerId. It clearly distinguishes from sibling tools which are unrelated to cloud save, but lacks specifics on what data is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives, prerequisites, or context for the playerId parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create currency in Economy 2.0
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| max | No | ||
| name | Yes | ||
| initial | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Create currency' without mentioning mutability, permissions, side effects, limits, or idempotency. Essential behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the key action. However, it sacrifices necessary detail; every sentence should earn its place, and while this one does convey the core purpose, it omits critical information, making it moderately effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, no annotations, and multiple siblings, the description is severely inadequate. It explains nothing about return values, parameter roles, or behavioral details, leaving the agent with insufficient guidance to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage. The tool description adds no information about parameter meanings, types, or constraints, leaving the agent to infer everything from the schema alone. This fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the resource (currency), and it specifies the context (Economy 2.0). This distinguishes it from sibling tools like economy_create_item and economy_create_shop, which create different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a currency, but it provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The context is inferred from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create inventory/virtual item with custom properties
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | Yes | ||
| type | No | INVENTORY | |
| maxStack | No | ||
| properties | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Create' without disclosing behavioral traits like persistence, side effects, limits, or atomicity. Since no annotations are provided, the description carries the full burden, but it is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, but it is too brief. It lacks structure and important details, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, a nested object, and no output schema, the description is incomplete. It does not cover return values, default behaviors, or parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description should add meaning. It only mentions 'custom properties', referencing the properties parameter, but fails to explain id, name, type, or maxStack beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'inventory/virtual item with custom properties'. It distinguishes from sibling tools like economy_create_currency and economy_create_shop, which create different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 economy_create_currency. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create shop with items and costs
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| items | Yes | ||
| shopId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'create shop' without mentioning overwrite behavior, prerequisites, or consequences of missing references.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 5 words and front-loaded. However, it could include more structure without losing brevity, such as listing required parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, error conditions, or behavior for existing shop IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 mentions 'items and costs', adding some context beyond the schema, but lacks specifics on the nested structure of items and costs (e.g., required fields within arrays).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'create' and the resource 'shop' with sub-elements 'items and costs'. It distinguishes from sibling tools like 'economy_create_currency' and 'economy_create_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as updating a shop or creating other economy entities. The usage is only implicitly understood from the action verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List full Economy 2.0 catalog: currencies, items, shops
| Name | Required | Description | Default |
|---|---|---|---|
| includeArchived | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits such as default exclusion of archived items (despite the includeArchived parameter), pagination, or any side effects. The term 'full catalog' may be misleading if pagination exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the primary action. However, it omits parameter details which could be included without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and one parameter, the description is insufficient. It does not explain parameter behavior, return format, or prerequisites (e.g., permissions). Compared to sibling tools, it lacks completeness for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (includeArchived) with 0% coverage. The description does not mention this parameter or its effect, leaving the agent to infer its purpose from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'full Economy 2.0 catalog', specifying the components (currencies, items, shops). It distinguishes from sibling tools like economy_create_* which are for creating, not listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving the catalog but does not explicitly state when to use it vs alternatives like economy_create_* or other listing tools. No exclusionary or context guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run full project health check: size, bloat, compliance, UGS status - one tool to rule them all
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It does not indicate whether the operation is read-only, destructive, requires authentication, or has rate limits. The lack of detail leaves the agent without necessary context for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and lists key components. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's comprehensive nature (health check) and lack of output schema or annotations, the description is incomplete. It does not explain the format or interpretation of results, whether the check is synchronous, or any side effects. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema is empty. The description does not need to explain parameters since there are none. Baseline for zero parameters is 4, and the description appropriately focuses on the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and the resource ('full project health check'), listing what it covers (size, bloat, compliance, UGS status). However, it does not explicitly differentiate from sibling tools like build_analyze_bloat or build_check_compliance, though the phrase 'one tool to rule them all' implies an aggregated scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a comprehensive health overview but provides no explicit guidance on when to use this tool versus the more specialized sibling tools. No 'when-not' or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Unity project UGS status, environment, and quick economy check. Run this first if UGS env is set.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states 'Get' implying read-only, but does not explicitly confirm no side effects, whether it mutates state, or any other constraints like rate limits or required permissions. The 'quick economy check' suggests a query but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences: first states the purpose, second gives usage guidance. No wasted words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's basic purpose and usage timing, but lacks detail on return values or structure (no output schema provided). For a simple status check, it is minimally adequate but could be improved by describing what exact information is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. Per guidelines, baseline score is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'Unity project UGS status, environment, and quick economy check'. It distinguishes itself from siblings by implying it's a preliminary check, though it doesn't explicitly compare to similar tools like 'super_health_check'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Run this first if UGS env is set' provides explicit when-to-use guidance, positioning it as an initial step. It does not list when-not-to-use or alternatives, but the context of sibling tools and the phrase 'first' adequately conveys priority.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0assets_find_orphansbuild_analyze_bloatbuild_check_compliancebuild_fix_importsbuild_get_last_reportcloudcode_deploy_modulecloudcode_list_modulescloudsave_get_player_dataeconomy_create_currencyeconomy_create_itemeconomy_create_shopeconomy_list_catalogsuper_health_checkugs_get_project_infoScored across 14 tools
Tools have distinct purposes overall, but slight overlap exists between build_analyze_bloat and build_get_last_report, as both deal with file sizes. However, descriptions clarify the differences.
All tools follow a consistent domain prefix followed by verb_noun pattern using snake_case. No mixing of conventions, making it easy to understand the tool's scope from its name.
14 tools cover multiple Unity development domains (assets, builds, cloud code, cloud save, economy) without being overwhelming. Each tool serves a clear purpose and the count is appropriate for the server's scope.
The tool set provides good coverage for diagnostics and creation, but lacks update/delete operations for economy resources and cloud save. Missing operations like updating currencies or setting player data could cause agent failures in certain workflows.
A MCP server built for developers enabling Git based project management with project and personal…
MCP registry & directory: search, find & install 31k+ MCP servers & tools. Catalog and marketplace.
MCP server for Appcircle mobile CI/CD platform.
MCP server for building and testing AI agents with multi-model experimentation and insights.
