start_login
shallowholdings.proof/mcp-server · Verify this server
Start a login session by sending an authentication challenge to the user's chosen channel (Telegram, WhatsApp, SMS, or email). Returns a session ID and, FOR TELEGRAM AND WHATSAPP ONLY, deep_link, qr_code (base64 PNG) and qr_text (UTF-8 text QR for terminal display); on sms it returns sms_message with sms_dids instead, and on email nothing to display. Agent usage: (1) Call start_login with the desired channel and phone_number (for SMS) or email (for email). (2) Present the challenge, and WHICH FIELD depends on the channel. On telegram/whatsapp pass `deep_link` to render_auth_link, which prints the clickable link and a QR code; in a chat client the link is what the user acts on, since they are usually on the same machine. On sms `deep_link` is an EMPTY STRING and render_auth_link will reject it — show `sms_message` and let the user pick a number from `sms_dids`. `suggested_region` is always set, but the matching ENTRY in `sms_dids` may be missing (europe and israel appear only when a number is configured) or present with an empty `did`, so offer that region first only when `sms_dids[suggested_region]` exists and carries a number, and otherwise offer whatever the object does. On email there is nothing to display at all, and nothing to check either: a result means the mail was accepted for delivery, so tell the user to open their inbox. A delivery failure is an ERROR here, not a field — the tool answers `challenge_delivery_failed` and NO session exists, so do not call wait_for_login; retry, or offer another channel. Never hand `qr_text` to a link renderer — it is the link already rendered as QR art, so print it verbatim inside a fenced code block or not at all, because its rows stop scanning the moment one wraps or a blank line lands between them. (3) Call wait_for_login with the returned session ID to poll until the user completes authentication. Terminal states: "verified" (login succeeded), "failed", "expired".
1 trials · measured 14 days ago
start_login scores 100.0/100 on Vouch's measured behaviour index, from 1 real invocation trials against holdings.proof/mcp-server, measured 23 Sept 2026 under methodology v0.2.0. Every measured component scored 100.
Component breakdown
| Component | Weight | Value |
|---|---|---|
| Reliability | 35% | not applicable |
| Schema integrity | 25% | 100.0 |
| Failure behaviour | 15% | not applicable |
| Latency | 15% | not applicable |
| Concurrency | 10% | not applicable |
Tool details
- Transport
- remote + stdio
- Credential class
- gated
- Input schema
- not declared
- Output schema
- not declared
- Side-effect classification
- unclassified
Score history
| Day | Score | Tier | Methodology |
|---|---|---|---|
| 2026-09-23 | 100.0 | shallow | v0.2.0 |
Probe evidence
| Probe | Outcomes |
|---|---|
| schema_integrity | pass: 1 |
Raw request/response logs are not archived yet — the outcome counts above are drawn directly from every recorded trial.
Embed this score
Available for every tool, scored or not — not a verification perk. Always links back to this page.
[](https://vouch.tools/tools/3e3c8048-9370-4787-a003-b4cd791ab463)