Skip to main content
Glama
MarzLars

Unity UIToolkit MCP Server

by MarzLars
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

Unity UIToolkit MCP Server

A Vibe Coded Model Context Protocol (MCP) server that provides LLM agents with access to Unity UIToolkit documentation, code examples, and conversion tools for migrating HTML/CSS to UXML/USS.

Features

This MCP server provides the following tools for working with Unity UIToolkit:

Pre-rendered Documentation (Recommended)

  • list_prerendered_docs: Lists all available pre-rendered Markdown documentation

  • read_prerendered_docs: Reads clean, LLM-friendly Markdown documentation converted from Unity's HTML docs

Note: Pre-rendered documentation is automatically fetched and converted weekly via GitHub Actions using markitdown. This provides faster access, better LLM digestibility, and eliminates runtime dependencies on external sites.

Legacy Documentation Tools

  • get_uitoolkit_documentation: Provides Unity UIToolkit documentation reference with links and examples for specific topics (UXML, USS, VisualElement, etc.)

  • get_unity_script_reference: Access Unity Script API reference documentation for UIToolkit classes and methods

  • list_uitoolkit_components: List available UIToolkit components and controls by category

Code Examples

  • get_uitoolkit_code_example: Provides common Unity UIToolkit code example patterns with links to Unity's official examples repository

  • fetch_unity_example_code: Fetches actual source code from Unity's UI Toolkit examples repository. Use this to retrieve implementation samples referenced in documentation (e.g., from <code source="..."/> tags)

Conversion Tools

  • convert_html_to_uxml: Convert HTML markup to UXML format with guidance and best practices

  • convert_css_to_uss: Convert CSS styles to USS (Unity Style Sheets) format with property mappings

Related MCP server: Unity MCP Server

Documentation Pre-rendering

Unity UIToolkit documentation is automatically fetched and converted to Markdown:

  • Schedule: Weekly on Mondays at 00:00 UTC

  • Trigger: Can be manually triggered via GitHub Actions

  • Process:

    1. Fetches latest Unity UIToolkit HTML documentation

    2. Filters to UIToolkit-related pages only

    3. Converts to clean Markdown using markitdown

    4. Commits to docs/ directory

See .github/workflows/update-unity-docs.yml for implementation details.

Installation

npm install
npm run build

Usage

This MCP server uses the stdio transport and can be integrated with any MCP-compatible client.

Configuration

Add to your MCP client configuration (e.g., Claude Desktop config):

{
  "mcpServers": {
    "uitoolkit": {
      "command": "node",
      "args": ["/path/to/UIToolkitMCP/dist/index.js"]
    }
  }
}

Or use npx:

{
  "mcpServers": {
    "uitoolkit": {
      "command": "npx",
      "args": ["uitoolkit-mcp-server"]
    }
  }
}

Available Tools

1. list_prerendered_docs

Lists all available pre-rendered documentation files.

Parameters: None

Example:

{}

2. read_prerendered_docs

Reads pre-rendered Markdown documentation.

Parameters:

  • doc_type (string): Either "manual" or "script-api"

  • doc_name (string): Name of the documentation file (e.g., "UXML", "UIElements_VisualElement")

Example:

{
  "doc_type": "manual",
  "doc_name": "UXML"
}

3. get_uitoolkit_documentation

Retrieves Unity UIToolkit documentation for specific topics.

Parameters:

  • topic (string): The UIToolkit topic to search for (e.g., "UXML", "USS", "VisualElement")

Example:

{
  "topic": "UXML"
}

4. get_uitoolkit_code_example

Provides common Unity UIToolkit code example patterns with links to Unity's official repository.

Parameters:

  • example_name (string): Name or path of the example (e.g., "simple-list-view", "custom-control")

Example:

{
  "example_name": "simple-list-view"
}

5. fetch_unity_example_code

Fetches actual source code from Unity's UI Toolkit examples repository. This is particularly useful when you encounter <code source="..."/> tags in the script-api documentation and want to see the actual implementation.

Parameters:

  • file_path (string): Path to the code file (e.g., "Button_clicked.cs" or "Modules/UIElements/Tests/UIElementsExamples/Assets/Examples/Button_clicked.cs")

Example:

{
  "file_path": "Button_clicked.cs"
}

Note: The tool will automatically search multiple Unity repositories to find the code:

  • Unity's public UI Toolkit manual code examples repository

  • Unity's C# Reference repository (for internal test examples)

6. get_unity_script_reference

Retrieves Unity Script API reference for UIToolkit classes.

Parameters:

  • class_name (string): The Unity class name (e.g., "VisualElement", "ListView", "Button")

Example:

{
  "class_name": "ListView"
}

7. convert_html_to_uxml

Provides guidance for converting HTML to UXML.

Parameters:

  • html_snippet (string): HTML code to convert

Example:

