FLYsafe.live — MCP Strategy: AI Enablement Across the FLYsafe.live Suite (v1.3)

🎯 Core Thesis

MCP is the one and only interface layer between FLYsafe.live data and AI agents. No agent — regardless of which MCP server it calls — ever reads or writes a table directly. Every MCP tool is a thin wrapper over an existing API or view, the same contract the frontend already uses. This keeps AI enablement additive: it can only do what the platform's own APIs already allow, scoped further by an agent-specific permission grant.

Read freely, write narrowly. This principle was established for the Aircraft Custodian API's MCP exposure (Aircraft_Custodian_dTwin_Strategy.html §⑤) and this document extends it as the platform-wide standard for all five MCP servers: agents can read almost anything they're scoped to see, but can only write to a short, explicit, operationally-safe allowlist — never to identity, retirement, mission binding, partnership approval, or anything that changes who a drone is or who it's flying for.

This document sets the strategy layer above the individual repos. For the concrete API and schema details it references, see the companion docs already in this repo: Aircraft Custodian & dTwin Strategy, MQTT Topic Reference, and Cross-Tenant Partnership Architecture.

1. Why — the driving force behind AI enablement 2. The five MCP servers — inventory & roles 3. Data streams to expose — consolidated inventory 3.5. Blender / DSS — OI & subscriber query layer 4. MCP design principles for developers 5. Deployment strategy 6. Write-back governance — the RTM boundary 7. Agent personas & use cases 8. Identity, auth & audit 9. Roadmap & phasing 10. Open questions & inputs pending 11. Changelog

① Why — the Driving Force Behind AI Enablement

Two operational needs justify exposing FLYsafe.live data to AI agents, and both bound the scope of what "AI enablement" is allowed to mean here:

🧑‍✈️ Pilots — safe flight ops management

An Aircraft AI agent should be able to answer "is my drone's OI still conforming," "what's my battery and link health right now," "why did I get a TISB alert," and act on a short list of safe, reversible toggles (OI automation on/off, ADS-B surrogate) — without ever being able to change who owns the aircraft, retire it, or rebind its mission.

🗼 Mission managers — integrated airspace

An OCC / Mission Manager AI agent needs fleet-wide visibility across own-tenant drones and the shared surveillance picture (MLAT, ADS-B, vision sensors, partner-tenant drones) to reason about conflicts and DAA proximity. This is read-heavy by nature — the value is situational awareness, not remote control.

Both use cases are served by read access to a wide surface. Neither use case requires broad write access — which is exactly why §6 draws the write boundary as narrowly as it does.

② The Five MCP Servers — Inventory & Roles

All five live in the AM - FLYsafe project in Bitbucket (workspace/projects/AMFS). Two are designated core — platform infrastructure every other AirMarket service builds on going forward — and three are domain adapters that the core layer will increasingly front.

🧩 am-mcp-fsl CORE

The platform-wide MCP gateway for FLYsafe.live. Long-term home for the full data-stream surface — RTM state, surveillance feeds, partnerships, infrastructure health — everything in §3 that isn't already owned by mcp-api-custodian's per-drone API. Also owns the fleet-wide (make/model) side of the Blender/DSS query layer in §3.5 — oi.check_approval_by_description and oi.get_dss_subscribers — since both cross drone boundaries in a way the per-drone Custodian API doesn't.

Primary consumer: OCC AI, Compliance AI, cross-domain agents
Transport: SSE for cloud, stdio for local dev
Status: needs the full table/stream inventory from §10 to reach v1 scope

🚁 mcp-api-custodian CORE

Wraps the Aircraft Custodian API (§⑤ of the dTwin strategy doc) — the per-drone dTwin, OI automation, ADS-B provisioning, ownership flag, health. Already has a drafted MCP tool table (drone.list, drone.get_state, drone.set_oi_automation, etc.) with the read/write split this document generalizes. Owns the by-serial side of the Blender/DSS query layer in §3.5 — oi.check_approval_by_serial — as a natural extension of its existing GET /drones/{serial}/oi/current.

Primary consumer: Aircraft AI (pilot-facing)
Transport: SSE for cloud, stdio for local dev
Status: furthest along — treat as the reference implementation for §4

✈️ mcp-flysafe ADAPTER

