headless-unity-mcp

by Shonas301

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 maps to a distinct Unity operation: screenshot, lock status, build, list targets, compile, test, and scene generation. Build vs compile are clearly differentiated by their descriptions, and no two tools appear to serve the same purpose.
Naming Consistency4/5
All tools share a consistent 'unity_' prefix, but the action words mix verbs (build, compile, test) with nouns (shot, status, targets, scene). This is mostly predictable but deviates from a pure verb_noun pattern.
Tool Count5/5
With 7 tools, the server is well-scoped for a Unity CI/headless workflow. Each tool covers a specific need without redundancy, and the count is well within the ideal 3-15 range.
Completeness4/5
The tool surface covers the core lifecycle: build, compile, test, screenshot, and scene generation, plus target listing and lock status. Minor gaps like explicit lock release or raw log retrieval are workarounds, but the main workflows are complete.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the build action and the configured build_method, but doesn't disclose whether the build is long-running, whether it blocks, what side effects occur, or whether special permissions are needed. The 'queue_wait_timeout_s' parameter hints at queueing but the description doesn't explain this behavior.
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 with no fluff. The first sentence states the primary function, and the second gives a practical pointer. Every word earns its place.
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?
While the output schema exists, the description doesn't cover the workspace parameter or the timeout semantics, leaving gaps for a build tool. It does provide the essential build target and lists a prerequisite, but for the tool's complexity (3 params) and no annotations, more context would be expected.
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 0%, so the description must compensate. It indirectly explains the 'target' parameter by pointing to unity_targets, but it doesn't clarify the 'workspace' parameter or the 'queue_wait_timeout_s' parameter. The timeout's meaning is only inferable from its name, and workspace is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Build the standalone player') and the resource ('for a target'), with the mechanism 'via its configured build_method'. It distinguishes from unity_compile by specifying a 'standalone player' artifact, though it doesn't explicitly name alternatives.
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?
The description implies usage for building a target and advises calling unity_targets to list names, which is a helpful prerequisite. However, it doesn't provide explicit when-to-use vs alternatives like unity_compile, nor any exclusions or context on when not to use it.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It covers prerequisites (build, screen recording, unlocked screen), the return type (PNG path), and a usage caveat (read in a throwaway subagent). It does not mention side effects like process spawning or cleanup, but the disclosed information is substantial and non-contradictory.
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 and fully front-loaded: it states purpose first, then prerequisites and return behavior. Every clause earns its place with no filler or repetition.
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?
The tool has 3 undocumented parameters and no annotations. While the output schema exists and the description mentions the PNG path, the lack of parameter semantics leaves a significant gap in the context needed to invoke the tool correctly. The agent would not know what target or workspace mean, especially given the sibling unity_targets and unity_build tools.
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?
Schema description coverage is 0%, so the description must explain the parameters (target, workspace, queue_wait_timeout_s). It does not mention any of these parameters or map them to concepts like the build target or workspace path. The agent is left without any guidance on how to fill in the parameters correctly.
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 specific action: 'Launch the built player and screenshot its window by CGWindowID.' This identifies the resource (built player's window) and the operation (screenshot), and it inherently distinguishes from sibling tools like unity_build or unity_status, which have different purposes.
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 clear prerequisites: 'Needs an existing build, the macOS Screen Recording grant, and an unlocked screen.' This tells the agent when the tool can be invoked (after a build, with permissions). It does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only mentions the action and a method. It does not disclose potential side effects (e.g., overwriting an existing scene), whether the operation blocks or queues (despite a queue_wait_timeout_s parameter), or any error/return behavior. The word '(Re)generate' hints at possible overwriting, but this is left implicit.
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, consisting of three short sentences that front-load the core purpose and then provide usage context. No wasted words; every sentence contributes actionable information.
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?
The description covers the essential purpose and the main prerequisite, but it is incomplete regarding parameter roles and behavioral details like queueing and potential overwrites. The presence of an output schema reduces the need to document return values, yet the description still leaves gaps for a three-parameter tool with no annotations.
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 0%, so the description must clarify parameter meanings. It partially explains `target` by referring to a 'target's scene' and pointing to unity_targets for listing names, but it provides no context for `workspace` or `queue_wait_timeout_s`. The description adds minimal value beyond the schema's property names.
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: '(Re)generate a target's scene' with a specific mechanism ('invoking its configured scene_method'). It distinguishes itself from sibling tools like unity_build, unity_test, and unity_shot by focusing on scene generation from code.
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 explicitly states when to use: 'Only for projects that author scenes from code' and provides a direct instruction for a necessary preliminary step: 'Call unity_targets to list target names.' This gives clear guidance on when and how to use the tool.
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?
With no annotations, the description carries the burden of disclosing behavior. It clearly states the read-only nature ('List') and the lock-free guarantee, which are important for an agent to assess side effects. It does not describe error cases or file-location details, but the core behavioral traits are transparent.
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 a single, information-dense sentence. It front-loads the action and resource, then adds the key lock-free constraint without any wasted 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?
The tool is simple, and the output schema likely explains return values. However, the complete absence of parameter guidance and the lack of explicit usage alternatives make the description less complete than ideal. The lock-free note adds valuable context, but the parameter gap prevents a higher score.
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 one parameter ('workspace') with zero description coverage, and the description never mentions it. The agent receives no guidance on what the parameter controls (e.g., which project's targets to list) or how the default empty string behaves, leaving a critical semantic gap.
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 a specific action ('List'), the resource ('build targets'), and the source ('unity-mcp.toml'). It distinguishes itself from siblings like unity_build or unity_compile by being a listing operation, and the lock-free note adds a unique scoping constraint.
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 implies usage for inspecting available build targets, and the explicit 'Never takes the lock' provides practical guidance that it is safe to call concurrently with builds. However, it does not explicitly mention when not to use it or compare with alternatives, leaving some room for inference.
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?
With no annotations, the description carries the full burden and reveals a critical non-obvious behavior: success is determined by grepping the unity log for 'error CS', not the exit code, since Unity exits 0 on compile errors.
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 concise sentences, each adding essential information: the first states the function, the second clarifies a crucial behavior. No unnecessary fluff.
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?
While the core purpose and a key behavior are covered, the description lacks parameter semantics and usage alternatives. Given no annotations and an output schema, it is only partially complete for a tool of this 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 0%, and the description does not explain the 'workspace' or 'queue_wait_timeout_s' parameters. The parameter names hint at their meaning but the description adds no semantics.
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 ('Import and compile all assemblies') with a specific verb and resource, distinguishing it from sibling tools like unity_build and unity_test.
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?
The description implies usage for compilation but provides no explicit when-to-use guidance or alternatives. The verdict clarification is more behavioral than usage-focused.
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?
With no annotations provided, the description fully carries the behavioral disclosure burden. It goes beyond a simple 'runs tests' by explaining the exact failure criteria: a missing XML is a FAIL, and any result="Failed" is a FAIL. It also states that it returns parsed per-platform totals, giving the agent insight into what to expect from the tool's output and how to interpret results.
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 three concise sentences, each adding distinct value: the action, the failure evidence semantics, and the return type. There is no repetition of schema information or fluff. It is perfectly front-loaded with the primary action and efficiently structured.
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?
The description is largely complete for a test-running tool: it covers the operation, critical behavioral details (XML-based failure detection), and return summary. The main gap is the lack of context for 'workspace' and 'queue_wait_timeout_s,' but these are auxiliary parameters with defaults. The presence of an output schema also reduces the need to explain return structure in the description. Overall, it is adequate and informative.
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 0%, so the description must compensate for parameter meaning. It does clarify 'platform' by tying it to EditMode/PlayMode tests, but it gives no explanation for 'workspace' or 'queue_wait_timeout_s.' The schema only provides names and defaults, leaving the agent to guess the purpose of these parameters. Thus, compensation is only partial.
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 opens with a specific verb+resource: 'Run EditMode and/or PlayMode tests.' This clearly identifies the tool's function and distinguishes it from sibling tools like unity_build or unity_compile, which handle other Unity CI tasks. No ambiguity about what this tool does.
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?
While the description does not explicitly name alternative tools or state 'when not to use,' it provides clear context by specifying the test modes (EditMode/PlayMode) and the per-platform totals. This implicitly signals when the tool is appropriate—whenever Unity tests need to run—but lacks explicit exclusions or comparisons to siblings.
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?
With no annotations, the description carries the transparency burden. It discloses the key behavioral trait (never acquires the lock), which is essential for safe usage. It doesn't mention error conditions or output format, but since an output schema exists, that information is available elsewhere.
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 short sentences, front-loaded with the core purpose, then a key qualifier. Every word earns its place; there is zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter status tool with an output schema, the description is complete. It explains what the tool does and explicitly states a critical non-behavior. No additional context is needed.
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?
The tool has zero parameters, so the parameter-semantics burden is minimal. The description adds no parameter details, but none are needed. The baseline for 0-param tools is 4, and no gaps are present.
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 function: it reports who holds the machine lock. It also adds a critical qualifier ('Never takes the lock') that distinguishes it from actions that might acquire the lock. This is a specific, unambiguous purpose.
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 implies when to use this tool: when you need to check lock status without acquiring the lock. It explicitly says 'Never takes the lock,' which serves as a safety guideline. It doesn't explicitly name alternatives, but among sibling tools it's clearly the only status-checking tool.
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:

[![headless-unity-mcp MCP server](https://glama.ai/mcp/servers/Shonas301/headless-unity-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Shonas301/headless-unity-mcp)

Score Badge

Copy to your README.md:

[![headless-unity-mcp MCP server](https://glama.ai/mcp/servers/Shonas301/headless-unity-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Shonas301/headless-unity-mcp)

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/Shonas301/headless-unity-mcp'

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