How do I use fpv-sim-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fpv-sim-mcp run an engagement with seed 20260719" 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.

fpv-sim-mcp

by wasomma

Overview Schema Related Servers Score Discussions

TypeScript

fpv-sim-mcp

An MCP server that exposes fpv-sim — a deterministic force-on-force simulation of FPV sUAS vs counter-UAS RF direction finding — as tools an AI agent can call.

All data is notional. The area of operations ("AO KATANA"), unit positions, sensor parameters, and outcomes are invented for demonstration purposes. Unclassified throughout.

Why this exists

The original fpv-sim is a browser tab a human watches. This project demonstrates the step after that: making the same simulation agent-accessible, so an AI assistant can run engagements, sweep hundreds of seeds, compare doctrine variants, and explain the results — the workflow the original developers did by hand during tuning (grid sweeps, 40 seeds per cell) packaged as five typed, validated, deterministic tools. The simulation core was extracted from the browser file into a headless TypeScript engine with behavior parity proven by golden-master tests: the same seed produces the same engagement, tick for tick, as the browser version.

The core lesson is unchanged from the original: the side that transmits less is harder to fix. An agent with these tools can discover that itself — see the example transcript below.

Related MCP server: The Trench MCP Server

Quick start

Requires Node 20+.

git clone https://github.com/wasomma/fpv-sim-mcp.git
cd fpv-sim-mcp
npm install
npm test        # builds and proves browser-parity + unit tests (26 tests, both modes)
npm run demo    # exercises the server through a real MCP stdio client

Claude Code

claude mcp add fpv-sim -- node /absolute/path/to/fpv-sim-mcp/dist/src/server/index.js

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "fpv-sim": {
      "command": "node",
      "args": ["/absolute/path/to/fpv-sim-mcp/dist/src/server/index.js"]
    }
  }
}

(On Windows use a path like C:\\path\\to\\fpv-sim-mcp\\dist\\src\\server\\index.js.)

Remote (no local install)

The server also ships a Streamable HTTP entry point (dist/src/server/http.js) for hosting on any box with Node 20+ — deploy/DEPLOY.md is a complete VPS runbook (systemd, Caddy TLS, bearer-token auth).

A hosted demo instance runs at https://wasomma-fpv.duckdns.org/mcp (health probe at /healthz). It is bearer-token protected — it exposes CPU, not secrets, but an open sim endpoint invites abuse. If you'd like to try it without building anything, ask me for a token (GitHub / LinkedIn), then:

claude mcp add --transport http fpv-sim https://wasomma-fpv.duckdns.org/mcp \
  --header "Authorization: Bearer <token>"

Determinism makes the hosted instance verifiable: run_engagement(20260719) returns the same BLUFOR victory at T+311.1s from the cloud that the local build produces — same seed, same engagement, any machine.

Tools

Tool	What it does
`run_engagement(seed, mode?, config_overrides?)`	One full deterministic engagement: winner (or STALEMATE) with reason, duration, phase timeline, per-team fix quality (CEP breakdown), LOB/intercept counts per DF node, key timestamps, and the complete event log. Tactical mode adds the objective, sortie tallies, and the per-airframe package state.
`sweep_seeds(start_seed, count, mode?, config_overrides?)`	Up to 1000 consecutive seeds under one configuration, aggregated server-side: win rates (including stalemates), time-to-fix and time-to-kill distributions, stalemate reasons, and notable seeds to drill into.
`compare_configs(start_seed, count, mode?, config_a, config_b, labels?)`	Two CONFIG variants over the same seeds (paired design — terrain and emplacement luck cancel out), with per-variant stats, outcome flips, deltas, and a plain-language summary generated from the numbers.
`describe_model()`	The modeling assumptions: DF error model, RF propagation, fix quality gates, drone FSM, EMCON semantics, both engagement plans — and the known simplifications an agent must respect before drawing conclusions.
`get_config_schema()`	Every tunable parameter with path, unit, default, and sane range. Generated from the same table that validates inputs, so documentation and enforcement cannot drift.

mode selects the engagement plan, exactly as in the browser sim: "orbit" (default) is the original fight — one FPV per side holds a forward orbit while the DF nodes build the fix — and "tactical" is the multi-FPV sortie stream: each side pushes a package of one-way strike sorties into a shared objective (OBJ TANTO), its GCS emitting sortie by sortie, while a reserved hunter-killer launches on the fix; both packages spent with no hunter able to go is the STALEMATE reason packages_expended. Same terrain, sensors and fix math either way, and the same seed gives the same emplacement in both modes. Tactical knobs live under TACTICAL.* in config_overrides (package size, pilot stations, reserve-or-retask, launch spacing, objective geometry).