Read-only fleet and flight history from FLYsafe.software / DroneLogBook — drone roster, flight logs, fleet summary. Fills in the historical/logbook context that live dTwin state doesn't carry (past flights, maintenance notes, inventory numbers).

Tools: list_drones, get_drone, list_flights, get_drone_flights, get_fleet_summary, cache_status, rebuild_cache
Read-only by design — no DroneLogBook write path exists or is planned

🛰️ am-mcp-dji-fh2 ADAPTER

Read-only DJI FlightHub2 device, dock, and project data — org info, device list, dock status. Explicitly documented in its own source as read-only with respect to FH2; nothing in FH2 is ever modified through this server.

Tools: get_connection_info, get_organization_info, list_projects, list_devices, and dock/device detail calls
Read-only by design

Finding from repo recon — reconcile before Phase 1. The working copy that should correspond to mcp-fh2 currently contains two separate server implementations side by side — a FlightHub2 server at server.py and a FLYsafe/DroneLogBook server at deploy/server.py — plus two installers (install-fh2-mcp.ps1, install-flysafe-mcp.ps1) and two K8s manifests. Left as-is, this makes mcp-fh2 and mcp-flysafe ambiguous as separate Bitbucket repos. Before Phase 1 sign-off, split these cleanly along the repo boundary the team already named (FH2 code → am-mcp-dji-fh2, DroneLogBook code → mcp-flysafe) so each Bitbucket repo builds and deploys exactly one server.

③ Data Streams to Expose — Consolidated Inventory

The two core MCP servers (am-mcp-fsl, mcp-api-custodian) are where every FLYsafe.live data stream should eventually become AI-callable. The table below consolidates every stream this repo's existing architecture docs already describe. It is a floor, not a ceiling — §10 flags where it's still incomplete.

What "RTTP" is, for anyone new to the term. RTTP is the real-time telemetry pipeline that sits at the center of this whole diagram: GCS Plugins → RTTP (encompassing Flink normalization/fusion jobs) → Custodian APIs → tenant.drones, with a second branch RTTP → Evidence & Storage for history/compliance. No raw telemetry ever hits a database directly — RTTP validates and normalizes first. Every row in the tables below is either a piece of RTTP's live output (MQTT), a piece of what it writes to state (Postgres), or a piece of what it writes to history (Evidence & Storage, below). "MQTT" and "RTTP" are not two different systems to account for — MQTT is RTTP's transport.

Postgres — per-tenant RTM state

Table / View	DB	What it holds	Exposing MCP
`drones.dlb_drones`	tenant `rtm_app_db`	Raw DroneLogBook import — identity, hardware/firmware, ownership, financial fields. Written only by the Import process.	mcp-api-custodian (read via view)
`drones.drones`	tenant `rtm_app_db`	Custodian dTwin table — adapter config, OI automation + geometry, ADS-B provisioning, ownership flag, live telemetry state, lifecycle timestamps.	mcp-api-custodian
`drones.v_dtwin`	tenant `rtm_app_db`	Canonical joined dTwin record — the view every consumer (frontend, Custodian, MCP) should read the full drone record from.	mcp-api-custodian (primary read path)
`drones.v_dlb_drones`	tenant `rtm_app_db`	Renamed display view over raw DLB import, for operator-facing reporting.	mcp-flysafe / am-mcp-fsl

Postgres — cross-tenant / central

Table / View	DB	What it holds	Exposing MCP
`aadms.drones`	central AADMS	Materialized view over every tenant's `drones.drones` ⋈ `dlb_drones` via `postgres_fdw` — callsign → (tenant_id, serial_number) routing for inbound ADS-B.	am-mcp-fsl (routing/lookup tools only — never the raw FDW proxies)
`approved_partners`	partnership service DB	Cross-tenant partnership allowlist.	am-mcp-fsl (read-only; status changes stay human-driven per §6)
`approval_requests`	partnership service DB	Partnership request lifecycle log (pending → approved → suspended → revoked).	am-mcp-fsl (read-only)

MQTT / EMQX — real-time streams

Full topic catalog: FLYsafe_MQTT_Topic.html. Categories relevant to agent read access:

