Skip to main content
Glama

Mikes Moose MCP

This is a helper that makes AI assistants (like Cline, Claude, or Cursor) much better at writing mission scripts for DCS World using the MOOSE framework. It works by giving the AI accurate, up-to-date information about MOOSE — so it stops guessing and starts writing code that actually runs.


What problem does it solve?

AI models are trained on internet data, and their knowledge of MOOSE is often out of date or just wrong. They might use a class that no longer exists, call a method with the wrong name, or write Lua that won't work in DCS.

This helper solves that by handing the AI a 10-megabyte reference manual it can dip into, without ever loading the whole thing. It's the difference between asking a friend who "kind of remembers" MOOSE, and handing them a book that's open to exactly the right page. Instead of relying on its memory, the AI can ask the helper:

  • "What methods does the SPAWN class have?"

  • "How do I schedule something to happen every 30 seconds?"

  • "Is this code I wrote valid MOOSE?"

  • "What group names are actually in my mission file?"

  • "Why did my script error out?"

The helper answers with small, precise facts pulled from your actual MOOSE files — not from the AI's fuzzy memory. The trick that makes this possible is that the 10 MB file is parsed once into a searchable index, and the AI only ever sees the little slice it asks for. Which raises the obvious question: how does that not obliterate the AI's (small) working memory? Read on.


Related MCP server: llms-mcp

Why a 10 MB file doesn't blow your AI's context window

This is the single most important idea in the whole project, so it's worth spelling out.

An AI assistant talks to you using a limited "working memory" called the context window — a budget of tokens (roughly, chunks of text) it can hold and reason over at once. MOOSE's main file is about 10 MB of Lua and documentation — far more than fits in that window. If you just pasted the whole file, you'd instantly blow the budget and the AI would stop working.

So this helper never sends the whole file to the AI. Instead:

  1. Parsed once, indexed forever. When you install, the helper reads the 10 MB Moose.lua, breaks it into 587 classes and 6,379 methods, and stores them in a small searchable index on your disk.

  2. The AI asks, the index answers. When the AI needs to know about, say, the SPAWN class, it doesn't get the whole file — it gets just SPAWN's documentation and method signatures. Maybe 200–500 tokens.

  3. Answering costs pennies of the budget. A single lookup is like opening one page of a book and reading it aloud. The other 9,999 pages stay closed on the shelf.

  4. Your version, not a stranger's. Because the index is built from your Moose.lua, the answers match the exact MOOSE build your missions use. The AI is never reasoning about an outdated copy.

The result: the AI gets the accuracy of a full 10 MB reference manual while only spending a few hundred tokens at a time. That's what makes it practical for small, budget AI models — not just top-tier ones.


What you need before you start

This is a one-time setup. You'll need:

  1. DCS World installed (any edition — Stable or OpenBeta), since the whole point is reading your mission files and logs.

  2. Node.js, the program that runs JavaScript helper tools like this one. If you don't have it or aren't sure, follow the short check below.

  3. An AI assistant that supports "MCP servers". Cline, Claude Desktop, and Cursor all do. If you're using Cline, you're already good to go.

Don't worry if you've never heard of MCP or Node before — the next two sections walk you through it with no assumed knowledge.


Step 1 — Do you have Node.js?

Node.js is a free program that runs helper tools on your computer. To check if you have it:

  • Windows: press the Windows key, type cmd, and press Enter. In the black window, type:

    node --version

    If you see something like v20.0.0, you have it. If you see 'node' is not recognized, you need to install it.

To install it (Windows):

  1. Go to https://nodejs.org

  2. Download the LTS version (the big green button)

  3. Run the installer — click Next through everything, using the default options

  4. Reopen the cmd window and run node --version again to confirm


Step 2 — Get and install this helper

There isn't a pre-built "release" you download and run. This helper is source code that you download once, then build on your own machine. It's not hard — the commands below do all the work.

