flightaware-mcp

fa_update_alert

Idempotent

Update an existing flight alert by replacing its configuration, such as filters and notification triggers. Confirmation is required; Standard or Premium AeroAPI tier needed.

Instructions

Update an existing flight alert (replaces its configuration). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview of the request (method, path, body) and a confirmToken, makes NO network call, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Requires a Standard or Premium AeroAPI tier (the free Personal tier returns 401).

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Alert id to update
`eta`	No	Notify on ETA changes
`hold`	No	Notify on hold
`filed`	No	Notify when a flight plan is filed
`ident`	No	Flight ident / designator to watch (e.g. UAL123)
`origin`	No	Origin airport code filter
`arrival`	No	Notify on arrival
`diverted`	No	Notify on diversion
`end_date`	No	ISO-8601 date the alert expires
`cancelled`	No	Notify on cancellation
`departure`	No	Notify on departure
`max_weekly`	No	Cap on notifications per week
`start_date`	No	ISO-8601 date the alert becomes active
`destination`	No	Destination airport code filter
`confirmToken`	No	ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.
`aircraft_type`	No	ICAO aircraft type filter (e.g. B738)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.2.0Sep 24, 2026

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true to proceed. Without this, the tool returns a preview.",
-  "type": "boolean"
-}

addedInput schema / properties / confirmToken

Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}

Changed1 schema field changedv1.0.0Sep 19, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv0.1.0Jun 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already carry idempotentHint/openWorldHint/readOnlyHint, and the description adds substantial behavior beyond them: the first call makes NO network call, the preview includes method/path/body, only a repeat call with confirmToken proceeds, and the operation replaces existing configuration. 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.

Conciseness4/5

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

Three sentences, front-loaded with the core purpose, then the confirmation flow, then the prerequisite. The middle sentence is long but every clause (preview contents, no network call, repeat-with-token) is necessary to prevent misuse.

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 16-parameter mutation with a two-phase confirmation protocol, the description covers purpose, confirmation mechanics, and entitlement. It doesn't describe the final response body on the confirming call, but with no output schema and a clear flow, an agent has enough to invoke it 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%, including a rich explanation of confirmToken semantics in the schema itself, so the description needn't repeat parameter details. The description connects confirmToken to the two-step flow but doesn't add per-parameter meaning beyond the schema, matching the baseline for full coverage.

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?

Description opens with 'Update an existing flight alert (replaces its configuration)' – a specific verb and resource that clearly states the operation. It is unmistakably distinct from siblings like fa_create_alert, fa_delete_alert, and fa_list_alerts.

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 provides concrete usage context: the confirmation flow (client prompt vs. preview+confirmToken fallback) and the tier requirement (free Personal tier returns 401). It doesn't explicitly name sibling alternatives or when-not-to-use conditions, but the 'existing' qualifier and detailed flow give solid guidance.

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

fa_update_alert

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools