Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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.

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.

moose_searchA

Fuzzy-match on half-remembered class or method names against the indexed Moose.lua. Returns each match as name + a one-line summary (plus signature/parent where available). Cap at 15 results by default, max 30. Use this before lookup when you only half-remember a name.

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.

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.

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.

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.

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.

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.

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.

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
MOOSE index statusCurrent state of the Moose.lua index: file, hash, commit, counts, provenance.
MOOSE structured logger helperDrop-in logger-helper.lua that emits one-line structured [GM] events into dcs.log. dofile it before Moose.lua in your mission.

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

ActivitySlowing
ResponsivenessNo issues