RecallRadar

Each tool targets a distinct operation on a distinct resource: single-record fetch by id (recalls_get), filtered query (recalls_search), and static registry metadata (recalls_sources). There is no plausible way for an agent to confuse these, and the descriptions reinforce the boundaries (e.g. search explicitly excludes FDA/vehicle recalls).

All three tools share a clear `recalls_` namespace prefix, which makes the set instantly recognizable. However, `recalls_get` and `recalls_search` are verbs while `recalls_sources` is a noun, a minor deviation from a strict verb_noun pattern.

Three tools is thin but well-matched to a read-only lookup service: search to discover, get to expand, sources to attribute. Nothing appears redundant, though the surface is minimal enough that a single missing operation would noticeably weaken it.

The read-only lifecycle (discover -> retrieve detail -> verify provenance/licence) is fully covered with no dead ends, and provenance is embedded in every field. The main gap is that search caps at 100 results with no pagination or cursor tool, so broad queries can silently truncate results an agent cannot page through.