Kshana: la marca, una retícula de brújula que señala el instante preciso, junto al logotipo tipográfico kshana

kshana-mcp: pregunte a su asistente de IA y el motor responde

kshana-mcp es un servidor de Model Context Protocol (MCP) para Kshana, el simulador de código abierto para la resiliencia de PNT (posicionamiento, navegación y temporización). Permite que un asistente de inteligencia artificial (IA) ejecute el motor real y lea su JSON (JavaScript Object Notation), en lugar de adivinar las matemáticas. Habla por stdio (entrada y salida estándar) con cualquier cliente compatible con MCP, incluidos Cursor y JetBrains AI Assistant / Junie.

Las matemáticas para las que Kshana está validado son justo donde un modelo de lenguaje adivina peor: la propagación orbital SGP4 (Simplified General Perturbations 4), los marcos de referencia de la IAU (Unión Astronómica Internacional), las desviaciones de Allan, la disponibilidad de GNSS (sistema global de navegación por satélite) y el DOP (dilución de la precisión), los niveles de protección de ARAIM (monitorización avanzada de integridad autónoma del receptor), la fusión de GNSS e INS (sistema de navegación inercial) y los modelos de sensores cuánticos. Haga una pregunta; el asistente ejecuta un escenario real y obtiene cifras de mérito con su procedencia y su etiqueta VALIDATED o MODELLED.

Un motor abierto en el centro, con el servidor MCP como una de sus superficies junto a la línea de comandos, la biblioteca de Rust, Python, WebAssembly y Kshana Studio, la imagen de Docker y el complemento de JetBrains; todas las superficies ejecutan el mismo motor, y Kshana Pro depende de él sin bifurcarlo

Herramientas#