Resources: fpv-sim://design-notes (the original sim's technical write-up) and fpv-sim://mcp-design-notes (this project's DESIGN_NOTES.md).

Every tool is read-only and side-effect-free. Identical inputs always return identical outputs — the server itself is deterministic, which is what makes results citable: any number an agent reports can be reproduced by anyone running the same call.

Example: what an agent does with this

Abridged transcript (tool results elided; the numbers below are real — reproduce them with npm run demo or the same tool calls):

User: Does emissions discipline actually decide these fights, or is that just the demo's marketing? Test it.
Agent: (calls describe_model) The model says the only default asymmetry is EMCON posture: BLUFOR keys its uplink 4s on / 13s off with burst video, OPFOR 10s on / 4s off with continuous video. I'll test the claim by giving OPFOR the same discipline as BLUFOR and comparing across identical seeds.
(calls get_config_schema, then compare_configs(start_seed: 1000, count: 200, config_a: {}, config_b: {TEAMS: {OPFOR: {uplinkOn: 4, uplinkOff: 13, videoOn: 3, videoOff: 7}}}))
Across 200 paired seeds: stock OPFOR (continuous emitter) loses 40.0% to 25.5%. When OPFOR adopts BLUFOR's duty cycles, the gap closes to 34.0% vs 30.0% — 45 of 200 seeds change outcome, and BLUFOR's mean time-to-fix on the OPFOR GCS degrades by ~146 seconds because the uplink it collects against is keyed 76% less of the time. So yes: with identical hardware, EMCON posture alone moves the win rate by ~10 points and starves the enemy's fix timeline. The residual BLUFOR edge is its 6-second earlier launch. Worth knowing: ~35% of engagements are honest stalemates — the estimator refuses to bless a bad fix, so nobody commits.

That last sentence is the point of the whole exercise: the agent can also read describe_model and report what the simulation cannot claim.