Once Node.js is working:

  1. Get the software from here:

    https://github.com/thebgpikester/Mikes-Moose-MCP
    • Click the green Code button → Download ZIP, then unzip it to somewhere you'll remember — e.g. C:\moose-mcp.

    • (Or, if you have Git installed, you can instead run git clone https://github.com/thebgpikester/Mikes-Moose-MCP.git C:\moose-mcp — same result.)

    You should now have a folder C:\moose-mcp containing items like src/, package.json, README.md, and LICENSE.

  2. Open cmd and go into that folder:

    cd C:\moose-mcp
  3. Run the install command (this downloads the helper's dependencies — takes a minute or two the first time):

    npm install
  4. Run the build command (this compiles the source into the program your AI assistant will actually run):

    npm run build

That's it. The helper is now installed and ready.


How the helper finds MOOSE knowledge — your MOOSE, not a stranger's

The helper reads a Moose.lua file and turns it into a searchable index the AI uses to answer questions. There are two ways to give it that file. You can use one or both — it's quick and safe to switch between them.

Option A — Use the downloaded latest MOOSE (easiest, once)

Run this once to fetch the most recent official MOOSE framework file from the internet:

npm run download-reference

This stores a clean reference copy the helper can index. It's a good starting point, and it's the file used if you ever ask the helper to index "the latest MOOSE."

This is the important one. Your DCS/missions don't necessarily use the latest MOOSE — they use whatever Moose.lua you ship or load. So for answers that match your setup exactly, point the helper at your own file. You don't even need a command — just tell your AI assistant, and it will call the moose_ingest tool with the path to your file (for example):

moose_ingest
  path: "C:\\Users\\YourName\\Saved Games\\DCS\\Scripts\\Moose.lua"

It works with any real file path, including a network (UNC) share:

moose_ingest
  path: "\\\\ServerName\\Shared\\Missions\\Moose.lua"

It also works directly on a mission file, pulling out whichever Moose.lua is embedded inside it:

moose_ingest
  path: "C:\\Users\\YourName\\Missions\\MyMission.miz"

What to expect when you ingest a file

When the AI calls moose_ingest, you'll get a short status back, something like:

{
  "ok": true,
  "message": "Indexed 587 types, 6379 methods.",
  "status": {
    "source": "local",            // "local", "reference-download", or "miz-embedded"
    "filePath": "C:\\Users\\YourName\\Saved Games\\DCS\\Scripts\\Moose.lua",
    "commit": "2026-02-06...130d358f4a...",   // the exact MOOSE build, if detectable
    "typeCount": 587,
    "methodCount": 6379
  }
}

Three things to know:

  • Do this after you update MOOSE. If you switch to a newer/older Moose.lua, re-run moose_ingest with the new path. The index is rebuilt to match that file.

  • Re-ingesting the same file is free. The helper hashes the file; if nothing changed, it just refreshes the timestamp — no rebuild.

  • The index is for one file at a time. The current setup indexes the file you most recently asked for. If you switch between your local copy and the reference download, the last one you ingested is the one the AI sees. That's deliberate — it stops the AI from mixing answers across two different MOOSE versions.

Want to test it? Type npm test. It should run through a few checks and print something like All 5 suites passed. If it does, everything works.


Step 3 — Connect it to your AI assistant

An MCP server is just a small program that your AI assistant can talk to, like an extra pair of eyes. You tell your assistant where the helper is, and it does the rest.

If you use Cline

  1. Open Cline's settings (the ⚙️ icon, then "MCP Servers").

  2. Add a new server with these exact settings, changing the path to where you unzipped the project:

    {
      "mcpServers": {
        "moose-mcp": {
          "command": "node",
          "args": ["C:\\moose-mcp\\build\\index.js"]
        }
      }
    }

    (Make sure C:\moose-mcp matches where you actually put it.)

  3. Restart your assistant / reload the window.

If you use Claude Desktop

  1. Open the file claude_desktop_config.json (in Claude's settings folder — the app can open it for you).

  2. Add the same block above to the mcpServers section.

  3. Restart Claude.

After this, your assistant should show a list of new tools it can use (they're all named moose_*).


Step 4 — How to use it

Once connected, just talk to your assistant normally and it will use the MOOSE tools automatically when it makes sense. For example:

  • "Write a script that spawns a flight of F-18s when a unit enters a zone." — the assistant will look up the correct SPAWN and ZONE classes and write Lua 5.1 code that follows MOOSE best practices.

  • "Check this code I wrote" — paste in some Lua and ask it to verify. The assistant will check every class and method name against the real MOOSE.

  • "Tell me how to use CARGO" — it will point you at a real example in the official MOOSE missions repository, rather than guessing.

  • "Why did my mission error?" — if you've turned on the debug logger (see below), it can read your dcs.log and tell you exactly what went wrong and where, including which unit/group the error concerns.

Turning on the debug logger

If you want the helper to be able to read what actually happened in a mission (not just what should have happened), drop a small file into your mission:

  1. Ask your assistant for the file (or take it from src/logger-helper.lua in this project).

  2. Put it in your mission's Scripts folder, alongside (before) Moose.lua.

  3. Logging is on by default now. To turn it off later, set GM.DEBUG = false in that file.

With logging on, your assistant can parse dcs.log, find the current session, and tell you exactly what your script did — and what failed.


What's under the hood (in plain terms)

The helper has four jobs, and together they form a complete picture. Think of it as four reference books the AI can open:

Book

What it answers

Framework Reference

"What is this class? What methods does it have? What are the parameters?" — read directly from your actual MOOSE files, so it matches the version you're using.

Framework Practice

"What's the right way to do this?" — rules based on years of experience (e.g., use TIMER instead of SCHEDULER, don't wrap lookups in pcall).

Mission Truth

"What's actually in my mission file?" — the real group names, units, and triggers, so the AI doesn't guess a FindByName that will miss.

Runtime Truth

"What actually happened when I ran it?" — read from your dcs.log, so you can see if spawned groups appeared, which functions are slow (via PROFILER), and what errored.

Why "version-matched" matters: DCS/missions use whichever MOOSE build they ship. The helper reads that file, so the AI never tells you about a method that doesn't exist in your version.


Troubleshooting

Problem

What to do

'node' is not recognized

Node isn't installed (or cmd wasn't restarted). Go back to Step 1.

npm install errors

Usually a network issue. Re-run it; if it persists, check your internet connection / firewall.

My assistant doesn't show the moose_* tools

The path in Step 3 is probably wrong. Double-check it points at build\index.js and restart your assistant.

npm test fails

Try npm run build first (it refreshes the compiled files), then npm test again.

I can't find my DCS logs

The helper looks in the standard spot: C:\Users\<you>\Saved Games\DCS\Logs\dcs.log (or DCS.openbeta for OpenBeta). It can usually find this itself.


For developers

  • Source code: everything is in the src/ folder (TypeScript files + one Lua helper).

  • Run from source (while developing): npm run dev

  • Test: npm test

  • The four pillars map to pillar1 (parser/index), pillar2-tools.ts (practice), pillar3-parser.ts (mission), pillar4-reader.ts (log).

In short: install once, connect once, and your AI assistant stops guessing about MOOSE and starts writing DCS mission code that works.

Available Tools

11 tools
moose_class_treeA

Returns the inheritance chain of a class (from the class up to BASE) plus the list of method names on each class in the chain. Method names only — no bodies, no docs. This is the cheapest query, ideal for checking "what methods does this class have?" quickly.

Inputs: class (required).

moose_exampleA

Pillar 2 (Framework Practice). Returns a matching vetted author example for a pattern. Author examples mirror the authors own tested missions (e.g. STATIONKEEP, FLEET, SUBHUNT, ADMIRAL). If no vetted author example matches, returns [NEEDS AUTHOR] and declines to answer authoritatively — it will never fall back to unvetted community code unless asked explicitly.

Inputs: pattern (required).

moose_ingestA

Index a Moose.lua file into the framework reference. Provide a path to a local Moose.lua (e.g. from Saved Games\DCS\Scripts\Moose.lua or a UNC path) optionally with source = local | miz-embedded | reference-download. If path is omitted, indexes the bundled latest reference build from GitHub. Re-ingesting is a no-op if the file hash is unchanged. Stamps every record with which file/hash/commit it came from.

Inputs: path, label, source.

moose_instancesA

Cross-cutting instance registry. Knows each DCS install (Stable/OpenBeta, Saved Games path, server vs client). Use action=list to see known instances, action=add to register one (label, variant, saved_games_path, server), action=remove to delete. Once an instance is registered, moose_parse_log and moose_ingest can accept that label as a path instead of a full path.

Inputs: action (required), label, server, variant, +1 more.

moose_lookupA

Returns one precise record from the indexed Moose.lua: the LDoc documentation block, the real Lua function signature, return docs, and the inheritance chain up to BASE. Provide class (required) and optionally method. When method is omitted, returns the class record only. If the method exists on a parent class, it is returned flagged as inheritedFrom. Token-budget: one small record, never a dump.

Inputs: class (required), method.

moose_parse_logA

Parse dcs.log for runtime truth (Pillar 4). Finds the current session start, extracts structured [GM] events (scope/phase/event sim + key=value), and collects SCRIPTING ERROR/WARNING, nil-index, and traceback lines. Never blends runs; handles truncation naturally. Token-budget returns only the requested number of events/errors, capped by default.

Inputs: path, max_errors, max_events, this_session_only.

moose_parse_missionA

Pillar 3 (Mission Truth). Parses a .miz mission file to expose real group names, unit types, countries, waypoints and trigger names. Copy-on-read: the .miz is copied to a temp dir and the mission Lua table is read as text, never executed. Kills FindByName misses with the actual entity names. Degrades gracefully if the file is locked by DCS or the ME.

Inputs: path (required).

moose_practiceA

Pillar 2 (Framework Practice). Returns the most relevant AUTHOR-curated rules for how to use MOOSE well for a given task. Author rules are authoritative and always outrank community code. Optionally filter by phase: plan (planning constraints) or act (coding conventions). Plan/Act workflow: fire phase=plan during planning, phase=act while writing code. Returns small, precise rule records.

Inputs: topic (required), limit, phase.

moose_tail_logA

Tail mode for dcs.log. Parses only lines after from_line, for near-live following. Call repeatedly, advancing from_line from the returned newFromLine to get only new events. Handles truncation/rotation by resetting to 0.

Inputs: path (required), from_line (required).

moose_validateA

Correlation core. Validates a generated Lua snippet against the Pillar 1 framework index. Every CLASS:METHOD call is looked up; unknown methods and classes are flagged, and deprecated-class or pcall-on-lookup anti-patterns are surfaced.

Inputs: code (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.1/5.0

    Scored across 11 tools

    Disambiguation4/5

    Each tool has a distinct role: search/lookup/class_tree for reference, example/practice for guidance, parse_log/tail_log for runtime analysis, and parse_mission for mission data. The only possible overlap is parse_log vs tail_log, but descriptions clearly separate full-session parsing from incremental tailing.

    Naming Consistency3/5

    All tools share the 'moose_' prefix and snake_case, but the suffix pattern mixes verbs (ingest, lookup, search, validate), nouns (example, practice, instances), and verb_noun compounds (parse_log, tail_log, parse_mission). This is readable but not a single consistent convention.

    Tool Count5/5

    With 11 tools, the server covers a comprehensive MOOSE workflow—indexing, querying, validating, log/mission parsing, and instance management—without excess. Each tool addresses a clear need, fitting well within the 3-15 sweet spot.

    Completeness4/5

    The tool set covers the major pillars of MOOSE development: framework reference, practice rules, runtime truth, mission truth, and validation. Minor gaps like removing indexed entries or listing all classes are workable via existing tools (e.g., re-ingest or search).

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      D
      maintenance
      An MCP server that provides LLMs with access to Equinox documentation and tools to validate Equinox module code. It supports both online documentation fetching from GitHub and offline access through local files.
      3
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that exposes the llms.txt file and its referenced local or external resources from a project root to provide context for AI models. It automatically parses documentation links and URLs to make them accessible as additional MCP resources.
      1
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      Generic MCP server that exposes Markdown documentation to LLMs, enabling them to search and answer questions about any software documentation.
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      A local MCP server that gives AI coding assistants retrieval access to your personal knowledge base of books, standards, and docs, grounding their answers in sources you trust.
      MIT