mcp-garry-codes

Overview Schema Source Related Servers Discussions Admin

Run Headless GLua Unit Tests

run_glua_test

Read-onlyIdempotent

Run headless Garry's Mod unit tests and assertions in a sandboxed Source Engine mock runtime without the game client. Surfaces failures with line numbers and stack traces for debugging.

Instructions

Execute headless Garry's Mod unit tests and assertions using the embedded Source Engine mock runtime (Python/Lua test harness) without requiring the Garry's Mod game client. Sandboxed headless subprocess execution with a default 5000ms timeout (configurable via timeout_ms up to 30000ms). Safe and non-destructive; does NOT modify source files on disk. Surfaces assertion failures and runtime exceptions with exact line numbers and stack traces. Provide either test_file_path (workspace path to a test script) or code_to_test (inline GLua test string with assertions); when both are provided, test_file_path takes precedence. Configure mock_realm ('client', 'server', 'shared', default 'shared') to set SERVER and CLIENT boolean constants and simulate realm-specific global libraries. Use this tool to execute automated test suites, verify mathematical computations, test hook callbacks, and validate net message serialization logic. Do NOT use for static analysis without execution (use lint_glua instead) or Zero-GC allocation profiling (use analyze_performance instead). Returns a GModToolResult envelope with status ('success' when all assertions pass, 'failed' on assertion or execution error), summary, and data containing passed (boolean), tests_run count, failures count, errors array (test_name, error_message, stack_trace), output_log (raw stdout/stderr), and execution_time_ms.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mock_realm`	No	Source engine execution realm environment to simulate ('client', 'server', or 'shared'). Controls SERVER and CLIENT boolean constants and realm-restricted mock libraries.	shared
`timeout_ms`	No	Maximum execution timeout in milliseconds before aborting the test runner process (between 500 and 30000, default is 5000).
`code_to_test`	No	Inline GLua test code string containing assertions (e.g. 'assert(type(Vector) == "function")'). Ignored if test_file_path is provided.
`test_file_path`	No	Workspace path to test script file. Takes precedence over code_to_test when both are provided.

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Domain-specific typed payload returned by the tool.
`status`	Yes	Execution status of the tool call ('success', 'partial', 'blocked', or 'failed').
`summary`	Yes	Concise, human-readable summary of operational findings, diagnostics, or execution outcome.
`evidence`	Yes	Traceability evidence including cited documentation and generated artifacts.
`warnings`	Yes	List of non-fatal warnings, lint advisories, engine caveats, or security notices.
`nextActions`	No	Actionable, ordered recommendations for the agent's immediate next steps.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 26, 2026

changedInput schema / properties / code_to_test / description

Previous value: -"Inline GLua test code with assertions"New value: +"Inline GLua test code string containing assertions (e.g. 'assert(type(Vector) == \"function\")'). Ignored if test_file_path is provided."

addedInput schema / properties / mock_realm / description

Added value: +"Source engine execution realm environment to simulate ('client', 'server', or 'shared'). Controls SERVER and CLIENT boolean constants and realm-restricted mock libraries."

changedInput schema / properties / test_file_path / description

Previous value: -"Workspace path to test script"New value: +"Workspace path to test script file. Takes precedence over code_to_test when both are provided."

changedInput schema / properties / timeout_ms / description

Previous value: -"Max timeout in ms"New value: +"Maximum execution timeout in milliseconds before aborting the test runner process (between 500 and 30000, default is 5000)."

addedInput schema / properties / timeout_ms / maximum
```
Added value: +30000
```
addedInput schema / properties / timeout_ms / minimum
```
Added value: +500
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "description": "Domain-specific typed payload returned by the tool.",
+      "properties": {
+        "errors": {
+          "description": "Detailed error logs and stack traces for failed tests.",
+          "items": {
+            "properties": {
+              "error_message": {
+                "description": "Assertion or runtime error message.",
+                "type": "string"
+              },
+              "stack_trace": {
+                "description": "Lua execution call stack.",
+                "type": "string"
+              },
+              "test_name": {
+                "description": "Identifier of the failed test case.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "test_name",
+              "error_message",
+              "stack_trace"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "execution_time_ms": {
+          "description": "Total execution duration in milliseconds.",
+          "type": "number"
+        },
+        "failures": {
+          "description": "Count of failed assertions.",
+          "type": "integer"
+        },
+        "output_log": {
+          "description": "Raw stdout/stderr execution log from the headless test harness.",
+          "type": "string"
+        },
+        "passed": {
+          "description": "True if all test assertions succeeded with 0 failures and 0 errors.",
+          "type": "boolean"
+        },
+        "tests_run": {
+          "description": "Total number of test assertions evaluated.",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "passed",
+        "tests_run",
+        "failures",
+        "errors",
+        "output_log",
+        "execution_time_ms"
+      ],
+      "type": "object"
+    },
+    "evidence": {
+      "description": "Traceability evidence including cited documentation and generated artifacts.",
+      "properties": {
+        "artifacts": {
+          "description": "Files, packages, or manifests generated on disk or in memory.",
+          "items": {
+            "properties": {
+              "label": {
+                "description": "Descriptive label of the generated artifact.",
+                "type": "string"
+              },
+              "sha256": {
+                "description": "SHA-256 hash of the generated file.",
+                "type": "string"
+              },
+              "uri": {
+                "description": "File path or URI of the generated artifact.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "label",
+              "uri"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "inputsDigest": {
+          "description": "SHA-256 digest of normalized tool inputs for auditability.",
+          "type": "string"
+        },
+        "sources": {
+          "description": "Cited documentation, wiki pages, or external web sources supporting the result.",
+          "items": {
+            "properties": {
+              "label": {
+                "description": "Display name or title of the cited resource.",
+                "type": "string"
+              },
+              "retrievedAt": {
+                "description": "ISO-8601 timestamp of source retrieval.",
+                "type": "string"
+              },
+              "uri": {
+                "description": "Canonical URI or URL of the documentation or source.",
+                "type": "string"
+              }
+            },
+            "required": [
+              "label"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "sources",
+        "artifacts"
+      ],
+      "type": "object"
+    },
+    "nextActions": {
+      "description": "Actionable, ordered recommendations for the agent's immediate next steps.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "status": {
+      "description": "Execution status of the tool call ('success', 'partial', 'blocked', or 'failed').",
+      "enum": [
+        "success",
+        "partial",
+        "blocked",
+        "failed"
+      ],
+      "type": "string"
+    },
+    "summary": {
+      "description": "Concise, human-readable summary of operational findings, diagnostics, or execution outcome.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "List of non-fatal warnings, lint advisories, engine caveats, or security notices.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "status",
+    "summary",
+    "data",
+    "warnings",
+    "evidence"
+  ],
+  "type": "object"
+}

First observedv1.0.0Sep 24, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark it read-only, non-destructive, and idempotent, and the description reinforces this with 'Safe and non-destructive; does NOT modify source files on disk'. It adds valuable behavior beyond annotations: sandboxed headless subprocess execution, a default 5000ms timeout configurable up to 30000ms, and surfacing of assertion failures/runtime exceptions with line numbers and stack traces.

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 long but dense, with every sentence carrying distinct information: purpose, safety, timeout, error behavior, parameter semantics, precedence, usage guidance, and return envelope. It is front-loaded with the core action and keeps the alternative-routing guidance near the middle, where it is useful without obscuring the primary purpose.

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 complexity, the description is complete: it covers execution mode, safety profile, timeout bounds, realm configuration, input precedence, output envelope fields, and alternative tools. The output schema exists and the description still summarizes the returned GModToolResult fields, so no necessary context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains the precedence relationship between test_file_path and code_to_test, specifies that mock_realm sets SERVER/CLIENT constants and simulates realm-specific libraries, and gives an inline code example. This materially augments the structured schema.

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 pair: 'Execute headless Garry's Mod unit tests and assertions', and names the embedded Source Engine mock runtime. It distinguishes the tool from siblings by explicitly excluding static analysis (lint_glua) and Zero-GC profiling (analyze_performance), so an agent can select it unambiguously.

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?

It states when to use the tool ('Use this tool to execute automated test suites, verify mathematical computations, test hook callbacks, and validate net message serialization logic') and gives explicit when-not-to-use guidance with named alternatives. It also clarifies the input selection rule: test_file_path takes precedence over code_to_test when both are provided.

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

Deploy Server