Category	Example topic	Contents	Agent access
`v1/output/aircraft/{sn}/…`	`telemetry`, `networkid`, `c2links`, `events`, `alerts/{severity}`, `oi/declaration`, `proximate_aircraft`	Post-Flink-normalized per-aircraft state — the same data the map renders.	Read, via API/MCP tool — never a raw broker subscription from an agent
`v1/shared/…`	`surveillance_traffic/live_mlat`, `live_community`, `live_vision`, `live_regional_{region}`, `surveillance_fused`, `surveillance_sensors/` (station/sensor health), `weather/`, `infrastructure/sites`, `inventory/assets`, `rtm-services/platform`, `alerts/broadcast`	Platform-wide surveillance targets and sensor-health, weather, tenant asset inventory, and infra/pipeline health — identical across tenants.	Read — core to OCC AI's integrated-airspace picture
`v1/input/#`	`aircraft/{sn}/gcs_telemetry`, DJI `thing/product/{sn}/osd` (root-level, no namespace prefix)	Pre-normalization producer feed from GCS Plugins / adapters.	No agent access — this is the producer-only ingestion path
`v1/internal/#`	`dock-status/{sn}`, `asset-tracking/ops/{id}`, `asset-tracking/c2/{id}`	Microservice coordination signals — dock↔drone serial pairing, ops asset positions (incl. dock-mounted ground weather sensors), C2 monitoring stations.	No direct agent access — surface derived fields (e.g. dock status, ground weather) through an API/view if a persona needs them

MCP never subscribes to the broker directly. Every MQTT-sourced field an agent needs must be surfaced through the same REST/WebSocket API the frontend uses (e.g. GET /drones/{serial}/state, GET /drones/{serial}/telemetry) — consistent with this repo's existing ACL model, where only Flink publishes to v1/output/#/v1/internal/# and only producers/adapters publish to v1/input/#. An MCP server is neither.

Tracks a draft, not a committed spec — and several fields are still open. The category-first topic structure above (v1/output|shared|input|internal, tenant implicit in the broker connection, no separate partner/ root) matches FLYsafe_MQTT_Topic.html's current in-progress revision — that file's own header marks it "v0 (legacy) → v1 (category-first) — in progress" and it is not yet committed to this repo. Beyond the overall structure, that doc's own Open Items table (§11) flags specific fields MCP tool design should treat as provisional: weather/* subtopic structure (OI-02, owned by the weather team — not yet designed, don't build a weather tool against it until it lands), the partner Kafka connector source topic (OI-08), and the networkid F3411 field names (OI-12, owned partly by Compliance). Re-check this table against the source doc before relying on it for tool design.

Kafka

Kafka is the platform's general internal transform bus, not only a partnership mechanism — Flink adapter jobs land normalized output there (e.g. DJI OSD → {tenant}.telemetry.raw.dji) on the way to becoming v1/output/… MQTT topics. The one Kafka-carried stream relevant to agent access is cross-tenant partnership data (partner drone telemetry/OI re-publication into this tenant's own output topics, tagged with sourceTenant), per cross-tenant-partnership-architecture.html. Agent read access to partner-drone data should go through the Partnerships API, not a Kafka consumer — the API is what resolves partner status and display-name mapping that the raw topic doesn't carry. No MCP tool, on any server, should ever consume Kafka directly — it is transform-internal, one layer further from a stable contract than even the MQTT topics.

Evidence & Storage — the compliance domain

RTTP has a second output besides tenant.drones: a distinct Evidence & Storage component (Postgres history + InfluxDB telemetry retention, holding CAR 922.08/09/10 evidence logs) that Compliance AI depends on and that isn't the same thing as live dTwin state. It's called out repeatedly as a consumer/destination in the Custodian strategy doc but wasn't broken out as its own inventory line in v1.0 of this document — corrected here.

Component	Contents	Exposing MCP
Postgres history	OI generation history (`GET /drones/{serial}/oi/history`) — audit trail for FLYplan post-flight review and compliance.	mcp-api-custodian (read-only)
InfluxDB telemetry	Same store as the live-telemetry row above, retained for evidence rather than just trails — position/mode/battery history over a compliance-relevant window.	mcp-api-custodian (via `GET /telemetry`, via API, not direct Influx query)
CAR 922.08/09/10 evidence logs	Regulatory compliance records (Canadian Aviation Regulation 922 series). Referenced throughout the architecture docs as a destination, but no dedicated read API is documented yet.	Gap — no MCP tool exists or should be built until a scoped read API exists; flagged in §10

