Drone Imagery MCP Server

An aerial inspection / drone imagery platform for ADK-Rust Enterprise energy & utility agents. 23 MCP tools covering a drone fleet, sites & inspection assets, flights/missions, geotagged imagery, detections with vegetation-clearance encroachment analysis, vegetation risk scoring + a prioritized risk queue, and remediation dispatch — over an audit trail, with approval gates on flying drones and dispatching crews.

A platform, not a point solution

This is modeled as a general aerial-inspection backbone (the layer behind a utility's drone vegetation-management and asset-inspection program), so inspection agents are clients of one shared system:

The inspector analyzes imagery into clearance detections, scores and prioritizes vegetation risk across the network, and — through gated tools — schedules follow-up flights and dispatches trim crews.

Architecture

Capabilities

• Fleet — drones with sensors (rgb/thermal/lidar), battery, and status (available/in_flight/maintenance/grounded).
• Sites & assets — inspection sites and assets (towers/poles/spans) with a required vegetation clearance (meters) and geolocation.
• Flights — scheduled missions; flight status transitions reflect drone availability (a flying drone is in_flight; completion frees it).
• Imagery — geotagged image records (URI references + sensor + lat/lon/altitude), optionally tied to an asset.
• Detections — for vegetation detections with a measured clearance, severity and encroachment are auto-computed from the asset's required clearance (deficit ratio → info/low/medium/high/critical).
• Vegetation risk — vegetation_risk aggregates an asset's detections into a 0–100 score + level (worst deficit × confidence); risk_queue ranks the whole network.
• Remediation — flag_for_remediation dispatches a crew with a priority derived from severity (P1–P4); status lifecycle to completion.

Governance posture

• Two writes are physical actions and are gated (requires_approval, external_write): schedule_flight (commits a drone to fly — validates availability and ≥25% battery) and flag_for_remediation (dispatches a field crew). Recording imagery/detections and analytics are not gated.
• Sensible guards — flights are refused for unavailable or low-battery drones; remediation priority follows detection severity. Everything is on the audit trail (audit_log).
• Reads are read_only. Imagery is referenced by URI/handle, never raw bytes. Sample data is fictitious.

Tools (23)

Fleet (4)

register_drone · get_drone · list_drones · set_drone_status

Sites & Assets (4)

create_site · list_sites · create_asset · list_assets

Flights (4)

schedule_flight (gated, external) · get_flight · list_flights · set_flight_status

Imagery & Detections (5)

add_image · list_images · add_detection · get_detection · list_detections

Risk & Remediation (6)

vegetation_risk · risk_queue · flag_for_remediation (gated, external) · update_remediation · list_remediations · audit_log

Example

// Gated flight, then capture + analyze
{"name": "schedule_flight", "arguments": {"drone_id": "DRN-1001", "site_id": "SITE-1003", "purpose": "vegetation inspection"}}
{"name": "add_image", "arguments": {"flight_id": "FLT-1011", "asset_id": "AST-1004", "uri": "s3://imagery/spanA.jpg", "sensor": "lidar"}}
{"name": "add_detection", "arguments": {"image_id": "IMG-1012", "category": "vegetation", "measured_clearance_m": 1.8, "confidence": 0.97}}

// Risk + gated dispatch
{"name": "risk_queue", "arguments": {"min_score": 25}}
{"name": "flag_for_remediation", "arguments": {"detection_id": "DET-1013", "work_type": "vegetation_trim"}}

Install & run

cargo install mcp-drone-imagery
mcp-drone-imagery            # serves MCP over stdio

Or build from source:

git clone https://github.com/zavora-ai/mcp-drone-imagery
cd mcp-drone-imagery && cargo build --release
./target/release/mcp-drone-imagery

Registry manifest

server_id = "mcp_drone_imagery"
display_name = "Drone Imagery / Aerial Inspection"
version = "1.1.0"
domain = "energy-utilities"
risk_level = "high"
writes_allowed = "gated"

The full mcp-server.toml declares all 23 tools with risk classes and approval gates for registry onboarding.

License

Apache-2.0

rmcp and MCP compatibility

This server is built with rmcp 3.1.2 and requires Rust 1.94.1 or newer. The rmcp 3 rollout retains legacy MCP initialization compatibility and targets MCP protocol revisions 2025-11-25 and 2026-07-28.

MCP 2026-07-28 rollout (P4 workflow/business)

This server uses rmcp 3.1.2 and adk-mcp-sdk 0.2 with a minimum supported Rust version of 1.94.1. It accepts stateless MCP 2026 requests with per-request protocol, client identity, and capability metadata while retaining the legacy MCP 2025-11-25 initialize flow for ordinary tools.

• Tasks: None; this server's operations are short-lived and execute directly.
• MRTR approvals: schedule_flight, flag_for_remediation
• Discovery and routing: rmcp serves on-demand discovery and validates the per-request protocol envelope; HTTP deployments can route with Mcp-Method and Mcp-Name. The packaged binary currently uses stdio.
• Caching: tools/list returns a public ttlMs of 60,000 for MCP 2026; rmcp omits the cache fields for legacy clients.
• Deprecated extensions: this server does not add new Roots, Sampling, or dynamic client-registration dependencies.

Protected tools require MCP_REQUEST_STATE_KEY with at least 32 high-entropy bytes. All replicas must share that key so sealed approval state can resume on another instance. Approval state is bound to the client identity, tool, and arguments and expires after two minutes. Missing identity, invalid state, rejection, or legacy protocol use fails closed. Task records are process-local for the current stdio runtime; use a durable task store before deploying the server behind scale-to-zero HTTP infrastructure.