Sentinel

Where an aircraft is right now, by callsign, hex address or tail number (paid, x402)

flights_lookup

Read-only

PAID: one live-flight lookup for $0.0100. Give a callsign, a 6-hex ICAO24 address or a tail number and get the aircraft's current position, altitude, ground speed, track and squawk in the same response the payment settles -- there is nothing to read back. No signup and no API key, ours or upstream, which is the whole product: every alternative live-flight API is a human signup plus a card. A malformed ident is refused FREE before the paywall, and an unreachable feed is refused FREE after it (the authorization is released, never settled) -- you pay only once the feed has answered. "Nobody with a known position is transmitting under that ident" IS an answer and does settle. Two airframes on one callsign is routine: you get the freshest and a matchCount saying how many there were. The data is ODbL 1.0 and the licence rides in every record -- adsb.lol community ADS-B feed, ODbL 1.0 -- keep it with the data. Call it once without payment to receive the price as an x402 PaymentRequired (Base USDC, and Solana USDC where offered); call it again with a signed payment in _meta['x402/payment'] to complete it. The receipt comes back in _meta['x402/payment-response']. No account, no API key. Complaints, questions, quote requests, or a service you wish we had: POST /feedback on this host -- free, no account. Every report is read and analysed daily; there is no individual reply.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ident": "<ident>"
    },
    "name": "flights_lookup"
  }
}

Input Schema

Name	Required	Description	Default
`ident`	Yes	One aircraft identifier: a callsign (UAL1), a 6-hex ICAO24 address (a0b1c2) or a registration (N12345, D-ABCD). Prefix cs:, hex: or reg: to say which kind it is -- unprefixed, a 6-hex-looking string is read as a CALLSIGN. Lowercase is fine.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only say read-only/non-destructive; the description adds the entire economics and failure model: $0.0100 price, paywall ordering, authorization released vs settled, ambiguous callsigns returning the freshest match plus matchCount, ODbL 1.0 licence riding in each record, and where the receipt appears. This is exactly the context an agent cannot get from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The critical facts (price, inputs, outputs, payment flow) are front-loaded, but the text is a single long run-on block that mixes product positioning ("every alternative live-flight API is a human signup plus a card") and a feedback-channel pitch that has no bearing on invoking this tool. It is informative but noticeably bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing returns, and it does: position, altitude, ground speed, track, squawk, matchCount, and the embedded licence. Combined with the payment handshake and free-failure rules, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already documents the cs:/hex:/reg: prefixes and the unprefixed-6-hex-reads-as-callsign rule, so the description repeats some of that. It still adds real meaning: a malformed ident is rejected free, and a shared callsign yields the freshest airframe with a matchCount, which tells the caller how to interpret an ambiguous input.

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?

States a specific verb and resource up front: "one live-flight lookup" taking "a callsign, a 6-hex ICAO24 address or a tail number" and returning "current position, altitude, ground speed, track and squawk." No sibling tool covers live flight data, and the scope (single aircraft, live position) is unambiguous.

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?

Gives explicit procedural guidance: call once without payment to receive the x402 PaymentRequired, call again with a signed payment in _meta['x402/payment'] to complete it. It also clarifies which failures are free (malformed ident, unreachable feed) versus billable (ident not transmitting). It stops short of naming sibling tools to use instead, but none are close substitutes.

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

All Sentinel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?