Herramienta	Qué hace
`run_scenario`	Ejecuta un escenario a partir de una definición TOML (Tom's Obvious, Minimal Language); devuelve el resumen y el JSON de resultados completo (JavaScript Object Notation: cifras de mérito, curvas). El parámetro opcional `include_chart` devuelve el gráfico como SVG (Scalable Vector Graphics).
`list_scenario_kinds`	Los 92 tipos de escenario integrados con descripciones y campos obligatorios/opcionales, para que el agente pueda construir un escenario válido.
`validate_scenario`	Comprobación previa: analiza el TOML y detecta su tipo de escenario, sin ejecutarlo.
`list_example_scenarios`	Los escenarios de referencia incluidos como JSON: cada `name`, su `kind` y una frase sobre lo que muestra. Filtro `kind` opcional. Cada ejemplo se ejecuta tal cual, de modo que esta es la vía más rápida hacia un TOML válido para un tipo de escenario.
`get_example_scenario`	El texto TOML de un escenario de referencia incluido, byte por byte el archivo de `scenarios/`.
`report_scenario`	Ejecuta un escenario y devuelve su informe: resumen ejecutivo, entradas, cada cifra con su unidad y su etiqueta VALIDATED o MODELLED, sucesos, las capacidades ejercitadas y un registro de reproducibilidad. `format` es `json` (por defecto) o `html` (la página imprimible de un solo archivo).
`animate_scenario`	Ejecuta un escenario y devuelve su serie temporal como animación: `svg` (por defecto), `html` (un reproductor autónomo) o `frames` (como máximo 120 en una respuesta). El primer elemento de contenido es un resumen JSON de lo que se dibujó; siguen los archivos. Un tipo de escenario sin eje temporal muestreado se rechaza indicando el motivo.
`list_export_formats`	Qué formatos de interoperabilidad se aplican a un escenario (`czml`, `kml`, `geojson`, `stk`, `sigmf`), el motivo cuando uno no se aplica y la especificación que sigue cada escritor. No ejecuta el escenario.
`export_interop`	Exporta un escenario como CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON, efemérides STK (Systems Tool Kit) `.e`, o SigMF (Signal Metadata Format, para un escenario `spectrum` con un bloque `[iq]`). El primer elemento de contenido es un índice JSON de los archivos (sufijo, tamaño, codificación y el resumen SHA-256, el Secure Hash Algorithm de 256 bits); siguen los archivos, con el archivo binario de muestras SigMF en base64.
`import_route`	Escribe una ruta GeoJSON `LineString` en un escenario que vuela una trayectoria de puntos de paso (`terrain-nav`, `terrain-slam`, `gravity-map`, `combined-altpnt`) y devuelve el nuevo TOML.
`export_sp3`	Exporta la constelación de un escenario `orbit` como efemérides precisas SP3-c (Standard Product 3, revisión c).
`export_omm`	Exporta los elementos de un escenario `orbit` como un catálogo OMM (Orbit Mean-elements Message) de CCSDS (Consultative Committee for Space Data Systems) 502.0-B-2.
`export_oem`	Exporta la serie de estados de un escenario `orbit` como efemérides CCSDS OEM (Orbit Ephemeris Message) 2,0: la serie de posición y velocidad en TEME (ecuador verdadero, equinoccio medio) que leen las herramientas de dinámica de vuelo (GMAT, General Mission Analysis Tool; Orekit; STK, Systems Tool Kit); el complemento con velocidad de `export_sp3`, que solo lleva posición.
`export_table_csv`	Ejecuta un escenario y devuelve su tabla de reproducibilidad como CSV (valores separados por comas): la tabla estable byte a byte que la CLI (interfaz de línea de comandos) escribe como `<scenario>.table.csv`. Solo `realtime-frame-eop`, `lunar-time-budget`, `lunar-jamming`, `telecom-timing`, `leo-navmsg` (su análisis `encode-decode` sobre un modelo de mensaje `kepler16` o `kepler-rac`) y `moonlight-service-volume` con `export_site_lat_deg` + `export_site_lon_deg` fijados emiten una; cualquier otro tipo de escenario devuelve un error que nombra estos.
`sky_geometry`	Geometría del cielo bajo un perfil del horizonte dependiente del acimut: a partir de un emplazamiento, una hora y preajustes de constelación, conjuntos de elementos de dos líneas (`tle`, propagados con SGP4 a una `epoch` UTC) o satélites como acimut/elevación o ECEF, los satélites visibles y los ocultos por el perfil, GDOP/PDOP/HDOP/VDOP/TDOP a partir del núcleo de DOP comprobado con gnss_lib_py, el cofactor y la covarianza este-norte-arriba (un reloj por sistema o uno común) y la elipse de error horizontal; con `skyline_preset` en lugar de `request`, un preajuste REPRESENTATIVE con su procedencia y su corte cada grado. MODELLED; lleva la declaración consultiva; sin Monte Carlo por MCP. Véase `docs/SKYLINE.md`.
`assess_receiver_log`	Evalúa la confianza de un registro real de un receptor GNSS (sistema global de navegación por satélite). El TOML nombra el `format` del registro (`ubx`, `rinex`, `android`, `nmea` o `sbf`) y da sus bytes en línea como `text` o `base64`; la herramienta ejecuta los monitores de confianza (caída de la densidad de portadora a ruido, pérdida de enganche, AGC (control automático de ganancia), indicador de inhibición, salto de posición y, con RINEX más navegación difundida, RAIM (monitorización de integridad autónoma del receptor) y un monitor asistido por reloj) y devuelve cuándo y por qué la posición dejó de ser digna de confianza. Las secciones opcionales `[[events]]` y `[compare]` puntúan sucesos declarados y caídas previstas de C/N0 frente a tolerancias declaradas. Una tabla `[platform] kind = "vessel"` selecciona los monitores marítimos y añade una puntuación de confianza de 0 a 100 por época con los monitores que restaron (consultivo; MODELLED). El registro se envía en línea como `text` o `base64` (como máximo 4 MiB). Gráfico y CSV por época a petición. Véase `docs/RECEIVER-TRUST.md`.
`assess_vessel_stream`	Puntúa un extracto NMEA 0183 acotado (como máximo 2 MiB y 20.000 épocas; debe contener la ventana de calibración) como lo puntúa `kshana receiver-trust live`: estado de confianza por época y puntuación de 0 a 100 con los monitores que restaron, un resumen y la última `$PKSHT`. La forma acotada del comando en directo: no se abre ningún socket y no se escribe nada en un puerto; la puerta, `--listen` y los exportadores de telemetría (Prometheus, OTLP, syslog) son solo de línea de comandos. Solo consultivo; MODELLED. Véase `docs/MARITIME-TRUST.md`.
`assess_vessel_log`	Un registro NMEA 0183 de un buque (como máximo 4 MiB) como ejecución por lotes, con el TOML de sesión que indica los límites del buque: el modelo de puntuación y la puntuación de 0 a 100 de cada época con sus deducciones (la respuesta conserva los recuentos por estado y las primeras 200 épocas degraded o untrusted). Solo consultivo; MODELLED.
`jammertest_import`	Lee el catálogo de pruebas y el plan de transmisión publicados de Jammertest (NPRA/jammertest-plan, MIT) como verdad programada (`kshana jammertest import`): las franjas de un área de prueba se convierten en sucesos de confianza del receptor con el identificador del catálogo y el año en cada etiqueta. Franjas planificadas, no horas de emisión registradas; no se lee ningún campo de contacto del plan. MODELLED. Véase `docs/JAMMERTEST.md`.
`jammertest_score`	Puntúa un registro de receptor frente a ese programa (`kshana jammertest score`): por prueba, la latencia de detección, las alarmas perdidas y el tiempo de recuperación, y las falsas alarmas fuera de cada franja. Registros de texto como `log`, binarios (`ubx`, `sbf`) como `log_base64`. Un paquete firmado necesita una clave: línea de comandos. Solo consultivo; MODELLED.
`create_evidence_pack`	Un paquete de evidencias firmado para una ventana del registro de un buque (`kshana receiver-trust evidence`): los bytes brutos del registro de la ventana, la configuración, los resultados y motivos por época, una página de resumen y un manifiesto con cada SHA-256 y una cadena de hashes, firmado con Ed25519. La semilla de firma nunca se devuelve ni se registra; sin una se usa una clave de un solo uso, de modo que el paquete prueba integridad, no identidad. Un registro técnico, no un dictamen jurídico. Véase `docs/EVIDENCE-PACKS.md`.
`attach_evidence_timestamp`	Vincula a un paquete un token de marca de tiempo RFC 3161 (base64 de los bytes de `.tsr`), en memoria (`kshana evidence attach-timestamp`); el paquete con el token debe seguir verificándose. No se comprueba la firma de la autoridad de marca de tiempo: use `openssl ts -verify`.
`verify_evidence_pack`	Verifica un paquete (`kshana evidence verify`): cada hash, la cadena, la firma y, con la clave pública del firmante y el registro completo, quién lo firmó y que el fragmento procede de ese registro. Nombra cada fallo y archivo. El `verdict` es `verified` (firmante fijado), `intact-signer-not-pinned` (todo se comprueba pero no se dio ninguna clave pública, de modo que el firmante no queda establecido) o `failed`; `require_timestamp` hace fallar un paquete sin token de marca de tiempo.
`generate_training_nmea`	NMEA 0183 sintético de puente para formación de tripulaciones a partir de un TOML `nmea-scenario` (inhibición, arrastre de posición, suplantación de hora, retardo de reproducción) con el registro del instructor (`kshana-nmea-training/1`); determinista por semilla. Solo texto: no se sintetiza nada a nivel de RF ni de IQ y no se transmite nada; nunca para los sistemas de navegación en vivo de un buque. La respuesta lleva las primeras 2000 líneas.
`build_interference_map`	Un mapa de interferencias GNSS a partir de informes de posición ADS-B o AIS como texto CSV (como máximo 4 MiB): un GeoJSON `kshana-interference-map/v1` por día UTC, solo agregado (sin identificadores, con las celdas de menos de 5 aeronaves o buques distintos retenidas), con la licencia del conjunto de datos incorporada. Una celda degradada no identifica la interferencia como causa; no es una previsión. MODELLED. Véase `docs/INTERFERENCE-MAP.md`.
`export_test_bench`	El movimiento del vehículo y los sucesos de un escenario para un simulador GNSS de laboratorio (`kshana bench-export`): CSV y JSON de movimiento, NMEA, puntos de paso y sucesos como texto, sin escribir nada en disco. Tipos de escenario `gnss-ins`, `jamming`, `gnss-sim`. Sin señal: nada de lo exportado es, modela ni maneja una señal de radiofrecuencia o de banda base; el simulador y su operador aportan las señales. Véase `docs/TEST-BENCH.md`.
`create_round_trip_pack`	El paquete firmado de ida y vuelta de laboratorio (`kshana evidence round-trip`): el escenario, el documento `kshana.test-conditions/1` del laboratorio, el registro del receptor y su puntuación frente a los sucesos declarados, enlazados por hash. Rechaza condiciones y sucesos de puntuación que discrepan. Sin señal; un registro técnico, no una certificación.
`iq_sweep`	Reproduce una grabación IQ del directorio de trabajo con varios diseños de lazo de seguimiento (`kshana iq sweep`): por diseño y PRN, la fluctuación de fase y de código en régimen estacionario, las fracciones de enganche y la C/N0 media. Como máximo 256 canales (diseño, PRN) por llamada; el intervalo debe caber en el presupuesto de muestras.
`iq_monitor`	Ejecuta los monitores de detección de interferencia y de suplantación sobre una grabación IQ del directorio de trabajo (`kshana iq monitor`): monitores de potencia y espectrales de banda ancha y monitores de C/N0 y de calidad de señal por satélite frente a una línea base aprendida. Nombres y longitudes de series y hasta 200 sucesos en la respuesta; el informe completo a petición como archivos. Un suceso dice que una magnitud medida salió de su línea base, no por qué. MODELLED.
`iq_labfit`	Ajusta el modelo de pérdida de enganche del lazo de seguimiento a ejecuciones de laboratorio (`kshana iq labfit`) a partir de un escenario `iq-labfit` cuyos registros van en línea (`text` o `base64`; se rechaza un `path`). No lee ni escribe ningún archivo. MODELLED.
`iq_test_conditions`	Valida un archivo `kshana.test-conditions/1` dado como texto y devuelve las condiciones resueltas con su hash. Solo en línea.
`compliance_report`	La correspondencia con marcos públicos, rellenada a partir de documentos de resultados dados como texto (`kshana compliance-report`): a qué filas de seis marcos y normas de resiliencia (marco US DHS Resilient PNT v2.0, IMO para buques, EASA para aviación, NIS2 artículo 21, EN 16803, NIST IR 8323r1) aportan evidencias a favor las ejecuciones, a cuáles no, y la brecha de cada fila. Recibe `runs` de `{label, result, scenario?}` (como máximo 64, 4 MiB en total). Un estado indica que las ejecuciones aportan evidencias a favor de las capacidades de la fila; no es una conclusión de que se haya alcanzado un marco ni una calificación o aprobación de ningún producto. La `statement` se devuelve con cada informe; muéstrela literalmente. MODELLED. Véase `docs/compliance/`.
`compliance_mapping`	Las tablas de correspondencia estáticas (o, con `sources`, los documentos fuente que citan, con versiones y URL) en Markdown, encabezadas por la misma declaración. No necesita ejecuciones.
`trust_telemetry`	Un flujo de confianza (líneas JSON) o un resultado de `receiver-trust` convertido a texto Prometheus, líneas syslog CEF o LEEF, una carga útil JSON de OTLP o líneas de descubrimiento y estado MQTT de Home Assistant, con los codificadores de `kshana trust-telemetry`. Texto en la respuesta: no se envía ni se sirve nada y no se lee ningún reloj. Solo orientativo.
`fit_imu_log`	Parámetros de acelerómetro y giróscopo de los escenarios `hybrid` y `fusion` ajustados a partir de un registro de IMU estacionaria (CSV o EuRoC) mediante desviación de Allan, con una tabla `[accel_classical]` lista para pegar y el SHA-256 del registro (`kshana imu-fit`). Texto de entrada, JSON de salida; MODELLED.
`list_standards_packs`	Los paquetes de normas (`kshana standards-pack list`): conjuntos de escenarios puntuados para los perfiles de ensayo del marco DHS Resilient PNT (niveles 1 a 4), IMO MSC.1/Circ.1575 y OACI Doc 9849 Apéndice F.
`run_standards_pack`	Un paquete ejecutado frente a sus umbrales fijados antes de la ejecución (`kshana standards-pack run`): cada ensayo es `MET`, `NOT MET` o `NEEDS INPUT`, con valores medidos y esperados; entregue el informe a `compliance_report` para ver las filas. MODELLED; no califica ningún producto.
`lunanet_afs_check`	La señal directa aumentada de LunaNet comprobada frente a LNIS V5 AD1 Volumen A (LSIS-AFS V1.0, 29 de enero de 2025): `spec` (la implementación frente a las tablas de códigos impresas del documento y sus ejemplos resueltos), `symbols` (un flujo de símbolos: patrón de sincronización, SB1, FID, continuidad de TOI) o `generate` (un flujo de prueba). LDPC y CRC-24Q de las subtramas 2 a 4 no se verifican; no se escribe ninguna señal.
`score_benchmark`	Una entrega de kshana-bench puntuada frente a un archivo de verdad de referencia, ambos en texto JSON (`kshana bench score`, `bench/SPEC.md`): el archivo de resultados con la versión de la especificación, la partición, los hashes de entrada y las métricas de la tarea. MODELLED; describe un registro o un corpus, nunca un producto.
`render_leaderboard`	Archivos de resultados de kshana-bench convertidos en la página estática de clasificación (texto HTML), cada uno validado antes.
`trust_telemetry`	Un flujo de confianza (líneas JSON) o un resultado de `receiver-trust` convertido a texto Prometheus, líneas syslog CEF o LEEF o una carga útil JSON de OTLP, con los codificadores de `kshana trust-telemetry`. Texto en la respuesta: no se envía ni se sirve nada y no se lee ningún reloj. Solo orientativo.
`route_exposure`	La proporción de la longitud de una ruta que cae en celdas degradadas, no degradadas, no evaluadas y no observadas de uno o más mapas de interferencia, opcionalmente dentro de un intervalo de fechas. Las celdas no observadas no son evidencia de que la ruta esté despejada.
`iq_signals`	La configuración de la capa IQ de GNSS: los nombres de señal que aceptan las herramientas IQ, si las herramientas de archivos IQ están activadas, el directorio de trabajo y el presupuesto de muestras por llamada. Llámela primero.
`iq_info`	Describe una grabación IQ (en fase y en cuadratura) del directorio de trabajo sin procesarla: formato, frecuencia de muestreo, frecuencia central, muestras, duración, archivos de datos y tamaños (`kshana iq info`).
`iq_scene`	Genera una escena IQ de GNSS con varios satélites en el directorio de trabajo (`kshana iq scene`): perfiles de Doppler/C/N0 indicados, o geometría real de efemérides de difusión a partir de un archivo de navegación RINEX, con un canal de propagación opcional a nivel de señal. Responde con los archivos escritos y sus recuentos de bytes y la primera época de la verdad de referencia por satélite.
`iq_acquire`	Adquisición por FFT (transformada rápida de Fourier) de uno o más PRN (códigos de ruido pseudoaleatorio) sobre una grabación (`kshana iq acquire`), opcionalmente tras etapas de front-end: por PRN, adquirido o no, Doppler, fase de código, estadístico de pico y umbral; `surface_out` (un PRN) conserva toda la superficie de correlación Doppler × fase de código con refinamientos de Doppler fino.
`iq_track`	Adquiere y después sigue con el banco de lazos DLL/PLL/FLL (lazos de seguimiento de retardo, fase y frecuencia) (`kshana iq track`), con los lazos de un archivo TOML `kshana.loop-design/1` del directorio de trabajo (`design`) o el diseño integrado, y readquisición opcional (`reacquire`): por canal, épocas, Doppler final, C/N0 final y medio, fracciones de enganche de fase y de código, enganchado al final, el estado de enganche final, falsos enganches y readquisiciones, además del nombre y el hash del diseño. El seguimiento se transmite en memoria acotada; la salida por época va solo a archivos (`epochs_out`: E/P/L, discriminadores, estados de los lazos, C/N0, estado de enganche como .csv/.jsonl/.bin; `events_out`).
`iq_frontend`	Aplica DSP (procesamiento digital de señal: paso de banda, filtro de muesca, anulación, escisión, AGC, cuantificador) de front-end del receptor y de mitigación de interferencias a una grabación y escribe una nueva (`kshana iq frontend`).
`iq_campaign`	Ejecuta una campaña de repetición de laboratorio (`kshana iq campaign`): grabaciones, cada una con un archivo de condiciones de ensayo que indica la verdad de referencia conocida del laboratorio, × cadenas de front-end × diseños de lazo. Cada celda se puntúa por tiempo hasta la pérdida de enganche, tiempo de readquisición, degradación de C/N0 frente a la J/S indicada (junto a una referencia analítica etiquetada MODELLED), tasa de falsos enganches, jitter de PLL/DLL y disponibilidad. Incremental y reanudable: cada llamada ejecuta las celdas pendientes que caben en el presupuesto de muestras (o en `max_cells`).
`iq_campaign_status`	El progreso de una carpeta de salida de campaña: celdas hechas y pendientes, y el resumen criptográfico una vez completa. Solo lee archivos.

Cada herramienta es una envoltura fina y fiel de una función pública de la biblioteca kshana: aquí no vive ninguna lógica de simulación nueva, de modo que un agente ejecuta exactamente el motor validado.

Las herramientas IQ de GNSS: archivos de entrada, JSON compacto de salida#

Las grabaciones IQ llegan a gigabytes, por lo que las herramientas iq_* nunca pasan muestras por el protocolo. Siguen un único contrato:

Un directorio de trabajo. El servidor lee y escribe archivos IQ solo dentro de la carpeta indicada por KSHANA_MCP_IQ_DIR. Todo argumento de ruta es relativo a ella (una ruta absoluta debe resolverse dentro de ella); las entradas se resuelven a través de enlaces simbólicos antes de la comprobación, la carpeta de una salida debe existir ya dentro de ella, y una salida existente solo se reemplaza con overwrite: true. Si no está definida, las herramientas de archivos IQ están desactivadas e indican cómo activarlas; todas las demás herramientas no se ven afectadas.
Un presupuesto de muestras. Una llamada genera o procesa como máximo KSHANA_MCP_IQ_MAX_SAMPLES muestras complejas (por defecto 50.000.000). En bytes son 400 MB como cf32_le (8 bytes por muestra compleja), 200 MB como ci16_le (4 bytes) y 100 MB como ci8 (2 bytes); una escena se escribe como cf32_le salvo que format indique otra cosa. La comprobación se hace antes de cualquier trabajo, y el rechazo indica la duración o el max_seconds que cabe.
Respuestas compactas. Cada herramienta responde con un único resumen JSON: picos de adquisición, C/N0, estado de enganche y cada archivo escrito con su ruta y su recuento de bytes. Las tablas por época van a los archivos json_out / csv_out que usted indique.
Los argumentos desconocidos se rechazan, no se ignoran, de modo que una opción mal escrita es un error.

Cada herramienta ejecuta la misma ruta de código que kshana iq en la línea de comandos, dentro del proceso. La capa es solo software: escribe archivos para receptores de software y no controla ningún hardware de radio. La capa IQ no añade síntesis de interferencia ni de suplantador, y nunca se transmite nada. (El tipo de escenario spectrum, aparte, puede escribir en un archivo instantáneas IQ de interferentes analíticos.)

{
  "mcpServers": {
    "kshana": {
      "command": "/Users/you/.cargo/bin/kshana-mcp",
      "env": { "KSHANA_MCP_IQ_DIR": "/Users/you/iq" }
    }
  }
}

Con la imagen de Docker, monte la carpeta y apunte la variable a ella: docker run --rm -i -v "$PWD/iq:/iq" -e KSHANA_MCP_IQ_DIR=/iq ghcr.io/ashfordeou/kshana-mcp.

Todo tipo de escenario es accesible#

run_scenario despacha según el campo kind del escenario, de modo que todo tipo de escenario que nombra list_scenario_kinds se ejecuta a través de ella. Eso incluye las familias más recientes, cada una con ejemplos incluidos que un agente puede obtener:

Capacidad	Tipos	Un ejemplo del que partir
Espectro y cascada	`spectrum`	`l-band-waterfall-jamming`
El sistema solar	`solar-system`	`solar-system-tour`
Constelaciones alrededor de cualquier cuerpo	`constellation-design`, `body-pnt`	`lunar-relay-constellation`, `europa-surface-pnt`
Campañas: fases encadenadas, barridos, Monte Carlo (conjuntos aleatorios con semilla), composición	`campaign`	`campaign-sweep-jammer-power`
Navegación en órbita terrestre baja (LEO): diseño de señal	`leo-signal`	`leo-band-trade`
Navegación LEO: presupuesto de enlace de un pase	`leo-pass`	`leo-pass-iridium`
Navegación LEO: mensaje de navegación	`leo-navmsg`	`leo-navmsg-encode-decode`
Navegación LEO: posicionamiento y temporización fusionados	`leo-pvt`, `leo-ppp`, `ntn-positioning`, `leo-pnt-chain`	`leo-doppler-positioning`, `leo-pnt-end-to-end`

list_example_scenarios con un kind nombra todos los ejemplos incluidos de ese tipo. Las animaciones, los informes y las exportaciones de interoperabilidad no son tipos de escenario: son vistas de una ejecución, y animate_scenario, report_scenario y export_interop las devuelven para cualquier escenario al que se apliquen.

No se sirven: las suites de estudio (kshana --study <suite.toml>), porque una suite nombra archivos de escenario hermanos en disco y las herramientas de escenario no leen ningún archivo. Ejecute cada miembro con run_scenario. (Las herramientas IQ sí leen y escriben archivos, solo dentro de su directorio de trabajo.)

Instalar el servidor MCP#

De carácter consultivo, no es un equipo de navegación homologado: el operador sigue siendo responsable de la navegación. El servidor se ejecuta en su ordenador; no se envía nada a Ashforde OÜ.

Un pasaje que nombra clientes de IA de terceros se omite aquí; está en mcp/kshana-mcp/README.md en GitHub.

Canal	Comando o botón	Requiere	Forma fijada
Cursor (un clic)	npx (Node) · Docker	Node o Docker	`kshana-mcp@0.40.0` / `ghcr.io/ashfordeou/kshana-mcp:0.40.0`
VS Code (un clic)	npx (Node) · Docker · Insiders (npx)	Node o Docker	`kshana-mcp@0.40.0` / `ghcr.io/ashfordeou/kshana-mcp:0.40.0`
npx	`npx -y kshana-mcp@0.40.0`	Node 18+	`kshana-mcp@0.40.0`
uvx / pipx	`uvx kshana-mcp==0.40.0` · `pipx run kshana-mcp==0.40.0`	Python 3,9+ con uv o pipx	`kshana-mcp==0.40.0`
Docker	`docker run -i --rm ghcr.io/ashfordeou/kshana-mcp:0.40.0`	Docker	`ghcr.io/ashfordeou/kshana-mcp:0.40.0`
Homebrew	`brew install ashfordeOU/tap/kshana-mcp`	brew	fórmula para v0.40.0
Scoop	`scoop bucket add ashforde https://github.com/ashfordeOU/scoop-bucket` y luego `scoop install kshana-mcp`	Scoop (Windows)	manifiesto para v0.40.0
winget	`winget install AshfordeOU.KshanaMcp`	winget (Windows)	`--version 0.40.0`
cargo	`cargo install kshana-mcp --version 0.40.0`	Rust 1,88+	`kshana-mcp 0.40.0`
Binario precompilado	la página de la versión: `kshana-mcp` (Linux x86-64), `kshana-mcp-<target>[.exe]`, comprobado con `SHA256SUMS` y `gh attestation verify`	ninguna	v0.40.0
Registro de MCP	`io.github.ashfordeOU/kshana-mcp` (lo encuentran los clientes que conocen el registro)	un cliente que conoce el registro	`0.40.0`
Remoto (HTTP en streaming)	`kshana-mcp --http 127.0.0.1:8080`, autoalojado: véase https://github.com/ashfordeOU/kshana/blob/main/docs/deploy/mcp-http.md	su propio host	v0.40.0

Desde una copia de trabajo o git (desarrollo):

cd mcp/kshana-mcp && cargo install --path .
cargo install --git https://github.com/AshfordeOU/kshana kshana-mcp

Modo HTTP (autoalojado)#

kshana-mcp --http 127.0.0.1:8080 sirve las mismas herramientas mediante HTTP en streaming en /mcp. Se enlaza solo a loopback; una dirección que no sea loopback necesita --allow-remote y un token de portador en KSHANA_MCP_HTTP_TOKEN; las herramientas de archivos IQ están desactivadas; el tamaño de las peticiones, el tiempo y la concurrencia están limitados; no se envía ninguna cabecera CORS. Kshana no aloja un punto de conexión: usted lo autoaloja. Véase docs/deploy/mcp-http.md.

cargo install coloca kshana-mcp en su PATH (normalmente ~/.cargo/bin/kshana-mcp). El servidor habla JSON-RPC (llamada a procedimiento remoto en JSON) por stdio; los registros van a stderr. Compilar desde el código fuente necesita una cadena de herramientas de Rust ≥ 1,88 (el SDK rmcp 2.x parcheado la necesita, y también la biblioteca kshana); la imagen de Docker no necesita ninguna.

Registrarlo en un cliente#

Prácticamente todos los clientes MCP usan el mismo bloque de configuración mcpServers: registre el binario kshana-mcp por su ruta absoluta:

{
  "mcpServers": {
    "kshana": {
      "command": "/Users/you/.cargo/bin/kshana-mcp",
      "args": [],
      "env": {}
    }
  }
}

O bien, con la imagen de Docker en lugar de un binario local (no hace falta PATH):

{
  "mcpServers": {
    "kshana": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "ghcr.io/ashfordeou/kshana-mcp"]
    }
  }
}

