Sections

The whole reference in one file for agents: llms-full.txt, and as openapi.json.

API reference

MCP

A hosted MCP server for agents that speak the Model Context Protocol (Claude Code, Cursor, Claude Desktop and others): thirteen tools shaped around the questions dispatch and flight planning ask, over the same data, rules and keys as the REST API.

  • URL: https://api.bravoecho.ai/mcp. Streamable HTTP, stateless: each POST gets one JSON answer; there is no session and no server stream (GET is 405).
  • Auth: the same organisation key as /v1, as Authorization: Bearer $BRAVOECHO_KEY. A missing or invalid key is a 401 with WWW-Authenticate: Bearer.
  • What counts: each tools/call that reaches a tool is one request, like one /v1 call, whatever the tool answers, and shows in the console's usage as MCP <tool>. Connecting (initialize), tools/list, ping and notifications are free and never refused for quota; so is a call naming a tool that does not exist. Only the RAIM tools (raim_route_check, raim_predict) and the RAIM part of flight_briefing are counted; the others are beta, recorded and free. flight_briefing counts one request per part it runs, as POST /v1/briefing does, shown as MCP flight_briefing (raim) and so on. At the monthly cap a RAIM tool call is refused with HTTP 429 quota_exceeded, as on /v1. The per-minute rate limit covers every request.
  • Flight: the route tools (and flight_briefing) take the whole flight object (see Flight object) exactly as POST /v1/raim/route, /v1/notams/route and /v1/weather/route do, so one object goes to all three unchanged: each uses what it needs, accepts the rest and refuses what the endpoint refuses, with the same error. A waypoint may also give an airport code in id instead of lat and lon.
  • Answers: a lead sentence, then compact JSON, typically 1 to 12 KB. For the route tools the lead is the endpoint's summary, for points a one-line verdict, for airport weather one line per airport; show it to people as it is. Times are UTC. A failure is a tool error (isError: true) whose text is the API's error, {"error": code, "message": text}.

