Ring your paired phone (find_my_phone)
Sends a high-priority “ring” command to your paired phone over FCM so you can locate it — the find_my_phone MCP tool’s backing endpoint.
Fire-and-forget by design (spec D10). There is no queue entry and no retry: a phone that was off or offline when this fired must not suddenly ring an hour later, so an undeliverable command is dropped, not queued. The endpoint always returns 202 once the request is accepted — the server has no delivery receipt for FCM, so it cannot confirm the phone actually rang.
Reachability is instead surfaced honestly via warnings: an empty/absent array means the phone had a push registration and the FCM send was accepted; a non-empty array (e.g. "phone has no push registration — may be unreachable") means the ring may never arrive. This is not a delivery guarantee either way — only the best information the server has.
Owner-scoped and phone-only. {deviceId} must be the caller’s own device id and must be a phone-kind device — a non-phone id returns 409 no_phone_device. A foreign or unknown id is indistinguishable from 404 not_found: cross-tenant device existence is never confirmed. Requires the phone:control scope (403 insufficient_scope otherwise) and is charged against the same per-token send-class limits as POST /v1/interactions.
Phone-capability gate. If the paired phone’s reported app build predates ring support, the request is refused outright (426 phone_app_outdated) rather than accepted and silently dropped as an unrecognized FCM message. A phone that has never reported its version rings anyway, with a warnings entry naming the uncertainty.
Authorizations
Opaque bearer token created on your paired Android phone. The format is rfk_live_ followed by 32 URL-safe alphanumeric characters (≥160 bits of entropy). Test tokens use the rfk_test_ prefix.
Path Parameters
The phone device id to ring — must be the caller's own paired phone.
"dev_9af3"
Response
Ring command accepted. Whether it will actually reach the phone is reported in warnings, not the status code.
Always "requested" — the ring is fire-and-forget (D10): the server never learns whether the phone actually rang, only whether the FCM send was attempted.
requested "requested"
Caveats about this ring, present for either of two independent reasons: the target phone had no push registration (or the FCM send failed) — the ring may never arrive — OR the phone's reported app version is unknown (see the phone-capability gate above), in which case the ring is still sent but the uncertainty is named here. The second reason can appear even after a fully successful send, so a non-empty array is not itself a failure signal; omitted entirely only when neither caveat applies, and even then its absence is not a delivery guarantee, only a lack of a known reason it would fail.