Skip to main content
Glama

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_status so far. The rest of the orchestrator is being built.

What's here now

  • The MCP server unity-ludometry-mcp (stdio) with the server_status tool.

  • 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# package UnityLudometry.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-mcp

Getting 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 pytest

About 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 tool
server_statusServer statusA
Read-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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.1.0
    • First observedserver_status

TDQS

A3.9/5.0

Scored across 1 tool

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness1/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers