unity-ludometry-mcp
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-ludometry-mcpscan my Unity game and tell me what I can mod"
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.
UnityLudometryMCP
A local Model Context Protocol (MCP) server that helps you understand Unity games and build mods for them. It combines optional static-analysis tools, online research and a runtime agent inside the game (UnityRuntimeAnalysisAgent) into one knowledge base that your AI assistant can query and act on, with your consent at every step that changes anything.
Status: pre-release (v0.1 in development). The MCP server runs and can be registered with your client, but it offers only
server_statusso far. The rest of the orchestrator is being built.
What's here now
The MCP server
unity-ludometry-mcp(stdio) with theserver_statustool.protocol/: the schema-first protocol spoken between the orchestrator and the agent: JSON Schemas for every method, event and exchanged file, golden fixtures, and the zero-dependency C# packageUnityLudometry.Protocol(with message types generated from the schemas) that the agent uses.src/unity_ludometry_mcp/: the Python orchestrator: the protocol layer (models generated from the schemas, strict JSON, framing, envelopes, named-pipe/TCP transports), agent discovery, the agent client, and the package layout the rest of the orchestrator grows into.docs/: documentation.
Related MCP server: Union Unity MCP Server
Requirements
Windows, Python 3.13 with uv, and the .NET SDK (10.0 or newer). Later, optionally: dnSpyEx and the AssetStudio command-line tool, for static analysis.
Install and register
There are no releases yet; run the server from a clone and register it with your MCP client as unity-ludometry-mcp.
In Claude Code:
git clone https://github.com/RectangleEquals/UnityLudometryMCP
cd UnityLudometryMCP
uv sync
claude mcp add unity-ludometry-mcp -- uv run --directory <path to your clone> unity-ludometry-mcpGetting started has the JSON form for other clients, what gets written where (the profile root, otherwise only folders you choose; today nothing at all) and how to remove everything. Configuration lists the environment variables.
Building and testing
See CONTRIBUTING. In short:
uv sync --group dev
uv run pytestAbout the use of AI in this project
This section is here so you can decide for yourself, with accurate information.
How this project is being made. The design and implementation are produced with the help of an AI coding assistant (Anthropic's Claude), working under the direct supervision of a human developer. In practice:
The human decides what the project is for, sets every requirement and constraint, and chooses between the options the AI proposes.
The AI drafts code and documentation within those requirements, one small, reviewable step at a time.
The human reviews every step before it becomes part of the project. Every commit in this repository is made by the human, not by the AI.
Behaviour is checked by automated tests (for the protocol: schema validation and golden fixtures replayed by both sides) and, as the project grows, by running it against real Unity games.
How this project uses AI when you run it. UnityLudometryMCP is an MCP server: it contains no AI model and never contacts an AI service by itself. It offers tools to the AI assistant you connect it to (for example Claude Code), and that assistant decides which tools to call. You stay in control:
Anything that changes something (installing the in-game agent, raising its permission level, modifying a running game, writing files) needs your explicit consent, and every installation is recorded so it can be undone exactly.
The in-game agent starts read-only, lists every action in its overlay, and has an E-STOP that stops all automated activity immediately.
Files are written only to locations you choose. Online research is done by your assistant's own web tools, and its results are treated as unverified until the game confirms them.
If you have questions or concerns about any of this, please open an issue.
License
MIT. See LICENSE.
Available Tools
1 toolserver_statusServer statusARead-onlyIdempotent
Report this server's version, the agent protocol version it speaks, where it keeps its data (the profile root), and what the connected MCP client supports. Read-only; safe to call at any time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description largely repeats 'Read-only; safe to call at any time' and adds the informational scope rather than new behavioral details such as auth or rate limits.
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 two compact sentences with the purpose front-loaded and no wasted words. Every clause contributes to identifying what the tool reports or how safe it is to call.
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 simplicity, rich annotations, zero parameters, and an existing output schema, the description provides everything needed: what is reported and that it is safe. No additional return-value explanation is required because the output schema covers that.
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 takes zero parameters, so there are no parameter semantics for the description to clarify. The baseline for a parameterless tool 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, 'Report', and enumerates the exact informational resources returned: server version, agent protocol version, profile root, and connected MCP client capabilities. With no sibling tools, it is unambiguous and complete.
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?
It clearly states the tool is read-only and 'safe to call at any time', giving explicit context for invocation. There are no sibling alternatives to route against, and no when-not-to-use conditions are needed for this tool.
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.
1 tool update
v0.1.0- First observed
server_status
TDQS
Scored across 1 tool
With only a single tool there is nothing to confuse it with, so selection risk is effectively zero. However, the tool's purpose (server status reporting) gives no signal about what the server's actual domain is, leaving the set trivially unambiguous but uninformative.
The lone tool uses a clear snake_case verb_noun-style name (server_status) that reads well and follows a common convention. With only one tool there is no second name to establish or violate a pattern, so consistency can only be partially assessed.
A single read-only status tool is far too thin for a server whose name implies a ludometry (game/play measurement) domain. One tool cannot plausibly represent the intended scope, making this an extreme under-provision of the surface.
The surface contains only a diagnostic status endpoint and no domain operations whatsoever — no create, read, update, or delete of any ludometry-related resource. An agent has no way to accomplish anything beyond checking server health, so the toolset is severely incomplete.
Maintenance
Related MCP Connectors
Savecraft serves real save game data and expert game knowledge to AI assistants.
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Related MCP Servers
- AlicenseBqualityCmaintenanceA bridge between Unity and AI assistants that enables AI to interact with Unity game environments through a standardized interface for code execution, scene analysis, and runtime debugging.352 npm7MIT
- AlicenseNot gradedqualityFmaintenanceEnables AI agents to interact with Unity projects through multimodal vision, code analysis, asset management, and scene manipulation. Supports real-time Unity editor control, project search, script creation, and visual debugging through screenshots.32MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to interact with Unity Editor, managing scenes, game objects, animations, materials, scripts, and more via natural language commands.1MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to control and automate the Unity Editor, allowing them to build games and scenes from natural language commands.1MIT