fpv-sim-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_engagementA | Run a single deterministic force-on-force engagement to completion and return the full record: winner (or STALEMATE) with reason, duration, phase timeline, per-team fix quality (CEP breakdown), LOB and intercept counts per DF node, key event timestamps, drone/GCS end states, and the complete event log. Tactical mode adds the objective, sortie tallies and the per-airframe package state. Notional data. |
| sweep_seedsA | Run count consecutive seeds (start_seed .. start_seed+count-1) under one configuration and return aggregate statistics only: win rates by team including STALEMATE, time-to-fix and time-to-kill distributions (mean/median/p10/p90), duration distribution, stalemate reasons, and notable seeds worth drilling into with run_engagement. Aggregation is computed server-side; per-run event logs are not returned. Max count 1000. |
| compare_configsA | Run two CONFIG variants over the SAME consecutive seed range (a paired experimental design: terrain and emplacement luck cancel out, so a few hundred seeds resolve real effect differences) and return each variant's aggregate statistics, the paired outcome deltas, the seeds whose outcome flipped, and a plain-language summary generated from those numbers. Use it to test doctrine questions, e.g. what happens to win rates when OPFOR adopts EMCON discipline. Max count 500. |
| describe_modelA | Return the modeling assumptions: DF measurement and bearing-error model, RF propagation, fix estimation and its quality gates, drone state machine, EMCON semantics, outcome definitions, and the known simplifications. Read this before drawing conclusions from simulation results — it states what the model can and cannot support. |
| get_config_schemaA | Return every parameter accepted in config_overrides: path, unit, default, sane range, and description — plus the parameters that are deliberately not overridable and why. This is generated from the same table that validates tool inputs, so it cannot drift from actual behavior. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| design-notes | Technical write-up of the original browser simulation this server wraps: terrain and RF models, the DF fix math and its honesty gates, drone behavior, tuning guide, and known simplifications. |
| mcp-design-notes | How this project extracted the browser sim into a headless engine, how determinism parity is verified, and why the MCP interface looks the way it does. |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: single detailed runs, multi-seed aggregate sweeps, paired config comparisons, and two documentation tools. There is no overlap or risk of an agent selecting the wrong tool for a task.
All five tools follow a consistent verb_noun pattern (run_engagement, sweep_seeds, compare_configs, describe_model, get_config_schema), making the set predictable and easy to navigate.
With five tools, the server is well-scoped for a simulation workbench: three execution tools and two supporting documentation tools. Every tool earns its place without redundancy.
The core simulation lifecycle is covered: single-run detail, multi-seed aggregation, and paired configuration comparison, plus schema and model documentation. Minor gaps exist such as supporting comparisons of more than two configs or extracting per-run logs from a sweep, but workarounds are available.