Click on "Install 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., "@DayZ API MCP Server Search for weapon crafting methods"
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 (Model Context Protocol) server for DayZ Enforce Script. Gives any AI coding assistant deep knowledge of the DayZ scripting API — semantic search across 5800+ vanilla classes, code validation, class hierarchy, reverse call graphs, and more.
Tool | Description |
| Semantic / exact / fuzzy search across 25 000+ methods |
| Full signature, parameters, body, and related functions |
| Real usage examples from vanilla scripts |
| Inheritance tree and modded extensions |
| Reverse call graph — who calls a given method |
| Enforce Script Iron Rules checker (ternary, try/catch, casts, etc.) |
| Suggests vanilla API for custom code |
| Parse Enforce Script and extract AST |
Related MCP server: lake-dayz
git clone https://github.com/quantumloader/dayz-api-mcp-server.git
cd dayz-api-mcp-server
npm install
npm run buildPoint to your DayZ Tools script dump (usually extracted via DayZ Tools):
# Index all layers (1_Core through 5_Mission)
node dist/indexer/index-cli.js index P:/scripts
# Or use the batch file
Index-All-Scripts.batOutput: data/index.json (~30 MB, 5800+ classes, 25000+ methods, 300+ enums).
Windsurf — add to MCP settings:
{
"mcpServers": {
"dayz-enforce": {
"command": "node",
"args": ["P:/enforce-mcp-dayz/dist/server/index.js"]
}
}
}Claude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"dayz-enforce": {
"command": "node",
"args": ["P:/enforce-mcp-dayz/dist/server/index.js"]
}
}
}Replace P:/enforce-mcp-dayz with your actual path.
src/
├── parser/
│ ├── token.ts # Token types
│ ├── rules.ts # Keywords, operators
│ ├── lexer.ts # Tokenizer with #ifdef/#endif support
│ └── EnforceScriptParser.ts # Token-based parser → ParsedClass/Method/Enum
├── indexer/
│ ├── Indexer.ts # Index interface
│ ├── FileSystemIndex.ts # TF-IDF index, reverse call graph, search
│ └── index-cli.ts # CLI: index / search / verify
├── validator/
│ └── CodeValidator.ts # Iron Rules validation engine
├── server/
│ ├── DayZMCP.ts # MCP server with all tools
│ └── index.ts # Entry point
└── types/
└── index.ts # Shared TypeScript types{ "query": "copy weapon attachments", "searchType": "semantic", "limit": 5 }searchType: semantic (default) — meaning-based, exact — name match, fuzzy — partial match.
{ "className": "EntityAI", "methodName": "CopyOldPropertiesToNew" }Returns signature, parameters, body source, file path, line number, and related functions.
{ "className": "DayZPlayerImplement", "methodName": "EEKilled" }Returns all call sites: caller class, method, file, and line.
{ "code": "string result = condition ? 'yes' : 'no';" }Checks for: ternary operator, try/catch, do-while, C-style casts, GetPlayer() on server, backslash in strings, vector literal format, missing SetSynchDirty(), and more.
{ "className": "PlayerBase", "methodName": "GetIdentity", "limit": 3 }{ "className": "PlayerBase" }Returns parent chain, children, and modded extensions.
{ "customCode": "for (int i = 0; i < player.GetInventory().GetCargo()..." }{ "code": "class MyClass extends ItemBase { ... }" }dayz://classes — list of all indexed classes
dayz://classes/{name} — class details with methods and variables
# Index scripts
node dist/indexer/index-cli.js index P:/scripts
# Search
node dist/indexer/index-cli.js search "handle weapons" --type semantic --limit 10
node dist/indexer/index-cli.js search HandleWeapons --type exact
# Verify index quality
node dist/indexer/index-cli.js verify --min-classes 1000The Enforce Script parser is based on the dfenscript lexer. Key capabilities:
Full #ifdef / #ifndef / #else / #endif support with nesting
All Enforce Script modifiers: override, proto, native, event, thread, sealed, abstract, final, etc.
Generic types (array<ref Widget>), destructors (~ClassName), operator overloads
Error recovery — skips broken declarations and continues parsing
Extracts method bodies for search indexing
MIT
Find who calls a specific method in vanilla DayZ scripts (reverse call graph)
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | Class name, e.g., "DayZPlayerImplement" | |
| methodName | Yes | Method name, e.g., "EEKilled" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only describes the tool as a 'reverse call graph' without disclosing performance, limitations, what happens if no callers are found, or the scope of scripts searched. Minimal behavioral disclosure.
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 a single sentence of 15 words, front-loaded with the verb and resource, and contains no unnecessary information. Every word contributes to clarity.
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 no output schema, the description should indicate what is returned (e.g., list of callers). It only states the purpose without describing the output format, leaving some ambiguity. Adequate for a simple tool but could be more complete.
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 clear descriptions for both 'className' and 'methodName'. The tool description adds no extra meaning beyond the schema, so baseline score of 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 clearly states the verb 'Find', the resource 'who calls a specific method', and specifies the domain 'vanilla DayZ scripts'. It also adds context 'reverse call graph', making the purpose distinct from siblings like 'find_usage_examples' and 'find_vanilla_alternative'.
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 implies usage for finding callers of a method, but does not explicitly state when to use this tool versus alternatives like 'find_usage_examples' or 'get_function_details'. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find real usage examples of a function from vanilla DayZ scripts
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | Class name | |
| methodName | Yes | Method name | |
| limit | No | Number of examples (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully inform about behavior. It only states a read-like operation but lacks details on scope (entire codebase?), performance, or output nature.
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?
A single sentence of 12 words, front-loaded with key information. No wasted words.
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?
Lacks explanation of return format (no output schema) and constraints like 'only vanilla scripts'. Adequate but not fully complete for a search tool.
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% with simple parameter descriptions. The tool description adds no additional meaning beyond the schema, 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 'Find real usage examples of a function from vanilla DayZ scripts' clearly states the tool's purpose with a specific verb and resource, and distinguishes it from sibling tools like find_callers or get_function_details.
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?
No explicit when-to-use or alternative guidance is provided. The description implies usage for obtaining examples but does not clarify when to choose this over siblings like search_function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if custom code has vanilla DayZ function alternative
| Name | Required | Description | Default |
|---|---|---|---|
| customCode | Yes | Your custom implementation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, what side effects exist, or any constraints. The action 'check' implies a read operation, but this is not explicitly stated.
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 a single, short sentence with no redundant information. It is concise, though it could be slightly more informative without losing brevity.
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 simple input schema and lack of output schema, the description is minimal. It fails to explain what constitutes a 'vanilla alternative', the expected format of customCode, or the nature of the response, leaving the agent underinformed.
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% for the single parameter 'customCode', with a basic description 'Your custom implementation'. The tool description adds no additional semantic value beyond the schema, achieving the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'check' with the resource 'custom code' and the goal 'vanilla DayZ function alternative', clearly stating what the tool does. It distinguishes itself from sibling tools like find_callers and find_usage_examples, but does not specify the output format.
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 provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent is left without context on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get class inheritance hierarchy and modded extensions
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | Class name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose permissions, error behavior (e.g., class not found), output format, or whether it returns entire hierarchy or just direct parent.
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?
Single sentence is appropriately front-loaded with the action. Every word is necessary, no redundancy.
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?
Lacks return value description, which is important since no output schema exists. The description is minimal but covers the basic purpose; however, it leaves ambiguity about what 'modded extensions' means and what the hierarchy looks like.
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% for the single parameter, so baseline is 3. The description adds no extra meaning beyond the schema's 'Class name', but it doesn't detract either.
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 the verb 'Get' and the resource 'class inheritance hierarchy and modded extensions', distinguishing it from sibling tools that focus on callers, usage, alternatives, etc.
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?
No guidance on when to use this tool versus alternatives like find_callers or find_vanilla_alternative. The description provides only purpose, no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific function including signature, parameters, and usage
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | Class name, e.g., "EntityAI" | |
| methodName | Yes | Method name, e.g., "CopyOldPropertiesToNew" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It merely states it 'gets detailed information,' implying a read operation, but does not disclose any behavioral traits such as whether it has side effects, authentication requirements, or rate limits. The description is too minimal for a tool with no annotation support.
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 a single sentence that is extremely concise, front-loaded with the purpose, and contains no filler. Every word is meaningful.
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 simple two-parameter tool without an output schema, the description provides adequate context by listing what the response includes (signature, parameters, usage). However, it does not specify the return format (e.g., JSON, text), which would be more complete.
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%, with clear parameter descriptions (e.g., className example 'EntityAI'). The description adds no additional meaning beyond the schema, 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 clearly states the tool retrieves detailed information about a specific function, including signature, parameters, and usage. This distinguishes it from sibling tools like find_callers (which finds callers) and find_usage_examples (which finds usage examples), as it focuses on the function's own details.
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 implies the tool is used when needing details of a specific function, but it does not explicitly state when to use it versus alternatives (e.g., find_callers for callers, find_usage_examples for usage patterns). No guidance is provided on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse Enforce Script code and extract classes, methods, enums
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Enforce Script code to parse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description carries full burden for behavioral disclosure. It only states the action but does not mention side effects, error behavior, or whether it is safe/read-only, leaving gaps in transparency.
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 a single, concise sentence with no wasted words, efficiently conveying the core action.
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 simple parse tool with one parameter and no output schema, the description is adequate but lacks details on the output format (e.g., a list of objects), which could be important for the agent.
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%, with one parameter described as 'Enforce Script code to parse'. The description adds no new meaning beyond the schema, so baseline 3 applies.
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 the verb 'Parse' and the resource 'Enforce Script code', and lists the extracted elements (classes, methods, enums), making it distinct from sibling tools like validate_code or search_function.
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?
No guidance is provided on when to use this tool vs alternatives (e.g., validate_code for validation, search_function for search). There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for functions in DayZ vanilla scripts by semantic description
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language description of what you need, e.g., "copy weapon attachments" | |
| searchType | No | Search type: semantic (default) for meaning, exact for pattern matching | |
| limit | No | Maximum results (1-20, default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose read-only nature, result format, or behavior for different search types (semantic, exact, fuzzy), leaving the agent without critical behavioral cues.
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 a single efficient sentence with no waste, but it could briefly mention the search type and limit parameters without becoming verbose.
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 omits output format, error handling, and does not fully cover the searchType and limit parameters even though schema coverage is complete; an agent may not know how to use the tool 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 coverage is 100%, so the baseline is 3. The description only restates the 'semantic description' already evident in the schema and does not add new meaning beyond the schema's parameter descriptions.
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 specifies the verb (search), resource (functions in DayZ vanilla scripts), and method (by semantic description), clearly differentiating it from sibling tools that focus on callers, usage examples, or code validation.
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?
No guidance is provided on when to use this tool versus siblings like find_callers or find_vanilla_alternative, nor are any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate Enforce Script code against Iron Rules and check for common mistakes
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Enforce Script code to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the validation intent but omits details on output format, side effects, or error behavior. The agent cannot infer what it will receive.
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?
Single sentence, no wasted words, front-loaded with the core action. Every word 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?
For a validation tool with one parameter and no output schema, the description should at least hint at what the output is (e.g., pass/fail, list of errors). It omits this, leaving the agent uncertain about the return value.
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% and the schema already describes the 'code' parameter as 'Enforce Script code to validate'. The description adds no extra meaning beyond the schema, meeting the baseline.
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 the tool's function: validating Enforce Script code against 'Iron Rules' and checking for common mistakes. This distinguishes it from siblings like 'parse_script' or 'search_function'.
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?
No guidance is provided on when to use this tool versus alternatives. The description implies its purpose but does not specify exclusions or mention similar tools like 'parse_script' for comparison.
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. Dates show when Glama detected each change.
v1.0.0find_callersfind_usage_examplesfind_vanilla_alternativeget_class_hierarchyget_function_detailsparse_scriptsearch_functionvalidate_codeEach tool has a distinct and clearly defined purpose, such as finding callers, usage examples, or validating code, with minimal overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.
With 8 tools, the set is well-scoped for the domain of DayZ scripting API exploration, covering essential operations without unnecessary bloat.
The tool set covers a comprehensive range of actions including searching, parsing, validating, and retrieving details about functions and classes, with no obvious gaps for the intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/quantumloader/dayz-api-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