{
  "html_snippet": "<div class='container'><button>Click Me</button></div>"
}

8. convert_css_to_uss

Provides guidance for converting CSS to USS.

Parameters:

  • css_snippet (string): CSS code to convert

Example:

{
  "css_snippet": ".button { background-color: blue; padding: 10px; }"
}

9. list_uitoolkit_components

Lists available UIToolkit components.

Parameters:

  • category (string, optional): Filter by category ("containers", "controls", "data-bound", "advanced")

Example:

{
  "category": "controls"
}

Resources

Development

Build

npm run build

Watch Mode

npm run watch

License

MIT

Available Tools

5 tools
convert_html_to_uxmlC

Provides guidance and examples for converting HTML markup to UXML format. Returns conversion patterns and best practices.

ParametersJSON Schema
NameRequiredDescriptionDefault
html_snippetYesHTML code snippet to convert to UXML

TDQS

C2.9/5.0
Behavior2/5

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

The description says it 'returns conversion patterns and best practices', which conflicts with the tool name's implication of performing a conversion. This ambiguity is misleading; the actual behavior (whether it outputs converted UXML or just patterns) is not disclosed. No annotations exist to mitigate this.

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 only two sentences, concise and front-loaded. However, the phrasing could be more precise without adding length.

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?

For a single-parameter tool with no output schema, the description covers the purpose but lacks details on output format, limitations, or when it might not work. It is adequate but not thorough.

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%, so the parameter is already well-described in the schema. The description adds only general context about guidance and examples, not additional semantic detail beyond what the schema provides.

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 tool converts HTML to UXML, but adds ambiguity by mentioning 'guidance and examples' and 'conversion patterns', which may imply it is a reference rather than an actual converter. It distinguishes from sibling tools that fetch code examples or references.

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 explicit guidance on when to use this tool versus alternatives. Sibling tools suggest possible overlaps (e.g., getting code examples), but no when-not-to-use or prerequisite conditions are provided.

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

fetch_unity_example_codeA

