This server provides a suite of read-only analysis, search, scaffolding, testing, and packaging tools for Garry's Mod (GLua) development.
Search official GMod documentation by keyword or exact symbol, filtered by realm and category.
Search community sources like GitHub, Facepunch, Reddit, and Steam for GLua solutions and undocumented quirks.
Lint GLua code statically for syntax errors, realm mismatches, and global pollution.
Audit network security to detect unauthenticated net receivers, SQL injection, and missing network strings.
Analyze performance to catch Zero-GC hot-path traps like allocations in render hooks.
Scaffold common GMod components such as SWEPs, SENTs, nextbots, STOOLs, VGUI panels, HUDs, effects, DarkRP modules, and gamemodes.
Run headless GLua unit tests using a mock Source Engine runtime with Vector/Angle/net/hook simulation.
Package and validate addons against Steam Workshop/GMA rules, with optional .gma compilation.
Provides access to the Facepunch Garry's Mod Wiki and developer archives, enabling search and retrieval of GLua functions, hooks, libraries, and official examples for addon development.
Searches GitHub for GLua repositories and code examples, along with Facepunch archives and developer discussions, to find community patterns and solutions.
Enables validation and packaging of Garry's Mod addons against Steam Workshop rules, including addon.json schema verification and GMA compilation.
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., "@mcp-garry-codes audit my addon for net security vulnerabilities"
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.
mcp-garry-codes — The Principal Garry's Mod Protocol Server
mcp-garry-codesis a specialized, production-grade Model Context Protocol (MCP) server engineered specifically for the Garry's Mod (GLua) ecosystem. It bridges AI coding agents with deep Source Engine awareness, static verification, net-security vulnerability auditing, zero-GC performance profiling, and headless testing.
Created & Maintained by: M A R W A N
Garry's Mod development represents a notoriously hostile coding environment:
Three Rigid Execution Realms (SERVER, CLIENT, and MENU) with strict serialization and transmission rules.
Micro-Allocation Garbage Collection Traps inside high-frequency rendering and simulation hooks (RenderScreenspaceEffects, HUDPaint, Think, Move) triggering severe client FPS drops.
Pervasive Network Vulnerabilities stemming from unvalidated client-authoritative net messages, rate-limit exploitation, SQL injections, and command execution backdoors.
Source Engine VGUI & Prediction Peculiarities where standard desktop GUI mental models fail.
mcp-garry-codes equips LLMs and autonomous coding assistants with the deep domain knowledge and verification tools necessary to produce bulletproof GLua code.
Related MCP server: Godot MCP
Tool Name | Realm Mode | Primary Function | Side Effects |
| Read-only | Query Facepunch Garry's Mod Wiki and indexed documentation filtered by realm and category. | Cached disk/memory |
| Read-only | Retrieve exact parameter signatures, return values, caveats, and official examples. | Cached |
| Read-only | Targeted search across GitHub GLua repositories, Facepunch archives, and developer discussions. | HTTPS query |
| Read-only / Pure | Static analysis parsing GMod C-style syntax ( | |
| Read-only / Audit | Scan addon message graphs for unauthenticated receivers, SQL injections, and missing | None |
| Read-only / Audit | Profile GLua code for Zero-GC hot-path violations (allocations in | None |
| Creation | Scaffold idiomatic SWEPs, SENTs, NextBots, STOOLs, VGUI panels, HUDs, Effects, DarkRP modules, or gamemodes. | File creation (Workspace only) |
| Execution / Sandbox | Run headless GLua unit tests using the embedded Source Engine mock runtime via LuaJIT / Python. | Sandboxed subprocess |
| Verification / Build | Validate | Optional |
Connect to rich contextual resources using standard MCP URIs:
gmod://wiki/hooks — Authoritative list of Garry's Mod hooks across all realms.
gmod://wiki/libraries — Core functions and libraries available in GLua.
gmod://realms/matrix — Execution realm boundaries, powers, and restrictions.
gmod://schemas/addon_json — Steam Workshop addon.json schema specification.
audit_addon — Comprehensive security and performance review of an addon folder.
fix_net_exploit — Guided repair workflow for net message vulnerabilities and authorization checks.
scaffold_swep — Interactive creation of a predicted, zero-latency weapon.
build_derma_menu — Responsive, DPI-scaled VGUI Derma interface builder.
scaffold_nextbot — Autonomous NextBot AI entity with navigation coroutines.
scaffold_toolgun_stool — Production Toolgun STOOL with CPanel convars, left/right clicks, and language strings.
scaffold_darkrp_module — Modular DarkRP package with custom jobs, shipments, categories, and hooks.
scaffold_effect — Custom 3D particle and billboard render effect.
optimize_zero_gc — Profile and optimize rendering hooks for zero garbage-collection stutter.
npx (Recommended)npx -y mcp-garry-codesnpmnpm install -g mcp-garry-codes
mcp-garry-codesmcp_config.json)Add the server definition to your mcp_config.json:
{
"mcpServers": {
"mcp-garry-codes": {
"command": "npx",
"args": ["-y", "mcp-garry-codes"],
"env": {
"WORKSPACE_ROOT": "${workspaceFolder}",
"PYTHON_PATH": "python"
}
}
}
}claude_desktop_config.json){
"mcpServers": {
"garrys-mod": {
"command": "npx",
"args": ["-y", "mcp-garry-codes"]
}
}
}Workspace Path Jail: All file queries, linter checks, and scaffolding operations are verified with PathGuard and strictly quarantined within the user's configured workspace.
Subprocess Isolation: External processes (python, glualint, luajit) execute via child_process.execFile with explicit argument arrays—no shell interpolation (shell: false) and strict execution timeouts (5,000ms default).
Automated Credential Redaction: Result envelopes pass through sanitization regexes that scrub Steam API keys, MySQL connection strings, and RCON passwords.
Net Message Auditing: Receivers executing mutations without checking ply:IsAdmin() or access privileges are flagged as critical vulnerabilities.
mcp-garry-codes includes an embedded Source Engine mock runtime (src/test_harness/lua/glua_mock.lua) and Python test orchestrator (src/test_harness/python/gmod_tester.py). It enables running headless unit tests without launching the Garry's Mod 32-bit or 64-bit client executable:
Full 3D Vector and Angle metatables (Distance, Dot, Cross, Length2D, RotateAroundAxis).
Mock Entity and Player objects with health, inventory, and trace methods.
In-memory FIFO bitstream queue verifying net.Write* and net.Read* alignment.
Event bus verifying hook.Add and hook.Run.
This project is licensed under the MIT License.
Author: M A R W A N
Profile Garry's Mod Lua code via static AST inspection to detect runtime performance traps, Zero-GC violations, and LuaJIT garbage collector bottlenecks. Purely analytical static inspection; does NOT execute code, does NOT evaluate scripts in a VM, and does NOT modify files on disk. Operates under zero-side-effect guarantees. Provide either file_path (workspace path) or code_content (raw snippet); when both are supplied, file_path takes precedence. Automatically inspects high-frequency rendering and simulation hooks (HUDPaint, RenderScreenspaceEffects, Think, Move). Use this tool to prevent client FPS stutter and server tickrate drops by flagging table allocations (Color(), Vector(), Angle()), unlocalized global lookups, and dynamic font creation inside per-frame hooks. Do NOT use for syntax or realm correctness checks (use lint_glua instead), network message exploit detection (use audit_net_security instead), or functional assertion testing (use run_glua_test instead). Returns a GModToolResult envelope with status ('success' or 'failed'), summary, and data containing performance_score (0-100), issues array (hook_name, line, severity, category, description, recommended_code), and allocation metrics (allocations_in_hot_path, global_calls_in_hot_path, dynamic_draw_calls).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Workspace path to .lua file to profile. Takes precedence over code_content when both are supplied. | |
| code_content | No | Direct GLua source code snippet to profile. Ignored if file_path is provided. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that it is purely static analytic, does not execute code, does not evaluate in a VM, does not modify files, and operates under zero-side-effect guarantees—richer than the annotation hints alone. It also discloses automatic inspection of specific hooks. No contradiction.
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 thorough (~200 words) and well-structured, front-loading the core purpose, then exclusions, usage guidance, and output format. Every sentence adds value, but it is slightly verbose and could be tightened without losing clarity. A 4 reflects good but not perfect conciseness.
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?
For a tool with two optional parameters and a defined return envelope, the description fully covers input precedence, behavioral guarantees, exclusions and alternatives, and the exact output structure (status, summary, performance_score, issues array fields, allocation metrics). No required information is missing for an agent to call it correctly.
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?
Schema description coverage is 100%, with both file_path and code_content fully explained in the schema. The description restates the precedence rule ('file_path takes precedence') but adds no new semantic details beyond what the schema already provides. Per the baseline rule for high coverage, a 3 is appropriate.
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 opens with a specific function: profiling GLua via static AST inspection to detect performance traps, Zero-GC violations, and LuaJIT GC bottlenecks. It explicitly differentiates from sibling tools by naming lint_glua, audit_net_security, and run_glua_test as alternatives for other checks, making the purpose unmistakable.
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 states clearly when to use: to prevent client FPS stutter and server tickrate drops by flagging allocations, unlocalized lookups, and dynamic font creation in hooks. It also explicitly lists what not to use for (syntax/realm checks, network security, functional tests) and points to the precise alternative tools. This is unambiguous routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform static AST security auditing across an addon's network messaging architecture (Garry's Mod net library) to identify exploitable receivers, SQL injection vectors, and missing network string registrations. Purely static AST analysis requiring no authentication, no network transmission, and zero file modifications. Scans code without executing it. Specify addon_dir (root directory of the addon; defaults to workspace root if omitted). Optionally provide file_paths array to restrict scanning to specific Lua files within that addon. Use this tool before releasing or deploying multiplayer Garry's Mod addons to detect unauthenticated net.Receive handlers (missing ply:IsAdmin or permission checks), client-authoritative SQL queries, and unregistered net strings that crash network channels. Do NOT use for general syntax validation (use lint_glua instead) or rendering performance profiling (use analyze_performance instead). Returns a GModToolResult envelope with status ('success' or 'failed'), summary, and data containing addon_dir, messages_found, registered_strings, network_graph (transmitters and receivers), and categorized vulnerabilities array (severity, type, message_name, file, line, description, recommended_fix, vulnerable_code).
| Name | Required | Description | Default |
|---|---|---|---|
| addon_dir | No | Root directory of the Garry's Mod addon to audit. Defaults to current workspace root if omitted. | |
| file_paths | No | Optional list of specific relative or absolute Lua file paths within addon_dir to audit. If omitted, recursively scans all Lua files in addon_dir. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly, idempotent, and non-destructive annotations, the description discloses that the tool requires no authentication, performs no network transmission, makes zero file modifications, and does not execute code. It also explains that scanning is purely static AST analysis, giving the agent an accurate safety and side-effect profile.
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 dense but front-loaded with the core purpose and explicitly organized with usage guidance and exclusions. The return envelope detail is somewhat redundant given that an output schema exists, but the overall structure remains efficient and each major section earns its place.
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?
The description covers purpose, scope, parameters, safety profile, output envelope shape, and concrete detection categories. With rich annotations and an output schema present, nothing an agent needs to correctly select and invoke this tool is missing.
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?
Schema description coverage is 100%, so the structured schema already documents both parameters and their defaults. The description adds context about scoping file_paths to 'specific Lua files within that addon,' but it largely restates what the schema provides rather than introducing new semantic depth.
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 states a specific verb ('Perform static AST security auditing') and resource ('network messaging architecture'), and enumerates concrete outcomes: exploitable receivers, SQL injection vectors, and missing network string registrations. It clearly differentiates from sibling tools by naming what it is not for, such as syntax validation or performance profiling.
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 explicitly tells the agent when to use the tool: before releasing or deploying multiplayer Garry's Mod addons to detect unauthenticated net.Receive handlers, client-authoritative SQL, and unregistered net strings. It also names alternatives for related but distinct tasks: lint_glua for syntax validation and analyze_performance for rendering profiling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve authoritative, complete API documentation for a specific, known Garry's Mod symbol (function, hook, library method, panel, or class) from the Facepunch Wiki index. Read-only lookup operation with zero side effects, no authentication required, and instant indexed retrieval; does NOT modify the workspace. If the symbol is not found in the index, returns status 'failed' with data null and provides actionable search alternatives in nextActions. Requires an exact, case-sensitive or standard symbol identifier (e.g. 'net.Receive', 'surface.DrawPoly', 'GM:PlayerInitialSpawn', 'Entity:TakeDamage'). Set include_examples to false (defaults to true) to exclude code examples and reduce token consumption. Use this tool when you know the exact symbol name and require complete parameter specifications, return types, engine caveats, realm affinity, or code examples. Do NOT use for keyword or topic searches (use search_gmod_wiki instead). Do NOT use for third-party addon code or community forum workarounds (use web_search_glua instead). Returns a GModToolResult envelope with status ('success' or 'failed'), summary, and data containing symbol, realm, description, arguments array (name, type, optional, default, description), returns array, examples array, notes, warnings, and canonical wiki_url.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Exact case-sensitive or standard Garry's Mod symbol name (e.g. 'util.AddNetworkString', 'net.Receive', 'GM:PlayerInitialSpawn', 'surface.DrawPoly', 'Entity:TakeDamage'). | |
| include_examples | No | Whether to include official Lua code usage examples in the response (default is true; set false to reduce token payload). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint, idempotentHint, and destructiveHint annotations, the description clarifies 'Read-only lookup operation with zero side effects, no authentication required' and failure behavior: returns status 'failed' with data null and actionable nextActions. No contradiction with annotations.
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 longer than the minimum but organized: purpose, usage boundaries, failure behavior, and envelope. It slightly repeats schema defaults (include_examples default, symbol examples), but every section earns its place and the key constraints are front-loaded.
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?
For a read-only lookup with an output schema, the description covers success and failure envelopes, realm, arguments, returns, examples, notes, warnings, and canonical wiki_url, plus siblings for alternate cases. Nothing necessary to select or invoke it correctly is missing.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that include_examples=false 'reduce[s] token consumption' and by emphasizing the exact/case-sensitive identifier requirement with examples, going slightly beyond the schema definitions.
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 opens with a specific action and resource: 'Retrieve authoritative, complete API documentation for a specific, known Garry's Mod symbol ... from the Facepunch Wiki index.' It also names sibling tools and what they are for, making it easy to distinguish from search_gmod_wiki and web_search_glua.
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?
Explicit use case: 'Use this tool when you know the exact symbol name and require complete parameter specifications...' and explicit exclusions: 'Do NOT use for keyword or topic searches' and 'Do NOT use for third-party addon code...', each naming the alternative tool. This fully routes the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform deep static analysis and AST validation on Garry's Mod Lua (GLua) source code to detect syntax errors, realm boundary violations (server/client/menu mismatches), global namespace pollution, and missing AddCSLuaFile calls. Purely read-only static analysis requiring zero credentials or network access. Does NOT execute code and does NOT modify files on disk; when fix_formatting is true, the formatted code is returned strictly inside the result envelope without overwriting the source file. Provide either file_path (workspace-relative or absolute) or code_content (raw Lua snippet); when both are supplied, file_path takes precedence. If target_realm is 'auto', automatically detects the execution realm from file path prefixes (sv_, cl_, sh_) or defaults to 'shared'. Use this tool before committing code or running tests to ensure syntax and realm hygiene. Do NOT use for runtime performance profiling (use analyze_performance instead to detect GC allocations in render hooks), network vulnerability scanning (use audit_net_security instead), or functional test execution (use run_glua_test instead). Returns a GModToolResult envelope containing status ('success' or 'failed'), summary, data with valid (boolean), error_count, warning_count, realm_detected, diagnostics list (line, column, severity, rule code, message, suggestion), and optional formatted_code.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Workspace-relative or absolute path to .lua file to lint. Takes precedence over code_content when both are provided. | |
| code_content | No | Direct GLua source code string to analyze statically. Used when file_path is omitted. | |
| target_realm | No | Target execution realm context for static analysis ('server', 'client', 'shared', 'menu', or 'auto'). 'auto' infers realm from filename conventions (sv_, cl_, sh_) or defaults to 'shared'. | auto |
| fix_formatting | No | When true, runs glualint auto-fixer and returns formatted_code in the result data without mutating or overwriting the file on disk (default is false). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by stating that the tool requires zero credentials or network access, does not execute code, and does not modify files on disk. It also discloses the non-obvious behavior of fix_formatting: formatted code is returned inside the result envelope rather than overwriting the source. These statements are consistent with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, adding valuable safety context.
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 well-structured and front-loaded: purpose first, safety guarantees second, input semantics third, usage guidance fourth, and output format last. It is lengthy but each sentence carries meaningful information, with only minor redundancy around 'read-only', 'does not execute code', and 'does not modify files'. The explicit exclusions and output envelope enumeration earn their place.
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 annotations, 100% schema coverage, and an output schema, the description covers all essential decision factors: what the tool does, what it detects, its side-effect-free behavior, input selection rules, realm detection behavior, exclusions, and result envelope contents. No critical context is missing for an agent to invoke this tool safely and correctly.
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 input schema already achieves 100% parameter description coverage, including file_path precedence over code_content, the target_realm enum with auto-detection semantics, and fix_formatting's non-mutating behavior. The description largely restates these schema details rather than adding substantial new parameter-level meaning. This aligns with the baseline of 3 for high schema coverage.
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 opens with a specific verb and resource: 'Perform deep static analysis and AST validation on Garry's Mod Lua (GLua) source code'. It enumerates concrete detections (syntax errors, realm boundary violations, global namespace pollution, missing AddCSLuaFile calls) and explicitly distinguishes itself from sibling tools by naming what it does not do. This leaves no ambiguity about the tool's role versus run_glua_test, analyze_performance, or audit_net_security.
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?
The description gives explicit when-to-use guidance ('before committing code or running tests') and explicit when-not-to-use guidance with named alternatives: analyze_performance for runtime profiling, audit_net_security for network vulnerability scanning, and run_glua_test for functional test execution. These exclusions map directly to sibling tool names and make the selection decision nearly foolproof.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Garry's Mod addon directory against official Steam Workshop and GMA packaging rules (addon.json validation, file extension whitelist, path casing), with optional .gma archive compilation. Read-only validation by default; does NOT mutate files. If build_gma is true AND validation passes with zero illegal files, compiles a .gma binary package using the external gmad executable (requires GMAD_PATH environment variable) to output_gma_path (defaults to '/out.gma'). addon_dir specifies the root directory of the addon (defaults to workspace root). Set build_gma to true (default false) to trigger .gma compilation. Optional output_gma_path sets the target .gma binary path. Use this tool as the final verification gate before uploading addons to the Steam Workshop or deploying to a dedicated server. Checks addon.json structure, flags non-whitelisted files (e.g. .psd, .git, .exe), and warns on uppercase characters that cause 404s on Linux servers. Use scaffold_gmod_component to bootstrap addon structures, and lint_glua/audit_net_security to audit code quality prior to packaging. Returns a GModToolResult envelope with status ('success' or 'failed'), summary, and data containing valid (boolean), addon_json_valid (boolean), total_files, total_size_bytes, illegal_files array (path, rejection reason), warnings array (casing and metadata warnings), and optional gma_path.
| Name | Required | Description | Default |
|---|---|---|---|
| addon_dir | No | Root directory of the Garry's Mod addon to inspect and validate. Defaults to current workspace root if omitted. | |
| build_gma | No | When true and validation succeeds with 0 illegal files, invokes gmad to compile a .gma binary archive. Requires GMAD_PATH environment variable (default is false). | |
| output_gma_path | No | Destination file path for the compiled .gma file. Defaults to '<addon_dir>/out.gma' if build_gma is true and this is omitted. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses the conditional mutation behavior: 'Read-only validation by default; does NOT mutate files. If build_gma is true AND validation passes with zero illegal files, compiles a .gma binary package using the external gmad executable.' It also surfaces the GMAD_PATH requirement and default output location, which goes beyond the annotations and gives an agent accurate expectations about side effects. This does not contradict the readOnlyHint=false or destructiveHint=false annotations.
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 long but information-dense, front-loading the core purpose before diving into optional compilation behavior and return envelope details. A little redundancy exists with schema content (e.g., 'Set build_gma to true (default false) to trigger .gma compilation'), but the overall structure is logically ordered and every section earns its place given the tool's dual validation/packaging nature.
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?
The description covers what the tool validates, when to use it, when compilation is triggered, prerequisites, defaults, sibling alternatives, and the return envelope structure. Given the schema and annotations also present, an agent has everything needed to decide whether to call this tool and what to expect from it.
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?
Schema description coverage is 100%, so the baseline is 3. The description does restate parameter defaults and semantics, but the input schema already documents addon_dir, build_gma, and output_gma_path thoroughly. The description adds only mild extra context around the zero-illegal-files condition and external executable requirement, not enough to raise the score further.
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 names a specific verb ('Verify') and a concrete resource ('a Garry's Mod addon directory') against official Steam Workshop and GMA packaging rules. It also explicitly scopes the optional compile behavior, making the tool's dual validation/packaging role unambiguous and distinguishable from siblings like lint_glua and scaffold_gmod_component.
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?
The description gives direct placement guidance: 'Use this tool as the final verification gate before uploading addons to the Steam Workshop or deploying to a dedicated server.' It also names sibling tools as alternatives for adjacent jobs ('Use scaffold_gmod_component to bootstrap addon structures, and lint_glua/audit_net_security to audit code quality prior to packaging'), making the selection boundary explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Generate production-grade, realm-separated Garry's Mod boilerplate code for 10 standard component architectures: SWEP (weapons), SENT (scripted entities), nextbot (NextBot AI with pathfinding coroutines), custom_tool (toolgun STOOLs with CPanel), vgui_panel (Derma UI), hud (Zero-GC HUDPaint overlays), gamemode (GM framework), effect (dynamic particle render effects), darkrp_module (DarkRP jobs, shipments, categories), and addon_skeleton (standard directory layout with addon.json). Dual operational mode: when output_dir is omitted (default), operates as a zero-side-effect preview returning a virtual code_manifest without touching the disk; when output_dir is provided, writes files directly to disk relative to workspace, creating directories and overwriting existing files at target paths. Implements idiomatic realm separation (e.g. server init.lua, client cl_init.lua with AddCSLuaFile headers, shared.lua). Requires component_type (enum: 'swep', 'sent', 'nextbot', 'custom_tool', 'vgui_panel', 'hud', 'gamemode', 'effect', 'darkrp_module', 'addon_skeleton') and alphanumeric identifier name (e.g. 'weapon_plasma_rifle', 'nb_stalker', 'tool_remover'). Optional output_dir designates target folder on disk. Optional options object configures category, base class, author, printable_name, and vgui_type ('frame', 'button', 'scroll', 'custom'). Use this tool when bootstrapping new Garry's Mod addons, weapons, entities, AI nextbots, STOOLs, or UI panels with idiomatic architecture and prediction support. Do NOT use for editing existing code or linting (use lint_glua). After scaffolding, use package_and_validate to verify Steam Workshop packaging compliance. Returns a GModToolResult envelope with status ('success' or 'failed'), summary, and data containing component_type, files_created array (path, purpose), and code_manifest mapping relative file paths to generated Lua source code strings.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique technical identifier for the component (e.g. 'weapon_plasma_rifle', 'ent_crate', 'vgui_scoreboard', 'tool_remover'). Must be alphanumeric with underscores or dashes. | |
| options | No | Optional metadata configuring component inheritance, display names, and base classes. | |
| output_dir | No | Optional workspace destination directory. If omitted, files are NOT written to disk and only returned in code_manifest (preview mode). If provided, files are written to disk relative to workspace, creating folders as needed and overwriting existing files at those paths. | |
| component_type | Yes | The architectural Garry's Mod component type to scaffold ('swep', 'sent', 'nextbot', 'custom_tool', 'vgui_panel', 'hud', 'gamemode', 'effect', 'darkrp_module', or 'addon_skeleton'). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that when output_dir is provided, it 'writes files directly to disk... overwriting existing files at target paths.' This is a destructive behavior, yet the annotation declares destructiveHint=false. This is a direct contradiction, which must be flagged. The description otherwise provides rich behavioral detail (dual mode, preview vs write), but the contradiction makes it misleading.
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 long but efficiently structured: purpose first, then operational mode, then parameter details, then usage guidance and post-scaffolding steps. Every sentence adds new information—no redundancy. Front-loading the component list and dual-mode behavior ensures critical decisions are made early.
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 complexity (4 params, nested options, 10 component types, dual modes) and the presence of an output schema, the description covers all necessary aspects: what it generates, how to control output, parameter constraints, usage boundaries, and return envelope. No critical detail is missing.
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 input schema already has 100% coverage, but the description goes well beyond by explaining the meaning of each parameter: component_type enum values, alphanumeric name requirements with examples, output_dir's preview vs write semantics, and options object fields with example values. It adds contextual meaning that helps an agent choose appropriate values without opening the schema.
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 clearly states a specific verb ('Generate') and resource ('Garry's Mod boilerplate code') with a comprehensive list of 10 component architectures. It distinguishes itself from siblings by explicitly naming lint_glua and package_and_validate as alternatives for editing/linting and verification respectively.
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?
Provides explicit guidance: 'Use this tool when bootstrapping new Garry's Mod addons... Do NOT use for editing existing code or linting (use lint_glua).' It also chains the workflow by recommending package_and_validate after scaffolding. This leaves no ambiguity about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the official Facepunch Garry's Mod Wiki and indexed API reference by keyword or conceptual topic across functions, hooks, libraries, panels, and enums. Read-only operation with zero side effects, no authentication required, and cached offline-first execution with live documentation fallback; does NOT modify the workspace. Requires a query string. Optionally filter by category ('functions', 'hooks', 'libraries', 'panels', 'enums', 'all', default 'all'), realm ('server', 'client', 'shared', 'menu', 'all', default 'all'), and max_results (1 to 20, default 5). Use this tool for broad discovery, conceptual exploration, or finding candidate APIs when the exact symbol name is unknown. Do NOT use if you already know the exact function or hook identifier (use get_gmod_symbol instead for complete signatures, argument specifications, caveats, and official examples). Do NOT use for third-party libraries, community forum solutions, or undocumented engine quirks (use web_search_glua instead). Returns a GModToolResult envelope with status ('success' or 'failed'), summary, and data containing query, category, realm, total_matches, and an array of matching results (title, canonical wiki_url, realm, summary, signature, category).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term, concept keyword, or partial identifier (e.g. 'net.Receive', 'PlayerInitialSpawn', 'DScrollPanel', 'draw.RoundedBox'). | |
| realm | No | Filter documentation by execution realm ('server', 'client', 'shared', 'menu', or 'all'). | all |
| category | No | Filter search results by documentation category ('functions', 'hooks', 'libraries', 'panels', 'enums', or 'all'). | all |
| max_results | No | Maximum number of documentation matches to return (integer between 1 and 20, default is 5). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds substantive context beyond that: no authentication required, cached offline-first execution with live fallback, and explicit confirmation that the workspace is not modified. The description aligns perfectly with the annotations.
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 dense but well-organized: it leads with the core operation and safety profile, then parameters, then usage boundaries, then return envelope. Every sentence provides actionable guidance, and the 'when not to use' statements are immediate and unambiguous.
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?
For a search tool with an output schema, annotations, and clear siblings, the description covers everything an agent needs: the operation, filters, the exact conditions for choosing alternatives, behavioral guarantees, and the return envelope. There are no meaningful gaps for correct invocation.
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?
Schema coverage is 100%, so the schema already documents all four parameters, their types, defaults, constraints, and enums. The description adds a little context by framing them as optional filters and gives a clear query-example list, but it mostly restates schema information, which is acceptable but not additive.
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 states a specific verb ('Query'), a precise resource ('official Facepunch Garry's Mod Wiki and indexed API reference'), and the scope ('functions, hooks, libraries, panels, and enums'). It clearly distinguishes this tool from siblings by positioning it as the broad-discovery search tool rather than the exact-symbol lookup or community-web-search tool.
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?
The description gives explicit when-to-use guidance ('broad discovery, conceptual exploration, or finding candidate APIs when the exact symbol name is unknown') and explicit when-not-to-use guidance with named alternatives: get_gmod_symbol for known identifiers and web_search_glua for third-party or community content. No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search external Garry's Mod developer communities, GitHub repositories, Facepunch archives, Reddit, and Steam Community forums for community-developed solutions, workarounds, and undocumented engine behaviors. Read-only external web search with open-world egress; requires no credentials and produces zero local file mutations or state modifications. Requires a query string. Optionally filter target domains with domain_filter ('github', 'facepunch', 'reddit', 'steam', 'all', default 'all') and limit results with max_results (1 to 10, default 5). Use this tool for troubleshooting obscure runtime bugs, researching community conventions, finding GitHub code implementations, or resolving undocumented engine quirks where official documentation is silent. Do NOT use for official Garry's Mod API reference, hook signatures, or standard library documentation (use get_gmod_symbol for exact lookups or search_gmod_wiki for topic searches). Returns a GModToolResult envelope with status ('success' or 'failed'), summary, and data containing query and results array (title, destination url, snippet, source platform).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query targeting Garry's Mod developer topics, error messages, or code patterns (e.g. 'GM:SetupMove prediction stutter', 'DarkRP custom job HUD'). | |
| max_results | No | Maximum number of community search results to return (integer between 1 and 10, default is 5). | |
| domain_filter | No | Restricts search results to specific developer community platforms ('github', 'facepunch', 'reddit', 'steam', or 'all'). | all |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond those: 'requires no credentials and produces zero local file mutations or state modifications,' plus the exact return envelope with success/failed status. No contradiction exists.
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 front-loaded with the core purpose, followed by usage guidance, exclusions, and return format. It is slightly redundant with annotations and the output schema, but every sentence earns its place and the overall structure is easy to scan.
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?
For a read-only external search tool with robust annotations, full parameter schema coverage, and an output schema, the description is complete. It covers purpose, invocation requirements, optional parameters, when to use and avoid the tool, alternative tools, and the result envelope shape, leaving no meaningful gap for an agent to call it correctly.
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?
Schema description coverage is 100%, and the schema already defines query, max_results, and domain_filter with defaults and constraints. The description recaps these parameter names and defaults but adds little new semantic meaning beyond what the schema provides, so baseline 3 is appropriate.
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 states a specific verb and resource: 'Search external Garry's Mod developer communities, GitHub repositories, Facepunch archives, Reddit, and Steam Community forums.' It also differentiates from siblings by explicitly saying it is not for official API reference, hook signatures, or standard library documentation, directing those cases to get_gmod_symbol and search_gmod_wiki.
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 explicitly lists when to use the tool: troubleshooting obscure runtime bugs, researching community conventions, finding GitHub code implementations, and resolving undocumented engine quirks. It also gives clear negative guidance with named alternatives, so an agent can confidently choose between web_search_glua and the official-doc tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_performance3 fields changedInput schema / properties / code_content / descriptionPrevious value: -"Direct Lua code snippet"New value: +"Direct GLua source code snippet to profile. Ignored if file_path is provided."Input schema / properties / file_path / descriptionPrevious value: -"Workspace path to .lua file"New value: +"Workspace path to .lua file to profile. Takes precedence over code_content when both are supplied."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Domain-specific typed payload returned by the tool.",
+ "properties": {
+ "issues": {
+ "description": "Detected hot-path performance bottlenecks and memory allocation traps.",
+ "items": {
+ "properties": {
+ "category": {
+ "description": "Category of performance defect.",
+ "enum": [
+ "allocation_in_render_hook",
+ "uncached_material",
+ "uncached_font",
+ "unlocalized_globals",
+ "expensive_entity_iteration"
+ ],
+ "type": "string"
+ },
+ "description": {
+ "description": "Explanation of why this causes GC pressure or FPS drops.",
+ "type": "string"
+ },
+ "hook_name": {
+ "description": "Hook where issue occurred (e.g. 'HUDPaint', 'Think', 'RenderScreenspaceEffects').",
+ "type": "string"
+ },
+ "line": {
+ "description": "1-based line number.",
+ "type": "integer"
+ },
+ "recommended_code": {
+ "description": "Optimized replacement code pattern with pre-allocated tables.",
+ "type": "string"
+ },
+ "severity": {
+ "description": "Severity of performance impact.",
+ "enum": [
+ "critical",
+ "high",
+ "medium"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "hook_name",
+ "line",
+ "severity",
+ "category",
+ "description",
+ "recommended_code"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "metrics": {
+ "description": "Detailed profiling metrics for the analyzed snippet.",
+ "properties": {
+ "allocations_in_hot_path": {
+ "description": "Number of Color/Vector/Angle allocations inside per-frame hooks.",
+ "type": "integer"
+ },
+ "dynamic_draw_calls": {
+ "description": "Dynamic font or material creation calls in hot paths.",
+ "type": "integer"
+ },
+ "global_calls_in_hot_path": {
+ "description": "Unlocalized global calls inside per-frame hooks.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "allocations_in_hot_path",
+ "global_calls_in_hot_path",
+ "dynamic_draw_calls"
+ ],
+ "type": "object"
+ },
+ "performance_score": {
+ "description": "Performance score out of 100 based on GC and call penalties.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "performance_score",
+ "issues",
+ "metrics"
+ ],
+ "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"
+}audit_net_security3 fields changedInput schema / properties / addon_dir / descriptionPrevious value: -"Root directory of addon (defaults to workspace)"New value: +"Root directory of the Garry's Mod addon to audit. Defaults to current workspace root if omitted."Input schema / properties / file_paths / descriptionPrevious value: -"Specific files to scan"New value: +"Optional list of specific relative or absolute Lua file paths within addon_dir to audit. If omitted, recursively scans all Lua files in addon_dir."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Domain-specific typed payload returned by the tool.",
+ "properties": {
+ "addon_dir": {
+ "description": "Addon root directory audited.",
+ "type": "string"
+ },
+ "messages_found": {
+ "description": "Total distinct net messages discovered in the AST.",
+ "type": "integer"
+ },
+ "network_graph": {
+ "description": "Cross-realm messaging graph mapping transmitters to receivers.",
+ "items": {
+ "properties": {
+ "data_types": {
+ "description": "Inferred payload bitstream types (e.g. 'String', 'UInt').",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "has_auth_check": {
+ "description": "True if receiver validates caller permissions.",
+ "type": "boolean"
+ },
+ "message": {
+ "description": "Network message identifier.",
+ "type": "string"
+ },
+ "received_in": {
+ "description": "Receiving realm.",
+ "enum": [
+ "client",
+ "server",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "registered_on_server": {
+ "description": "True if registered via util.AddNetworkString on server.",
+ "type": "boolean"
+ },
+ "sent_from": {
+ "description": "Transmitting realm.",
+ "enum": [
+ "client",
+ "server",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "message",
+ "sent_from",
+ "received_in",
+ "has_auth_check",
+ "registered_on_server",
+ "data_types"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "registered_strings": {
+ "description": "Network strings registered via util.AddNetworkString.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "vulnerabilities": {
+ "description": "Identified networking security vulnerabilities and exploitable handlers.",
+ "items": {
+ "properties": {
+ "description": {
+ "description": "Analysis of the vulnerability and attack vector.",
+ "type": "string"
+ },
+ "file": {
+ "description": "Relative file path where the issue occurs.",
+ "type": "string"
+ },
+ "line": {
+ "description": "Line number of the vulnerable receiver.",
+ "type": "integer"
+ },
+ "message_name": {
+ "description": "Identifier of the net message (e.g. 'AdminNuke').",
+ "type": "string"
+ },
+ "recommended_fix": {
+ "description": "Code remediation instructions.",
+ "type": "string"
+ },
+ "severity": {
+ "description": "Exploitation severity rating.",
+ "enum": [
+ "critical",
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "type": {
+ "description": "Vulnerability classification.",
+ "enum": [
+ "unauthenticated_net_receiver",
+ "missing_network_string",
+ "sql_injection",
+ "runstring_exposure",
+ "bitstream_mismatch",
+ "unbounded_payload"
+ ],
+ "type": "string"
+ },
+ "vulnerable_code": {
+ "description": "Vulnerable code snippet.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "severity",
+ "type",
+ "message_name",
+ "file",
+ "line",
+ "description",
+ "recommended_fix"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "messages_found",
+ "registered_strings",
+ "vulnerabilities"
+ ],
+ "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"
+}get_gmod_symbol4 fields changedInput schema / properties / include_examples / descriptionPrevious value: -"Include official usage examples"New value: +"Whether to include official Lua code usage examples in the response (default is true; set false to reduce token payload)."Input schema / properties / symbol / descriptionPrevious value: -"Exact symbol name (e.g. 'surface.DrawPoly', 'util.AddNetworkString')"New value: +"Exact case-sensitive or standard Garry's Mod symbol name (e.g. 'util.AddNetworkString', 'net.Receive', 'GM:PlayerInitialSpawn', 'surface.DrawPoly', 'Entity:TakeDamage')."Input schema / properties / symbol / minLengthAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Domain-specific typed payload returned by the tool.",
+ "properties": {
+ "arguments": {
+ "description": "Function arguments with types, optionality, defaults, and descriptions.",
+ "items": {
+ "properties": {
+ "default": {
+ "description": "Default value if omitted.",
+ "type": "string"
+ },
+ "description": {
+ "description": "Description of the parameter's role.",
+ "type": "string"
+ },
+ "name": {
+ "description": "Parameter name.",
+ "type": "string"
+ },
+ "optional": {
+ "description": "True if parameter is optional.",
+ "type": "boolean"
+ },
+ "type": {
+ "description": "GMod type (e.g. 'string', 'Player', 'number', 'table').",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "type",
+ "optional",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "description": {
+ "description": "Official documentation description.",
+ "type": "string"
+ },
+ "examples": {
+ "description": "Official usage examples with runnable GLua code snippets.",
+ "items": {
+ "properties": {
+ "code": {
+ "description": "GLua example code.",
+ "type": "string"
+ },
+ "title": {
+ "description": "Example title or scenario.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "code"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "notes": {
+ "description": "Implementation notes and tips.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "realm": {
+ "description": "Execution realm affinity.",
+ "enum": [
+ "server",
+ "client",
+ "shared",
+ "menu"
+ ],
+ "type": "string"
+ },
+ "returns": {
+ "description": "Return values with types and descriptions.",
+ "items": {
+ "properties": {
+ "description": {
+ "description": "Description of what is returned.",
+ "type": "string"
+ },
+ "name": {
+ "description": "Return value identifier.",
+ "type": "string"
+ },
+ "type": {
+ "description": "Return type.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "type",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "symbol": {
+ "description": "Exact Garry's Mod symbol identifier.",
+ "type": "string"
+ },
+ "warnings": {
+ "description": "Engine caveats, edge cases, and known pitfalls.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "wiki_url": {
+ "description": "Canonical Facepunch Garry's Mod wiki URL.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "symbol",
+ "realm",
+ "description",
+ "arguments",
+ "returns",
+ "examples",
+ "notes",
+ "warnings",
+ "wiki_url"
+ ],
+ "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"
+}lint_glua5 fields changedInput schema / properties / code_content / descriptionPrevious value: -"Direct Lua code string to analyze (if file_path omitted)"New value: +"Direct GLua source code string to analyze statically. Used when file_path is omitted."Input schema / properties / file_path / descriptionPrevious value: -"Workspace-relative or absolute path to .lua file"New value: +"Workspace-relative or absolute path to .lua file to lint. Takes precedence over code_content when both are provided."Input schema / properties / fix_formatting / descriptionPrevious value: -"Auto-fix code if possible"New value: +"When true, runs glualint auto-fixer and returns formatted_code in the result data without mutating or overwriting the file on disk (default is false)."Input schema / properties / target_realm / descriptionPrevious value: -"Target realm context"New value: +"Target execution realm context for static analysis ('server', 'client', 'shared', 'menu', or 'auto'). 'auto' infers realm from filename conventions (sv_, cl_, sh_) or defaults to 'shared'."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Domain-specific typed payload returned by the tool.",
+ "properties": {
+ "diagnostics": {
+ "description": "Detailed list of static analysis findings with line coordinates and remediation suggestions.",
+ "items": {
+ "properties": {
+ "code": {
+ "description": "Diagnostic rule identifier (e.g. 'GLUALINT', 'REALM_MISMATCH', 'GLOBAL_POLLUTION').",
+ "type": "string"
+ },
+ "column": {
+ "description": "1-based column number.",
+ "type": "integer"
+ },
+ "line": {
+ "description": "1-based line number.",
+ "type": "integer"
+ },
+ "message": {
+ "description": "Explanation of the syntax or realm violation.",
+ "type": "string"
+ },
+ "severity": {
+ "description": "Issue severity level.",
+ "enum": [
+ "error",
+ "warning",
+ "info"
+ ],
+ "type": "string"
+ },
+ "suggestion": {
+ "description": "Recommended remediation or code replacement.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "line",
+ "column",
+ "severity",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error_count": {
+ "description": "Total count of fatal syntax, parsing, and realm boundary errors.",
+ "type": "integer"
+ },
+ "formatted_code": {
+ "description": "Pretty-printed code if fix_formatting was enabled (the original file on disk is never modified).",
+ "type": "string"
+ },
+ "realm_detected": {
+ "description": "Effective execution realm evaluated.",
+ "enum": [
+ "server",
+ "client",
+ "shared",
+ "menu"
+ ],
+ "type": "string"
+ },
+ "valid": {
+ "description": "True if code passed static analysis with zero errors.",
+ "type": "boolean"
+ },
+ "warning_count": {
+ "description": "Total count of style, global pollution, and non-fatal hygiene warnings.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "valid",
+ "error_count",
+ "warning_count",
+ "realm_detected",
+ "diagnostics"
+ ],
+ "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"
+}package_and_validate4 fields changedInput schema / properties / addon_dir / descriptionPrevious value: -"Root directory of addon (defaults to workspace)"New value: +"Root directory of the Garry's Mod addon to inspect and validate. Defaults to current workspace root if omitted."Input schema / properties / build_gma / descriptionPrevious value: -"Compile .gma package if gmad is available"New value: +"When true and validation succeeds with 0 illegal files, invokes gmad to compile a .gma binary archive. Requires GMAD_PATH environment variable (default is false)."Input schema / properties / output_gma_path / descriptionPrevious value: -"Destination path for .gma"New value: +"Destination file path for the compiled .gma file. Defaults to '<addon_dir>/out.gma' if build_gma is true and this is omitted."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Domain-specific typed payload returned by the tool.",
+ "properties": {
+ "addon_json_valid": {
+ "description": "True if addon.json exists and strictly satisfies Workshop schema.",
+ "type": "boolean"
+ },
+ "gma_path": {
+ "description": "Destination path of the compiled .gma package if build_gma was true and successful.",
+ "type": "string"
+ },
+ "illegal_files": {
+ "description": "Files rejected by Steam Workshop gmad whitelist rules.",
+ "items": {
+ "properties": {
+ "path": {
+ "description": "Relative file path.",
+ "type": "string"
+ },
+ "reason": {
+ "description": "Reason for rejection (e.g. disallowed extension, binary payload).",
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total_files": {
+ "description": "Total file count inspected in addon directory.",
+ "type": "integer"
+ },
+ "total_size_bytes": {
+ "description": "Total uncompressed size of all addon files in bytes.",
+ "type": "integer"
+ },
+ "valid": {
+ "description": "True if addon passes all Steam Workshop rules and contains no illegal files.",
+ "type": "boolean"
+ },
+ "warnings": {
+ "description": "Validation warnings such as uppercase filenames breaking Linux servers.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "valid",
+ "addon_json_valid",
+ "total_files",
+ "total_size_bytes",
+ "illegal_files",
+ "warnings"
+ ],
+ "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"
+}run_glua_test7 fields changedInput schema / properties / code_to_test / descriptionPrevious 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."Input schema / properties / mock_realm / descriptionAdded value: +"Source engine execution realm environment to simulate ('client', 'server', or 'shared'). Controls SERVER and CLIENT boolean constants and realm-restricted mock libraries."Input schema / properties / test_file_path / descriptionPrevious value: -"Workspace path to test script"New value: +"Workspace path to test script file. Takes precedence over code_to_test when both are provided."Input schema / properties / timeout_ms / descriptionPrevious 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)."Input schema / properties / timeout_ms / maximumAdded value: +30000Input schema / properties / timeout_ms / minimumAdded value: +500Output 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"
+}scaffold_gmod_component12 fields changedInput schema / properties / component_type / descriptionPrevious value: -"Type of Garry's Mod component to scaffold"New value: +"The architectural Garry's Mod component type to scaffold ('swep', 'sent', 'nextbot', 'custom_tool', 'vgui_panel', 'hud', 'gamemode', 'effect', 'darkrp_module', or 'addon_skeleton')."Input schema / properties / component_type / enumPrevious value: -[
- "swep",
- "sent",
- "vgui_panel",
- "custom_tool",
- "hud",
- "gamemode",
- "addon_skeleton"
-]New value: +[
+ "swep",
+ "sent",
+ "nextbot",
+ "custom_tool",
+ "vgui_panel",
+ "hud",
+ "gamemode",
+ "effect",
+ "darkrp_module",
+ "addon_skeleton"
+]Input schema / properties / name / descriptionPrevious value: -"Identifier (e.g. 'weapon_plasma_rifle', 'ent_crate')"New value: +"Unique technical identifier for the component (e.g. 'weapon_plasma_rifle', 'ent_crate', 'vgui_scoreboard', 'tool_remover'). Must be alphanumeric with underscores or dashes."Input schema / properties / name / minLengthAdded value: +1Input schema / properties / options / descriptionAdded value: +"Optional metadata configuring component inheritance, display names, and base classes."Input schema / properties / options / properties / author / descriptionAdded value: +"Author name embedded into file headers and metadata."Input schema / properties / options / properties / base / descriptionAdded value: +"Base class to inherit from (e.g. 'weapon_base', 'base_anim')."Input schema / properties / options / properties / category / descriptionAdded value: +"Spawnmenu category (e.g. 'Custom Weapons', 'Fun + Games')."Input schema / properties / options / properties / printable_name / descriptionAdded value: +"User-facing UI name displayed in spawnmenu and HUD."Input schema / properties / options / properties / vgui_type / descriptionAdded value: +"Derma UI base template when scaffolding a vgui_panel ('frame', 'button', 'scroll', or 'custom')."Input schema / properties / output_dir / descriptionPrevious value: -"Workspace folder to write generated files to"New value: +"Optional workspace destination directory. If omitted, files are NOT written to disk and only returned in code_manifest (preview mode). If provided, files are written to disk relative to workspace, creating folders as needed and overwriting existing files at those paths."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Domain-specific typed payload returned by the tool.",
+ "properties": {
+ "code_manifest": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Key-value map of relative file path to generated boilerplate GLua code.",
+ "type": "object"
+ },
+ "component_type": {
+ "description": "The scaffolded component architecture.",
+ "enum": [
+ "swep",
+ "sent",
+ "vgui_panel",
+ "custom_tool",
+ "hud",
+ "gamemode",
+ "addon_skeleton"
+ ],
+ "type": "string"
+ },
+ "files_created": {
+ "description": "List of files scaffolded on disk or generated in manifest.",
+ "items": {
+ "properties": {
+ "path": {
+ "description": "Relative file path in Garry's Mod addon structure.",
+ "type": "string"
+ },
+ "purpose": {
+ "description": "Role of this file (e.g. 'Server init script', 'Shared weapon logic').",
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "purpose"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "component_type",
+ "files_created",
+ "code_manifest"
+ ],
+ "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"
+}search_gmod_wiki6 fields changedInput schema / properties / category / descriptionPrevious value: -"Filter search by category"New value: +"Filter search results by documentation category ('functions', 'hooks', 'libraries', 'panels', 'enums', or 'all')."Input schema / properties / max_results / descriptionPrevious value: -"Max results to return"New value: +"Maximum number of documentation matches to return (integer between 1 and 20, default is 5)."Input schema / properties / query / descriptionPrevious value: -"Search term (e.g. 'net.Receive', 'GM:PlayerInitialSpawn')"New value: +"Search term, concept keyword, or partial identifier (e.g. 'net.Receive', 'PlayerInitialSpawn', 'DScrollPanel', 'draw.RoundedBox')."Input schema / properties / query / minLengthAdded value: +1Input schema / properties / realm / descriptionPrevious value: -"Filter by execution realm"New value: +"Filter documentation by execution realm ('server', 'client', 'shared', 'menu', or 'all')."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Domain-specific typed payload returned by the tool.",
+ "properties": {
+ "category": {
+ "description": "Category filter applied to search.",
+ "type": "string"
+ },
+ "query": {
+ "description": "The search query that was executed.",
+ "type": "string"
+ },
+ "realm": {
+ "description": "Realm filter applied to search.",
+ "type": "string"
+ },
+ "results": {
+ "description": "Matched Garry's Mod documentation entries with signatures and realm annotations.",
+ "items": {
+ "properties": {
+ "category": {
+ "description": "Documentation category (e.g. 'functions', 'hooks').",
+ "type": "string"
+ },
+ "realm": {
+ "description": "Execution realm affinity.",
+ "enum": [
+ "server",
+ "client",
+ "shared",
+ "menu"
+ ],
+ "type": "string"
+ },
+ "signature": {
+ "description": "Full calling signature (e.g. 'net.Receive(string messageName, function callback)').",
+ "type": "string"
+ },
+ "summary": {
+ "description": "Brief official summary of the function, hook, or panel.",
+ "type": "string"
+ },
+ "title": {
+ "description": "Symbol or article title (e.g. 'net.Receive').",
+ "type": "string"
+ },
+ "url": {
+ "description": "Canonical Facepunch Garry's Mod wiki URL.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "url",
+ "realm",
+ "summary",
+ "signature",
+ "category"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total_matches": {
+ "description": "Total count of matching Garry's Mod wiki documentation entries found.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "query",
+ "category",
+ "realm",
+ "total_matches",
+ "results"
+ ],
+ "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"
+}web_search_glua5 fields changedInput schema / properties / domain_filter / descriptionPrevious value: -"Target community platform"New value: +"Restricts search results to specific developer community platforms ('github', 'facepunch', 'reddit', 'steam', or 'all')."Input schema / properties / max_results / descriptionPrevious value: -"Max results"New value: +"Maximum number of community search results to return (integer between 1 and 10, default is 5)."Input schema / properties / query / descriptionPrevious value: -"Target query"New value: +"Search query targeting Garry's Mod developer topics, error messages, or code patterns (e.g. 'GM:SetupMove prediction stutter', 'DarkRP custom job HUD')."Input schema / properties / query / minLengthAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "Domain-specific typed payload returned by the tool.",
+ "properties": {
+ "query": {
+ "description": "The community search query executed.",
+ "type": "string"
+ },
+ "results": {
+ "description": "Community forum, GitHub, and workshop search results with relevant code snippets.",
+ "items": {
+ "properties": {
+ "snippet": {
+ "description": "Relevant code excerpt, error explanation, or discussion snippet.",
+ "type": "string"
+ },
+ "source": {
+ "description": "Source platform ('github', 'facepunch', 'reddit', 'steam', or 'web').",
+ "type": "string"
+ },
+ "title": {
+ "description": "Post, thread, or repository title.",
+ "type": "string"
+ },
+ "url": {
+ "description": "Destination link.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "url",
+ "snippet",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "query",
+ "results"
+ ],
+ "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"
+}v1.0.0analyze_performanceaudit_net_securityget_gmod_symbollint_gluapackage_and_validaterun_glua_testscaffold_gmod_componentsearch_gmod_wikiweb_search_gluaScored across 9 tools
Each tool has a clearly distinct primary purpose, and cross-references between similar tools (get vs search, lint vs audit vs analyze) are explicit. However, the three static analyzers (lint_glua, audit_net_security, analyze_performance) all operate on code and return diagnostic-like results, which could lead to misselection if an agent requests a generic 'check my code' without specifying the concern.
All tool names are lowercase snake_case and start with a verb (get, web_search, lint, search, audit, analyze, scaffold, run, package), creating a generally consistent pattern. Minor deviations exist: web_search_glua and search_gmod_wiki both express search but with different word order and prefixes, and the glua suffix is inconsistently placed (web_search_glua, lint_glua, run_glua_test).
Nine tools is well within the ideal 3-15 range and maps neatly to a GMod addon development workflow: documentation lookup, community search, three distinct code quality checks, scaffolding, testing, and packaging. Each tool earns its place with a specific function, and none feel redundant or padding.
The tool set covers the full addon development lifecycle: discover APIs (get, search), research community solutions (web search), write/analyze code (scaffold, lint, audit, analyze), test (run_glua_test), and package (package_and_validate). There are no dead ends or obvious missing operations for the stated domain of Garry's Mod addon development.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