Tools:

  • raim_route_check: RAIM along a flight. route as filed or waypoints, departure, speed_kt, window_minutes (default 60 here: how far the departure may slip each side), step_seconds, profile, and for a route string cruise_fl or cruise_alt_m (cruise_fl: 350 flies at 10,668 m) and phase or hal_nm; waypoints carry their level as alt_m, alt_ft or fl, flown in metres, and codes are accepted and not used. Returns the verdict, the planned flight's outages with time and place, the departure window with its clean and blocked ranges, the fixes with their times and the per-fix window failures. As POST /v1/raim/route.
  • flight_briefing: RAIM, NOTAMs, weather and airspace for one flight in one call, as POST /v1/briefing in its compact form: the same flight object as the route tools, parts (default all four), window_minutes (default 60 here) and profile for the RAIM part, alternates for the weather part. The lead is the four summaries, RAIM first; then the RAIM dispatch verdict, outages and departure window, the first 30 NOTAMs along the route with their full text and place on the route (notams_omitted counts the rest; notams_along_route filters and lists more), the weather hazards and aerodromes, and the airspace entered (the first 25; airspace_along_route lists more). Each part counts as one request of its service; today only the RAIM part is counted.
  • raim_predict: RAIM at 1 to 100 points, window_minutes (default 60) each side of each point's time. A point may give an airport code in id instead of lat and lon. As POST /v1/raim/predict.
  • notams_along_route: NOTAMs along a route string or waypoints, in force between from and to, or from departure to the arrival at speed_kt, with an optional flight level band (fl_from, fl_to), categories and q. Without from and to, waypoint times or departure and speed_kt give the window. Levels (alt_m, alt_ft, fl, cruise_fl, cruise_alt_m) and RAIM's phase and hal_nm are accepted and not used. The lead is the API's summary, then what the list shows. Lists 25 by default (limit up to 100): the ones placed on the track and airspace, hazard and runway notices first, in order along the track with placement and chainage, text cut to its start; the counts cover every match. As POST /v1/notams/route.
  • notams_search: NOTAMs by location, fir, bbox, lat/lon/radius_nm, number, q or categories, in force between from and to or the live set, newest first. A search by number returns the whole text. As GET /v1/notams.
  • weather_along_route: weather along a flight: route as filed or waypoints, departure, speed_kt, the cruise level (cruise_fl or cruise_alt_m) for a route string, alternates, and optionally half_width_nm, pireps, as_of. RAIM's phase and hal_nm, at the top level or on waypoints, are accepted and not used. A waypoint may give an airport code in id instead of lat and lon: it is that aerodrome, and as the first or last point it sits at field elevation when another point has a level. The lead is the API's summary; then the hazards that affect the flight with their spans in NM, time and level, the ones in the corridor that are clear and why, the count of unplaced ones, the aerodromes (METAR and TAF text and categories for the time the aircraft is there), pilot reports, the flight as placed, the route's notes and the archive's caveats. Long lists are cut with a count of what was left out. As POST /v1/weather/route.
  • weather: METAR and TAF for 1 to 20 airports (ICAO, IATA or FAA codes), the latest or at a time (at: the latest METAR observed at or before it and the TAF in force then). One line per airport, then per airport the decoded METAR and TAF (with its worst group, over its validity or at at) and their text, the codes with nothing found or read as another station, and the archive's caveats. As GET /v1/weather/metar and GET /v1/weather/taf, in one call and one request.
  • winds_along_route: the wind and temperature at the flight's levels and times (United States, Alaska, Hawaii, the Pacific; FB forecasts): the same flight object, step_nm (default 50 here), tas_kt and as_of. The lead is the API's summary; then the totals (average headwind component, strongest wind, ISA deviation, with tas_kt the times), the legs from fix to fix, the samples along the track (up to 60), the forecasts used and the caveats. As POST /v1/weather/winds/route.
  • airspace_along_route: the special use airspace, Class B, C and D airspace and TFRs a flight enters (United States): the same flight object as the other route tools, half_width_nm (default 5) and kinds. The lead is the API's summary; then the airspaces entered in order along the track with their limits as published and the stretches where the aircraft is inside (NM, times, levels), times of use and, for a TFR, its NOTAM number, rule, effective times and text; the ones near the track with why the flight stays out (clear_by); TFRs with no published shape, each with its scope (an ARTCC the route passes through, or national); the flight as placed; the sources and caveats. As POST /v1/airspace/route.
  • mass_and_balance: weight and centre of gravity at ramp, takeoff, landing and zero fuel from the aircraft data you give, checked against its limits and envelopes. As POST /v1/planning/mass-balance, the same request; the lead is its summary.
  • navlog: the legs of a flight with course and heading, true and magnetic, wind, ground speed, time, fuel and ETA, and the fuel plan, from the aircraft performance you give and the winds aloft. As POST /v1/planning/navlog, the same request; the lead is its summary.
  • airport: one airport by ICAO, IATA, GPS or local code, with runways and frequencies. As GET /v1/airports/{code}.
  • resolve_route: the points a route string stands for, with its notes and the AIRAC cycle used. As GET /v1/routes/resolve.

Claude Code:

claude mcp add --transport http bravoecho https://api.bravoecho.ai/mcp --header "Authorization: Bearer $BRAVOECHO_KEY"

Cursor (~/.cursor/mcp.json) and other clients whose configuration takes a URL and headers:

{
  "mcpServers": {
    "bravoecho": {
      "url": "https://api.bravoecho.ai/mcp",
      "headers": { "Authorization": "Bearer <key>" }
    }
  }
}

Claude Desktop (claude_desktop_config.json), through the mcp-remote bridge (needs Node.js):

{
  "mcpServers": {
    "bravoecho": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://api.bravoecho.ai/mcp", "--header", "Authorization:${AUTH_HEADER}"],
      "env": { "AUTH_HEADER": "Bearer <key>" }
    }
  }
}

Keep the key in the client's configuration or environment, never in a repository.