Time-series & external SaaS

Source	Contents	Exposing MCP
InfluxDB	Telemetry timeseries backing `GET /drones/{serial}/telemetry` (position/mode/battery history for trails). See also Evidence & Storage above — same store, compliance angle.	mcp-api-custodian (via API, not direct Influx query)
DroneLogBook API (`api.dronelogbook.com`)	Fleet roster, flight logs — the source of `drones.dlb_drones`.	mcp-flysafe
DJI FlightHub2 API (`fh.dji.com`)	Org, project, device, dock data.	am-mcp-dji-fh2

③.5 Blender / DSS — Operational Intent & Subscriber Query Layer

FLYrtm's RTM services run on a Blender deployment — this is the foundation underneath the OI conformance behavior described throughout this doc and the Custodian strategy (§⑤A FLYplan & OI Automation, §⑧ Surveillance & Ownership Tagging). It hasn't been broken out as its own layer in this document until now; it belongs here because it's the missing hop between "does this drone have an OI" and "who else needs to know about it" — which is exactly the query chain the integrated-airspace use case in §1 depends on.

The query chain, as specified. Two hops, not one:

Blender / RTM query — ask FLYrtm's own OI store: does an Operational Intent exist for this drone/flight, and what's its approval state? This is the system-of-record query, analogous to the Custodian's existing GET /drones/{serial}/oi/current but scoped to the OI approval question specifically, not the full geometry.
DSS query — take the OI reference from step 1 and query the Discovery and Synchronization Service for the airspace volume/time it covers. The DSS returns the set of subscribers associated with that OI — the other USS/tenant parties who registered interest in that volume and need to be notified. This is standard USS-USS discovery behavior (the same family of interoperability this platform's ASTM F3411 Remote ID work already touches, per networkid in FLYsafe_MQTT_Topic.html §5) — a DSS entry doesn't carry the operational data itself, just where to go get it and who else is watching.

New required capability — cross-reference a drone to its OI approval state

The FLYsafe.live MCP must let an agent ask "does this drone have an approved OI" and get an answer two ways:

By serial number — exact lookup. Resolves through the existing dTwin identity chain (drones.v_dtwin → active mission binding → current OI reference) into the Blender/RTM query in step 1 above.
By make/model description — a fuzzy, one-to-many lookup. drones.dlb_drones.brand/model aren't unique keys, so this resolves to a candidate list of drones matching that description (scoped to the caller's tenant), each annotated with its own OI approval state — not a single yes/no.

MCP tool name	Query chain	R/W	Notes
`oi.check_approval_by_serial`	dTwin → Blender OI query	R	Exact match. The primary path — use this whenever the caller already has a serial.
`oi.check_approval_by_description`	fleet lookup (brand/model) → Blender OI query per match	R	Returns a list, not a single result — the tool response must make the one-to-many nature explicit so an agent doesn't misreport a single drone's status when several matched.
`oi.get_dss_subscribers`	OI reference → DSS subscriber query	R	Returns the subscriber/USS list for an OI's airspace volume. Core to OCC AI's integrated-airspace picture (§1, §7) — this is how an agent answers "who else is watching this flight."

This is a read-only layer — keep it that way. Every tool above is Tier 3 (§6): confirming approval state and listing subscribers never writes anything. The DSS write operations this same API surface supports elsewhere — creating or updating an Operational Intent reference, creating or updating a Subscription — are explicitly Tier 0. An agent confirming "is this OI approved" must never be able to create one, and must never register or alter a Subscription on a tenant's behalf; those stay a Blender/RTTP system-of-record operation, not an agent action. Add this pair of bullets to §6's Tier 0 list when this section ships.