Postscript — one claim above didn't survive a bigger experiment. The agent's parting guess that "the residual BLUFOR edge is its 6-second earlier launch" was later tested directly: a 2,000-pair study run on this engine (fpv-sim's MONTE_CARLO.md, experiment E2c) equalized the launch times and found the stagger moves every outcome rate by less than half a point — a non-factor. EMCON posture explains essentially the whole gap. The transcript stands as written because that is how this is supposed to work: a deterministic, citable claim was cheap to re-test at 10× the sample size, and it lost.

Determinism and provenance

Same seed, same engagement. All randomness draws from one seeded mulberry32 stream. Golden-master tests prove the extracted engine reproduces the browser version's five featured scenarios exactly — event log string-for-string, end times to the 0.1s tick, fix CEPs float-for-float (DESIGN_NOTES.md describes the three-legged verification, including a cross-check against the untouched sim in a real browser).
Authored with AI assistance (Anthropic's Claude, via Claude Code), like the original fpv-sim. The engine is a faithful port of the original simulation code, whose modeling comments are preserved in place; the fixtures it is tested against were generated by running the original, unmodified simulation source.
All simulation data is notional and unclassified. Numbers are plausible-magnitude fiction shaped by doctrine, not measured data. Nothing here supports absolute performance claims about any real system.

Repository layout

src/engine/    headless simulation engine (port of fpv-sim's index.html)
src/server/    MCP server: five tools, two resources, zod validation;
               build.ts is shared by the stdio (index.ts) and
               Streamable HTTP (http.ts) entry points
test/          golden-master parity + unit tests (npm test)
examples/      demo MCP client (npm run demo)
scripts/       golden-fixture generator (needs ../fpv-sim checkout)
deploy/        VPS runbook + hardened systemd unit for remote hosting
docs/upstream/ pinned snapshot of the original DESIGN_NOTES.md

License

This repository is public for demonstration, not open source. Licensed under the PolyForm Strict License 1.0.0: you may read the code and use it for noncommercial purposes, but no rights are granted to modify, redistribute, or use it commercially. (Connecting an agent to the hosted MCP endpoint is exactly the intended use.)

Available Tools

5 tools

compare_configsCompare two configurations over the same seedsA

Read-only

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.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Engagement plan. "orbit" (default): one FPV per side holds a forward orbit while the DF nodes build the fix. "tactical": each side pushes a package of one-way strike sorties into a shared objective (OBJ TANTO), its GCS emitting sortie by sortie, while a reserved hunter-killer launches on the fix; can end in the STALEMATE reason packages_expended. Same terrain, sensors and fix math either way; the same seed gives the same emplacement in both modes.
`count`	Yes	Number of consecutive seeds run under BOTH variants.
`label_a`	No	Human-readable name for variant A.
`label_b`	No	Human-readable name for variant B.
`config_a`	Yes	Variant A overrides (may be {} for the stock configuration).
`config_b`	Yes	Variant B overrides (may be {} for the stock configuration).
`start_seed`	Yes	Deterministic engagement seed. The same seed always replays the identical engagement. Featured orbit seeds: 20260719 (standard BLUFOR win), 66 (fast BLUFOR win), 57 (deliberate BLUFOR win), 41 (OPFOR win), 59 (close race, OPFOR). Featured tactical seeds: 12 (standard BLUFOR win), 26 (fast BLUFOR win), 5 (final-push BLUFOR win), 18 (close race, BLUFOR), 41 (OPFOR win), 14 (stalemate).

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

readOnlyHint=true already covers the safety profile, and the description adds useful behavioral context: the paired-seed rationale, the artifact list returned, and the count cap. It does not contradict the annotation, and the added detail goes beyond what readOnlyHint alone provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all high-signal: purpose and output list in the first, a concrete use case in the second, and the operational limit in the third. There is no filler or redundant elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the necessary work of telling the caller what will be returned. It also explains the experimental design, gives a representative use case, and caps the seed count. Combined with the highly detailed input schema, an agent has enough context to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameter semantics are already documented in the input schema. The description's references to same consecutive seeds and max count of 500 largely restate schema constraints rather than adding new parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Run two CONFIG variants over the SAME consecutive seed range') and clearly identifies the tool's resource and experimental design. It also enumerates the concrete outputs (aggregate statistics, paired deltas, flipped seeds, plain-language summary), making it easy to distinguish from single-run or unpaired sweep tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this tool for doctrine questions and explains why the paired same-seed design is appropriate ('terrain and emplacement luck cancel out'). It does not explicitly name alternatives such as run_engagement or sweep_seeds or state when not to use this tool, so it falls just short of full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

describe_modelDescribe the simulation modelA

Read-only

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, but the description adds value by detailing the content of the output (assumptions and limitations). No contradictions. The behavioral context is well explained beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that are front-loaded and contain all necessary information without redundancy. Every sentence serves a purpose, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description comprehensively lists the return content and mentions the tool's value in understanding model limitations. It is complete for a descriptive read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (0 parameters, schema coverage 100%). The description is not required to add parameter semantics, and it does not. Baseline score of 4 is appropriate for this case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states that the tool returns modeling assumptions and lists specific components (DF measurement, bearing-error model, etc.). It clearly differentiates from sibling tools like 'run_engagement' which are for running simulations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises to read the output before drawing conclusions, providing clear when-to-use guidance. It also implies this tool is for understanding model limitations, not for running simulations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_config_schemaGet the tunable-parameter schemaA

Read-only

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds that it's generated from the validation table ensuring no drift, providing complete behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each carrying essential information without waste; first sentence details returns, second adds non-drift property.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool without output schema, the description thoroughly covers what is returned and a key behavioral property, making it complete for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters; description adds meaning by enumerating output contents (path, unit, default, etc.) and mentioning non-overridable parameters, which is valuable beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies 'Return every parameter accepted in config_overrides' with details like path, unit, etc., and distinguishes from sibling tools by focusing on schema retrieval rather than execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly describes what the tool returns and mentions the non-overridable parameters, guiding when to use for understanding tunable parameters, but lacks explicit when-not-to-use or comparison with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_engagementRun one engagementA

Read-only

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.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Engagement plan. "orbit" (default): one FPV per side holds a forward orbit while the DF nodes build the fix. "tactical": each side pushes a package of one-way strike sorties into a shared objective (OBJ TANTO), its GCS emitting sortie by sortie, while a reserved hunter-killer launches on the fix; can end in the STALEMATE reason packages_expended. Same terrain, sensors and fix math either way; the same seed gives the same emplacement in both modes.
`seed`	Yes	Deterministic engagement seed. The same seed always replays the identical engagement. Featured orbit seeds: 20260719 (standard BLUFOR win), 66 (fast BLUFOR win), 57 (deliberate BLUFOR win), 41 (OPFOR win), 59 (close race, OPFOR). Featured tactical seeds: 12 (standard BLUFOR win), 26 (fast BLUFOR win), 5 (final-push BLUFOR win), 18 (close race, BLUFOR), 41 (OPFOR win), 14 (stalemate).
`config_overrides`	No	Optional partial CONFIG overrides. Call get_config_schema for the parameter table.

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description extensively discloses behavior beyond the readOnlyHint annotation: determinism ('same seed always replays the identical engagement'), STALEMATE outcomes and the packages_expended reason, tactical-mode output differences, and the crucial flag that the data is 'Notional data.' No contradiction with readOnlyHint exists — the deterministic run-and-return semantics are consistent with a read-only computation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph with the core action front-loaded ('Run a single deterministic force-on-force engagement to completion') followed by the return-record enumeration. It runs long due to the output list, but every clause earns its place given there is no output schema to carry that information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description's detailed enumeration of the return record (winner, reason, duration, phase timeline, CEP breakdown, LOB/intercept counts, timestamps, end states, event log, and tactical-mode additions) serves as the de facto output documentation. Combined with the rich input schema (featured seeds, mode semantics, config defaults), an agent has everything needed to invoke and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents mode, seed, and every nested config_overrides field with units, defaults, and ranges. The description adds only marginal parameter context, e.g., that tactical mode adds objective and sortie-tally outputs. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Run a single deterministic force-on-force engagement to completion' and enumerates the full return record. The 'single' qualifier distinguishes it from the sibling sweep_seeds, and the output enumeration (winner/STALEMATE, phase timeline, CEP breakdown, event log) leaves no ambiguity about scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context on what the tool does and how orbit/tactical modes alter behavior, which informs when an agent would call it. However, it never explicitly names alternatives or exclusion conditions — it doesn't say to use sweep_seeds for multi-seed exploration or compare_configs for configuration comparisons. Differentiation from sweep_seeds is only implicit in the word 'single'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sweep_seedsSweep a seed rangeA

Read-only

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.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Engagement plan. "orbit" (default): one FPV per side holds a forward orbit while the DF nodes build the fix. "tactical": each side pushes a package of one-way strike sorties into a shared objective (OBJ TANTO), its GCS emitting sortie by sortie, while a reserved hunter-killer launches on the fix; can end in the STALEMATE reason packages_expended. Same terrain, sensors and fix math either way; the same seed gives the same emplacement in both modes.
`count`	Yes	Number of consecutive seeds to run.
`start_seed`	Yes	Deterministic engagement seed. The same seed always replays the identical engagement. Featured orbit seeds: 20260719 (standard BLUFOR win), 66 (fast BLUFOR win), 57 (deliberate BLUFOR win), 41 (OPFOR win), 59 (close race, OPFOR). Featured tactical seeds: 12 (standard BLUFOR win), 26 (fast BLUFOR win), 5 (final-push BLUFOR win), 18 (close race, BLUFOR), 41 (OPFOR win), 14 (stalemate).
`config_overrides`	No	Optional partial CONFIG overrides. Call get_config_schema for the parameter table.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, so the description carries behavioral disclosure. It adds valuable details: aggregation is computed server-side, per-run event logs are not returned, and max count is 1000. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences plus a short max-count clause, with the operation and scope front-loaded. No filler; every sentence contributes to selection or invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch-analysis tool with no output schema, the description enumerates the return aggregates in detail and clarifies the no-logs constraint. It is sufficient for an agent to decide and call correctly, though it doesn't describe error handling or exact output structure, which is acceptable given the schema richness elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 adds the seed-range formula and restates max count, but parameter-level meaning is already well documented in the schema, including mode explanations and featured seed examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Run'), resource ('count consecutive seeds'), scope ('under one configuration'), and output ('aggregate statistics only'). It enumerates the exact statistics returned and explicitly notes that per-run event logs are not returned, which differentiates it from run_engagement without needing to open that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: run a batch of seeds and get only aggregate statistics. It routes to run_engagement for notable seeds and states that per-run logs are absent, implying when to switch. It doesn't explicitly cover compare_configs, describe_model, or get_config_schema, but the primary use case is well defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
pronto-stream A
io.github.nmxmxh
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
Aerospace & Astrodynamics Autonomous Agents
131

Related MCP Servers

AFSIM MCP Server
Aerospace & Astrodynamics Autonomous Agents
Yookio-Z
A
license
A
quality
D
maintenance
Enables LLMs and AI agents to interact with AFSIM through standardized MCP tools for scenario management, entity/component control, simulation execution, and results analysis.
Updated 3 months ago (2026-05-20 09:46 UTC)
37
23
MIT
The Trench MCP Server
Aerospace & Astrodynamics
jasonmeverett
F
license
Not graded
quality
D
maintenance
MCP server for controlling satellite ground station operations in the Trench simulation, including pass management, downlink control, and antenna pointing.
Updated a year ago (2025-09-16 15:23 UTC)
jsbsim-mcp
Aerospace & Astrodynamics Research & Data
flyintothesky
F
license
Not graded
quality
B
maintenance
Provides the JSBSim flight-dynamics engine as an MCP service, enabling AI agents to control and simulate aircraft in real-time through natural language.
Updated 2 months ago (2026-07-11 05:34 UTC)
gazebo-mcp
Developer Tools Autonomous Agents
mergeos-bounties
A
license
Not graded
quality
A
maintenance
MCP server for AI agents to drive Gazebo / gz-sim simulation, with offline mock mode for CI/demos.
Updated a month ago (2026-07-22 06:51 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wasomma/fpv-sim-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server