The local stdio server published as
@reflecto/mcp on npm is sunset. The hosted
connector below is the supported path. The published 0.1.1 still works — it is a thin
client over the unchanged Send API — but it receives no further
releases.Connect
The connector lives at:Claude Code
Claude (web and desktop)
Go to Customize → Connectors, click +, then Add custom connector, and enter the URL above. Anthropic documents custom connectors on Free, Pro and Max as well as Team and Enterprise. On Team and Enterprise the path is Organization settings → Connectors and only an Owner can add one.Any other MCP client
It is an ordinary remote MCP server speaking OAuth 2.0 with dynamic client registration, so any client supporting custom remote MCP connectors can point at the same URL.Approve it from your phone
You are not asked for an API key. The connector has none. Authorising it shows a six-digit code. Open Reflecto on your Android phone and approve the connection with that code — the same thing you do when pairing a computer. The connector holds a grant your phone issued, and your phone can revoke it under Settings → Connected services.Tools
Which tools a connector sees depends on the scopes its token was granted. New connectors are granted all six scopes when you approve them. A connector you authorised earlier keeps the narrower set it was granted then, until you reconnect it.
Reminders fire around the time you asked for, not to the second: Reflecto schedules them
without the exact-alarm permission, which Android grants sparingly and which a notification
app has no honest claim to.
Two numbers worth knowing about the ask-and-wait pair: a question stays open for ten
minutes by default (the assistant may request up to a day), and each
check_reply poll
waits up to 45 seconds before returning so the client does not time out.
send_notification parameters
What the server can see
Messages sent through MCP are not end-to-end encrypted, and it would be misleading to imply otherwise. Your assistant is not one of your paired devices and holds no keys, so there is nothing on the sending side to encrypt with. The server composes the message, holds it in memory only long enough to encrypt it separately to each of your devices, and never writes it to disk. This is the same trust model as the public Send API, and it is the documented exception to the end-to-end encryption that covers traffic between your own devices. See the threat model and the privacy policy. Practically: fine for “deploy finished, 3 tests failed” and “shall I force-push?”. Do not have an assistant send secrets through it.Notes
- Same auth, limits, rate limits and errors as the public Send API.
- You need an Android phone: it holds your keys and anchors the account.