Exact endpoint scope pending — Maykon to confirm. The Postman collection sent for this (airmarket.postman.co/workspace/FLYsafe.live/…) sits behind Postman login this document's author doesn't have — an unauthenticated fetch redirects straight to identity.getpostman.com. The query chain and tool table above are built from the stated requirement (Blender OI query → DSS subscriber query) plus this repo's existing OI/F3411 conventions, not from the collection's actual request list. Action: Maykon should confirm the concrete Blender and DSS endpoints this covers (paths, auth scheme, whether it's a direct DSS participant connection or brokered) and reconcile them against the tool table above before am-mcp-fsl implementation starts.

④ MCP Design Principles for Developers

🛠️ Design principles — apply to all five servers

Wrap APIs and views, never tables. Every MCP tool calls an existing REST endpoint or reads through a Postgres view. If the data a tool needs isn't behind a view yet, add the view/endpoint first — don't let the MCP layer become a second, divergent data-access path.
Curated subset, not a 1:1 mirror. Not every endpoint needs an MCP tool. mcp-api-custodian's drafted tool table deliberately excludes retire/restore, identity registration, mission binding writes, and adapter-config changes — start narrow, expand deliberately.
domain.action naming. Follow the existing convention (drone.list, drone.get_state, drone.set_oi_automation) across all servers so an agent orchestrating across multiple MCP servers sees one consistent vocabulary.
Tenant scoping is non-negotiable. Every tool call resolves its tenant from the caller's JWT, exactly like the REST API it wraps. No tool accepts a tenant ID as a free-text argument.
Numeric clamps live server-side, not in the tool description. Where an underlying API enforces a range (e.g. OI geometry factors, 0.5×–2.0×), the MCP tool must rely on that server-side enforcement — never re-implement or loosen it client-side.
Every response surfaces its own freshness. Cache-backed tools (mcp-flysafe, am-mcp-dji-fh2) must return cache_last_updated / staleness warnings in the payload, per the existing mcp-flysafe pattern, so an agent (and the pilot it's advising) knows when it's looking at stale data.
Read tools are broad; write tools are enumerated. Don't design a generic "update drone field" tool. Each writable field gets its own named, narrow tool — this is what makes the write allowlist in §6 auditable at a glance.

⑤ Deployment Strategy

All five servers should converge on the two-transport pattern already proven in mcp-fh2: stdio for local development against Claude Desktop / Claude Code, sse for cloud/cluster deployment.

Mode	When	How
`stdio`	Local dev, Claude Desktop / Claude Code	Server runs as a subprocess; client talks over stdin/stdout. No network exposure, no auth server needed for local iteration.
`sse`	Cloud / Kubernetes	Persistent HTTP service; client connects over HTTP + Server-Sent Events. This is the mode every production agent (Aircraft AI, OCC AI) uses.

Cloud deployment pattern (all five servers)

Docker image → AWS ECR → Kubernetes Deployment
  ├─ Service :8000 (MCP/SSE)  :8080 (health)
  ├─ Pod: single replica per server*
  │    ├─ FastMCP SSE server
  │    ├─ Health HTTP endpoint
  │    └─ Background cache-refresh thread (adapter-specific)
  └─ Secrets via K8s Secret — never a committed .env

* Single-replica caveat. Where a server keeps an in-memory cache and background refresh thread (mcp-flysafe, am-mcp-dji-fh2), each pod's cache is independent — running >1 replica means redundant upstream API hits and inconsistent cache state across pods. Stay single-replica until a shared cache layer (Redis) is added; don't scale these horizontally for HA without that change first. mcp-api-custodian and am-mcp-fsl, which read live from Postgres rather than an in-process cache, don't have this constraint.

Ingress requirements for SSE

SSE is a long-lived streaming connection — the ingress must not buffer it:

nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-buffering: "off"

Without proxy-buffering: off, the SSE stream buffers at the ingress and the client never receives messages — this has already bitten the mcp-fh2 deployment once; carry the fix forward to every server's manifest.

Environment convention

Variable	Description
`MCP_TRANSPORT`	`stdio` (default) or `sse`
`PORT` / `HEALTH_PORT`	SSE port (default 8000) and health-check port (default 8080)
`<ADAPTER>_API_KEY` / `_URL`	Per-adapter credentials — `FLYSAFE_API_KEY`, `FH2_AUTH_TOKEN`, etc. Supplied via K8s Secret in cloud, local `.env` (gitignored) in dev.
`_REFRESH_INTERVAL` / `_STALE_AFTER_S`	Cache refresh cadence and staleness thresholds, surfaced in every tool response per the freshness principle in §4.

⑥ Write-Back Governance — the RTM Boundary

This is the section that matters most for safety and compliance: where, exactly, is an agentic workflow allowed to write back into a FLYsafe.live RTM service? The answer is a four-tier model, generalized from the split mcp-api-custodian already drafted. Every MCP tool across all five servers must be classified into exactly one tier before it ships.

🚫 Tier 0 — Never exposed via MCP No agent access

Operations that change a drone's identity, ownership registration, or cross-tenant routing, or that alter partnership trust state. These remain human-initiated through the frontend, full stop — no agent persona, no permission grant, changes this.

Drone retire / restore
Identity registration — Keycloak client, AADMS publication
Mission binding create / delete (callsign ↔ serial authoritative link)
Adapter-config changes (MAVLink host/port, DJI FH2 endpoint)
Partnership allowlist and approval-request state changes (approve/suspend/revoke)
DSS entity writes — creating or updating an Operational Intent reference, creating or updating a Subscription (§3.5). These stay a Blender/RTTP system-of-record operation, never an agent action.

🔒 Tier 1 — Permission-scoped writes Explicit grant required

Operationally meaningful but reversible changes. Exposed only to agent service accounts with an explicit per-tenant permission grant in Keycloak, and every write must carry an audit reason field.

drone.set_ownership — surveillance ownership flag (audit reason required)
Publish-rate changes (affects telemetry cost/load tenant-wide if misused)

⚙️ Tier 2 — Operationally-safe writes Default-on for the relevant persona

Bounded, reversible, server-range-enforced. Safe to expose by default to the persona the tool serves (typically Aircraft AI), without a separate permission grant beyond normal tool access.

drone.set_oi_automation — enable/disable OI automation
drone.set_oi_distance — OI defaults, numeric clamp enforced server-side
drone.set_adsb_surrogate — ADS-B surrogate toggle
drone.regenerate_oi — force OI regeneration

👁️ Tier 3 — Read-only Open by default, tenant-scoped

Everything else: dTwin state, telemetry, OI status/history, health, fleet/flight history, surveillance feeds, partnership visibility, ADS-B status, and the Blender/DSS OI-approval and subscriber lookups in §3.5. This is the overwhelming majority of the surface in §3 — read access should be generous, because both driving use cases in §1 are read-heavy.

Hard rule. No MCP tool, on any of the five servers, may write directly to a database table, publish directly to an MQTT topic, or produce directly to a Kafka topic. Every write — Tier 1 or Tier 2 — goes through the same REST endpoint the frontend calls, carrying the calling agent's own scoped JWT. If a write can't be expressed as a call to an existing (or newly added) API endpoint, it does not become an MCP tool; the API gets built first.

⑦ Agent Personas & Use Cases

🧑‍✈️ Aircraft AI (pilot-facing)

Assists the pilot flying a specific drone. Primary consumer of mcp-api-custodian.

Read: dTwin state, OI status, health, telemetry
Write: Tier 2 toggles only

🗼 OCC / Mission Manager AI

Assists mission managers running integrated airspace across the fleet and shared surveillance picture. Primary consumer of am-mcp-fsl.

Read: fleet-wide state, surveillance traffic/sensors, proximate_aircraft/DAA, alerts, partner-drone visibility, OI approval by serial or make/model, DSS subscriber lists (§3.5)
Write: none by default; Tier 1 only with explicit grant

📋 Compliance AI

Evidence and audit-focused. Reads OI history, ADS-B status, health/lifecycle events, and the Evidence & Storage domain (§3) once its CAR 922 read API exists.

Read: everything audit-relevant
Write: none — Tier 3 only, by design

Emerging fourth persona — not yet formal. FLYsafe_MQTT_Topic.html's Open Items table (OI-07) notes that dead-letter-queue monitoring is developer-watched today, with "AI agent monitoring under consideration for production." That's a genuine Ops/Platform AI use case distinct from the three above — read-only against pipeline health (rtm-services/platform, DLQ depth/age) rather than drone state. Don't design tools for it yet; note it here so Phase 3+ scoping doesn't miss it once the team confirms direction.

⑧ Identity, Auth & Audit

MCP inherits the platform's existing Keycloak/JWT model rather than inventing a parallel one:

Every MCP call carries a JWT issued by the tenant's Keycloak realm — the same mechanism that authenticates GCS Plugins and the frontend.
MCP agents authenticate as per-agent service accounts, not as the operator's own session token (which GCS Plugins use). This keeps agent activity separately auditable from human operator actions.
Tier 1 permission grants are Keycloak role assignments — scoped per tenant, per agent persona — not a flag baked into the MCP server.
Every Tier 1/2 write is attributable to a JWT subject in the same audit trail the platform already relies on for compliance; no separate MCP-specific audit log needs to be invented.

⑨ Roadmap & Phasing

Phase 1

Finalize mcp-api-custodian against the tier model in §6; this is the closest to done and becomes the reference implementation the other four match.

Phase 2

Split the mcp-fh2 working copy along its real repo boundary (§2 finding) so am-mcp-dji-fh2 and mcp-flysafe are each a single, cleanly deployable server.

Phase 3

Close the ClickUp whiteboard gap (§10) and extend am-mcp-fsl to the full data-stream inventory in §3 — surveillance, infrastructure health, partnerships — plus the Blender/DSS OI-approval and subscriber query tools in §3.5 once Maykon confirms the concrete endpoint scope.

Phase 4

Cross-tenant-aware read tools in am-mcp-fsl — partner-drone visibility through the Partnerships API, matching the read-only partner UX already specified in the partnership architecture doc.

Phase 5

Formalize the Tier 1 permission model as first-class Keycloak roles per agent persona, so granting/revoking agent write access is an admin action, not a code change.

⑩ Open Questions & Inputs Pending

ClickUp whiteboard not accessible to this document. The whiteboard at app.clickup.com/8562670/whiteboards/859ze-31497 requires authenticated access this session doesn't have (an unauthenticated fetch returns ClickUp's mobile-app landing page, not the board). §3's inventory is built entirely from schemas and architecture docs already in this repo. Action: whoever owns that board should export it (image or ClickUp doc) into this repo, or walk through it live, so §3 can be reconciled against the authoritative data-structure map and any DB/table it names that isn't yet in §3 gets added.

Bitbucket AMFS project not independently audited. The project overview page at bitbucket.org/AirMarket_Inc/workspace/projects/AMFS 404s on an unauthenticated fetch. This strategy is grounded in the two local working copies available (mcp-fh2/am-mcp) plus the architecture already documented in this repo — it has not been checked against the actual current state of mcp-api-custodian, mcp-flysafe, or am-mcp-dji-fh2 as they exist in Bitbucket today. Action: a repo-by-repo capability audit (tool list, transport mode, deployment status) before Phase 1 sign-off.

Tier 1 permission mechanism not yet built. §6 assumes Keycloak role-based grants for Tier 1 tools; confirm this is the intended mechanism (versus a separate agent-permissions service) before Phase 5.

No read API for CAR 922 evidence logs yet. §3's Evidence & Storage table names these logs as a real destination referenced throughout the architecture docs, but no endpoint exposes them today. Action: once Compliance owns a scoped read API for this data, add the corresponding Tier 3 tool to mcp-api-custodian — don't build agent access to the underlying store ahead of that API.

weather/* stays out of scope until OI-02 resolves. The topic exists and is named in §3, but its subtopic structure is still TBD (owned by the weather service team). Treat any weather MCP tool as blocked on that item landing, not as something to build against the current placeholder shape.

Blender/DSS Postman collection not accessible to this document. The shared Postman workspace link redirects to identity.getpostman.com for this session — same access limitation as the ClickUp whiteboard and Bitbucket project in the earlier entries above. §3.5's tool table is built from the stated query chain (Blender OI query → DSS subscriber query) and this repo's existing OI/F3411 conventions, not from the collection's actual requests. Action: Maykon to confirm the concrete Blender and DSS endpoints, auth scheme, and whether DSS access is a direct participant connection or brokered, before §3.5 tools are implemented.

📝 Changelog

v1.3 (2026-07-27)

Added §3.5 — Blender / DSS Operational Intent & Subscriber Query Layer, covering FLYrtm's Blender deployment as the foundation of RTM services, the two-hop query chain (Blender OI query → DSS subscriber query), and the new required capability: cross-referencing a drone's OI approval state by serial number or by make/model description.
Added three new Tier 3 (read-only) tools: oi.check_approval_by_serial (mcp-api-custodian), oi.check_approval_by_description and oi.get_dss_subscribers (am-mcp-fsl).
Added an explicit Tier 0 entry for DSS entity writes (Operational Intent references, Subscriptions) — never exposed via MCP.
Flagged the Blender/DSS Postman collection as inaccessible to this document (Postman login wall) and named Maykon as the owner to confirm concrete endpoint scope before §3.5 tools are implemented.

v1.2 (2026-07-26)

Added an explicit definition of RTTP (§3) — the real-time telemetry pipeline that MQTT, Postgres, and InfluxDB are all facets of, not three separate systems.
Closed real gaps in §3's stream inventory found by re-checking against the current MQTT doc and Custodian strategy doc: weather/*, surveillance_sensors/*, and inventory/assets added to the shared-broker row; broadened the Kafka description beyond partnerships to its general adapter-transform role.
Added a new Evidence & Storage table (§3) — the compliance domain (Postgres history, InfluxDB retention, CAR 922 logs) that Compliance AI depends on, previously only mentioned in passing.
Flagged an emerging fourth persona (Ops/Platform AI, DLQ monitoring — per the MQTT doc's OI-07) as a forward signal, not yet a formal scope item (§7).
Added two Open Questions: no read API yet for CAR 922 evidence logs; weather/* MCP exposure blocked on OI-02.

v1.1 (2026-07-26)

Synced §3's MQTT table to the current (uncommitted, in-progress) category-first revision of FLYsafe_MQTT_Topic.html — added surveillance_fused and alerts/broadcast to the v1/shared/… row.
Added an explicit note that §3's MQTT section tracks a draft, not a committed spec, and should be re-checked if that migration changes further before landing.

v1.0 (2026-07-26)

Initial strategy draft — five-server inventory, consolidated data-stream map, four-tier write governance model, deployment pattern, roadmap.
Flagged ClickUp whiteboard and Bitbucket AMFS project as inaccessible inputs pending owner follow-up (§10).
Flagged FH2/FlySafe server overlap found in local mcp-fh2 working copy as a pre-Phase-1 cleanup item (§2).

🔌 MCP Strategy — AI Enablement Across FLYsafe.live

🎯 Core Thesis

Contents

① Why — the Driving Force Behind AI Enablement

🧑‍✈️ Pilots — safe flight ops management

🗼 Mission managers — integrated airspace

② The Five MCP Servers — Inventory & Roles

🧩 am-mcp-fsl CORE

🚁 mcp-api-custodian CORE

✈️ mcp-flysafe ADAPTER

🛰️ am-mcp-dji-fh2 ADAPTER

③ Data Streams to Expose — Consolidated Inventory

Postgres — per-tenant RTM state

Postgres — cross-tenant / central

MQTT / EMQX — real-time streams

Kafka

Evidence & Storage — the compliance domain

Time-series & external SaaS

③.5 Blender / DSS — Operational Intent & Subscriber Query Layer

New required capability — cross-reference a drone to its OI approval state

④ MCP Design Principles for Developers

🛠️ Design principles — apply to all five servers

⑤ Deployment Strategy

Cloud deployment pattern (all five servers)

Ingress requirements for SSE

Environment convention

⑥ Write-Back Governance — the RTM Boundary

🚫 Tier 0 — Never exposed via MCP No agent access

🔒 Tier 1 — Permission-scoped writes Explicit grant required

⚙️ Tier 2 — Operationally-safe writes Default-on for the relevant persona

👁️ Tier 3 — Read-only Open by default, tenant-scoped

⑦ Agent Personas & Use Cases

🧑‍✈️ Aircraft AI (pilot-facing)

🗼 OCC / Mission Manager AI

📋 Compliance AI

⑧ Identity, Auth & Audit

⑨ Roadmap & Phasing

Phase 1

Phase 2

Phase 3

Phase 4

Phase 5

⑩ Open Questions & Inputs Pending

📝 Changelog

v1.3 (2026-07-27)

v1.2 (2026-07-26)

v1.1 (2026-07-26)

v1.0 (2026-07-26)