Universal AI connector for Unity. Unified C# API for OpenAI GPT-5, Anthropic Claude, Google Gemini, Mistral, Cohere, Ollama, LM Studio, llama.cpp, xAI Grok, DeepSeek, and any OpenAI-compatible LLM. Real-time streaming, async/await, cross-platform (Windows, Mac, Linux, Android, iOS, WebGL). Build AI-powered NPCs, chatbots, and tools.
This MCP server exhibits significant gaps in definition quality that would require substantial rework before production use. The tool set spans both game engine operations (Unity scene manipulation) and trivial examples (dice rolling, arithmetic), mixing domains inappropriately. Most critically, parameter descriptions are largely absent or minimal, a hard blocker under the rubric. While tool names follow verb_noun conventions adequately, the descriptions lack LLM-optimization guidance (WHEN to use, dependencies, prerequisites). Schemas are present but sparse, with many parameters undocumented. Error handling and output schema documentation are not evident from the code. The server appears to be a proof-of-concept rather than a production-ready tool connector.
Perform a simple calculation. Supports: add, subtract, multiply, divide.
Create a new GameObject in the scene. Use 'primitive' for visible objects (Cube, Sphere, Capsule, Cylinder, Plane, Quad). Supports Undo.
Find GameObjects by name, tag, or component type. Returns matching objects with their paths.
Get the current date and time.
List all root GameObjects in the active scene with their child counts and active state.
Roll one or more dice. Returns the individual results and the total.
Parameter descriptions are missing or minimal (average ~40 chars vs. baseline 72 chars). Most parameters lack format constraints, ranges, or LLM guidance on valid inputs.
Output schemas are not documented anywhere in the provided code. LLMs cannot plan downstream calls or extract returned data without knowing the response structure.
Tool descriptions lack LLM-optimization guidance: WHEN to call, WHAT prerequisites exist, WHAT dependencies on other tools. Descriptions are functional but not agent-optimized.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Domain confusion: server mixes game engine operations (inspect_scene, create_gameobject) with trivial utility examples (roll_dice, calculate, get_time). A production server should have a cohesive purpose.
Numeric parameters lack bounds. E.g. 'count' in roll_dice has no min/max; 'a' and 'b' in calculate have no range constraints. Unbounded numbers invite invalid LLM calls.
Error handling and recovery guidance are not evident. No indication what errors tools return, whether they are retryable, or how an agent should respond.
'calculate' and 'get_time' are placeholder examples, not domain tools. They add noise and suggest the server is a proof-of-concept rather than production-ready.
Some parameter descriptions are ambiguous or under-specified. E.g. 'Name of parent GameObject' doesn't clarify: is it case-sensitive? Partial match? What happens if parent doesn't exist?