Dónde se coloca ese bloque depende del cliente:

Cursor: ~/.cursor/mcp.json (global) o .cursor/mcp.json (por proyecto).
JetBrains AI Assistant / Junie: Settings → Tools → AI Assistant → Model Context Protocol → Add → As JSON, pegue el bloque y reinicie por completo el IDE (entorno de desarrollo integrado).
Asistentes de escritorio: la mayoría usa un …_config.json con la misma estructura mcpServers; consulte la documentación de su cliente para saber dónde se ubica el archivo.
Agentes de CLI: muchos aceptan el mismo JSON mediante un mecanismo mcp add / mcp.json.

Use siempre una ruta absoluta al binario. Defina RUST_LOG=debug en env para diagnosticar problemas (los diagnósticos van a stderr; stdout se reserva para el protocolo JSON-RPC).

Pruébelo#

Una vez registrado, pida a su asistente cosas como:

"Enumera los tipos de escenario de Kshana." → list_scenario_kinds
"Muéstrame un ejemplo de spectrum de Kshana y ejecútalo." → list_example_scenarios, get_example_scenario, run_scenario
"Ejecuta el escenario de holdover de reloj de Kshana con un umbral de 20 ns y una interrupción de GNSS de 2 horas; ¿cuál es el holdover cuántico frente al clásico?" → run_scenario
"Exporta esa constelación GPS (Sistema de Posicionamiento Global) como SP3." → export_sp3
"Dame la tabla realtime-frame-eop como CSV." → export_table_csv
"Pon ese pase de Iridium en un globo de Cesium." → list_export_formats, export_interop
"Anima la campaña de jamming." → animate_scenario
"Dame el informe de esa ejecución, con su registro de reproducibilidad." → report_scenario
"Crea una escena GPS L1 de un segundo con los PRN 3 y 17, y luego adquiérela y síguela." → iq_signals, iq_scene, iq_acquire, iq_track

Nota de diseño: por qué un crate aparte#

El servidor es un crate independiente, excluido del workspace, con su propio Cargo.lock, de modo que el SDK (kit de desarrollo de software) oficial de MCP para Rust, rmcp, y su entorno de ejecución asíncrono nunca entran en el grafo de dependencias del crate kshana publicado: un usuario de la biblioteca o de Python no compila un servidor que no ejecuta. (Se separó por primera vez porque rmcp es edición 2024 y necesita rustc ≥ 1,85, mientras que el crate principal prometía entonces 1,75. La biblioteca y este servidor declaran ahora ambos 1,88, el mínimo de rmcp 2.x con parches de seguridad y de los crates de RustCrypto actualizados.) La integración continua (CI) controla este crate por separado: pruebas y cargo deny frente a su archivo de bloqueo. El árbol de licencias de rmcp está limpio (Apache-2.0/MIT/BSD), así que, a diferencia del crate de validación cruzada xval/anise-frames, que por lo demás imita, la separación no obedece a la licencia.

Licencia: AGPL-3.0-only, la Licencia Pública General Affero de GNU versión 3 únicamente (o una licencia comercial de Ashforde OÜ; véase LICENSING.md del repositorio).