Fetches the actual source code content from a specific file in Unity's UI Toolkit examples repository. Use this when you have a code source reference (e.g., from tags in documentation) and need to see the actual implementation.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the code file in the Unity examples repository (e.g., 'Modules/UIElements/Tests/UIElementsExamples/Assets/Examples/Button_clicked.cs')

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses the action (fetching source code) and the source (Unity's UI Toolkit examples repository). No mention of authentication or rate limits, but for a read-only fetch operation, the description is reasonably 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?

Two concise sentences, front-loaded with the main action ('Fetches actual source code content...'). No unnecessary words or redundancy. Every sentence serves a purpose: first explains what it does, second explains when to use it.

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 simplicity of the tool (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose and usage. It doesn't describe the return format, but for a source code fetch, the content is typically plain text, which is implicit.

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% for the single parameter 'file_path'. The description adds value beyond the schema by providing a concrete example and explaining the parameter's context (e.g., from documentation code source tags). This helps the agent understand how to populate the parameter 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?

Description clearly states the tool fetches source code from a specific file in Unity's UI Toolkit examples repository. It uses specific verbs ('fetches', 'actual source code content') and distinguishes from siblings by focusing on code source references from documentation tags like <code source='...'/>.

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?

Explicitly specifies when to use: when you have a code source reference from documentation and need to see the actual implementation. While it doesn't state when not to use or name alternatives explicitly, the context signals (sibling tools) and the clear use case provide good guidance.

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

get_uitoolkit_code_exampleA

Fetches actual code examples from Unity's official UI Toolkit manual code examples repository (https://github.com/Unity-Technologies/ui-toolkit-manual-code-examples). Use this to retrieve real implementation samples showing UIToolkit syntax and usage patterns.

ParametersJSON Schema
NameRequiredDescriptionDefault
example_nameYesName or path of the example to retrieve (e.g., 'simple-list-view', 'custom-control', 'data-binding', or a file path like 'ListView/SimpleListView.cs')

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose behaviors. It implies a read-only fetch operation but does not explicitly state that it is non-destructive or lacks side effects. The description is adequate but not rich.

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 concise sentences that immediately convey the tool's purpose and usage. There is no unnecessary information.

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 explains what the tool does and where it fetches examples from. However, it does not describe the format of the returned code examples or the response structure. Given the lack of an output schema, this is a minor gap.

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?

The schema description coverage is 100% for the single parameter, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for 'example_name'.

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 that the tool fetches actual code examples from a specific repository (Unity's UI Toolkit manual code examples repo), making its purpose unambiguous. It differentiates from sibling tools by specifying the exact source.

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 provides a clear usage scenario ('retrieve real implementation samples showing UIToolkit syntax and usage patterns') but does not explicitly state when not to use it or mention alternatives among the sibling tools.

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

get_unity_script_referenceB

Retrieves Unity Script API reference documentation for UIToolkit classes and methods. Use this to get detailed API information.

ParametersJSON Schema
NameRequiredDescriptionDefault
class_nameYesThe Unity class name to look up (e.g., 'VisualElement', 'ListView', 'Button', 'Label')

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, so the description carries full burden. Describes only a read operation with no side effects, but lacks any disclosure of input constraints, rate limits, or potential errors. Minimal transparency beyond the basic 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?

Extremely concise: two sentences, no filler, front-loaded with the core action. 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?

With one parameter and no output schema, the description is adequate but minimal. It does not explain what format the documentation returns, whether it includes methods and properties, or how it relates to other tools. Leaves some gaps for an agent.

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 has one parameter (class_name) with full description coverage (100%). The tool description does not add any additional semantic value beyond what the schema already provides, so baseline score of 3 is appropriate.

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?

Clearly states it retrieves Unity Script API reference for UIToolkit, with specific verb 'Retrieves' and resource 'API reference documentation'. However, does not explicitly distinguish from sibling tools like 'get_uitoolkit_code_example' or 'read_prerendered_docs', leaving slight ambiguity.

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 phrase 'Use this to get detailed API information' implies when to use, but no explicit guidance on when not to use or comparison with alternatives (e.g., code examples, prerendered docs). Context must be inferred by the agent.

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

read_prerendered_docsA

Reads pre-rendered documentation for Unity UIToolkit. Returns documentation from either Unity's HTML manual (for UXML, USS, etc.) or from C# source code (for class API references).

ParametersJSON Schema
NameRequiredDescriptionDefault
doc_nameYesName of the documentation file (e.g., 'UXML' for manual, 'Button' for script-api)
doc_typeYesType of documentation: 'manual' for UIToolkit concepts or 'script-api' for class references

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It discloses that the tool reads pre-rendered docs from two sources, which implies a read-only operation. However, it lacks details on potential side effects, authentication requirements, rate limits, or output format, leaving some gaps.

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, front-loaded with the core purpose, and contains no extraneous information. Every sentence contributes to understanding the tool.

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 simplicity of the tool (2 parameters, no output schema, no annotations), the description is mostly sufficient. It could be improved by mentioning the output format (e.g., returns HTML text or plain text), but overall it provides a clear functional overview.

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 input schema covers both parameters with descriptions. The description adds value by providing concrete examples (e.g., 'UXML' for manual, 'Button' for script-api) and clarifying the mapping of doc_type to document type, exceeding the schema 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 the tool reads pre-rendered documentation for Unity UIToolkit, specifying two distinct sources (HTML manual and C# source code). The name and description together unambiguously indicate the tool's function, and it is distinguishable from siblings which focus on code examples or script references.

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 that the tool is used to retrieve documentation text, differentiating it from siblings like get_uitoolkit_code_example or get_unity_script_reference. However, it does not explicitly state when not to use it or provide direct comparisons to alternatives.

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

Tool Schema Changelog

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

  1. 5 tool updatesv1.0.0
    • First observedconvert_html_to_uxml
    • First observedfetch_unity_example_code
    • First observedget_uitoolkit_code_example
    • First observedget_unity_script_reference
    • First observedread_prerendered_docs
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation3/5

Tools have some overlap: get_uitoolkit_code_example and fetch_unity_example_code both deal with code examples from the same repository, while get_unity_script_reference and read_prerendered_docs both provide API reference information, creating potential ambiguity for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_uitoolkit_code_example, fetch_unity_example_code, convert_html_to_uxml), making the naming uniform and predictable.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of providing Unity UIToolkit documentation and code examples, avoiding unnecessary complexity while covering key functions.

Completeness3/5

The tool set covers code examples, API reference, HTML conversion, and documentation reading, but lacks search or listing capabilities, which could force agents to rely on exact references.

Maintenance

ActivityActive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Unity MCP Server

    rachitkumarrastogi
    F
    license
    B
    quality
    B
    maintenance
    Provides AI assistants with structured access to Unity project metadata, build settings, and agent documentation directly from the filesystem. It enables querying project details and scene configurations without requiring the Unity Editor to be running.
    100
    124
    5
    -

  • Unity MCP Server

    AnkleBreaker-Studio
    A
    license
    B
    quality
    A
    maintenance
    Provides AI assistants with comprehensive control over Unity Hub and Unity Editor through over 200 specialized tools for project management and scene manipulation. It enables users to perform complex tasks like script creation, asset management, and project builds using natural language commands.
    80
    193
    394
    -

  • Unity MCP Server

    coolmew
    A
    license
    Not graded
    quality
    Not graded
    maintenance
    Exposes Unity Editor project context and manipulation tools to AI coding agents, enabling automated scene hierarchy analysis, script inspection, and asset management. It supports both read and write operations including GameObject editing, component configuration, and animation authoring within the Unity environment.
    2
    -

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MarzLars/UIToolkitMCP'

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