@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

create_account

Start an account-bootstrap verification session for email, SMS, Telegram, or WhatsApp; returns session ID, channel instructions, and QR/deep links for agent-driven onboarding.

Instructions

Create an account-bootstrap session for agent-driven onboarding. Public endpoint (no API key required). Returns a session id, channel-specific instructions, and — FOR TELEGRAM AND WHATSAPP ONLY — deep_link, qr_code (base64 PNG) and qr_text (UTF-8 text QR).

The endpoint is safe to call regardless of whether the submitted identity is new: completing verification transparently creates a User when none exists, or logs the user in when one already does. The response is intentionally uniform — the server does NOT reveal whether the identity is already registered (this would be a user-enumeration oracle). If the agent needs to distinguish new-vs-returning users, call get_current_user after verification and inspect the user's created_at.

EMAIL CHANNEL SENDS NOTHING HERE. The response carries email_sent=false and send_required=true: confirm with the user that the address is theirs, then call send_account_email. The other channels dispatch nothing either way — the user sends the first message themselves (reverse OTP).

Agent usage: (1) Call create_account with the user's chosen channel. (2) For email, confirm with the user and call send_account_email. On telegram/whatsapp pass deep_link to render_auth_link, which returns the clickable link with a QR code beneath it to you. On sms deep_link is an EMPTY STRING and render_auth_link will reject it — show sms_message, which is what the user sends; this response carries no destination number, so do not invent one. Do not hand qr_text to a link renderer either — it is the link already rendered as QR art; print it verbatim inside a fenced code block if a real terminal needs the QR. (3) Once your reply shows the user the challenge, call wait_for_account_creation with the session id until verification completes. On email the user must press "Sign in the browser that requested this" on the link's page — "Sign in here" signs in the browser they clicked from, and the wait then ends with "completed_elsewhere". (4) On verified, JWT + refresh cookies are set; proceed with whatever follow-up the agent was asked to do.

The user does not see tool results — most clients fold them away, render_auth_link's output included. Before you wait or poll, put what the user must act on into your own reply text: the link itself (not a sentence announcing it), the SMS text and number, or a note to check their inbox.

Input Schema

Name	Required	Description
`email`	No	Email address. Required for email channel.
`channel`	Yes	Authentication channel the user will verify through
`phone_number`	No	E.164 phone number. Required for SMS channel (determines DID routing).

Output Schema

Name	Required	Description
`id`	No
`type`	No	Outcome of an account-session creation. `account_creation` means a new User will be written on verification. `login` indicates the submitted identity matched an existing User and the session will log them in.
`email`	No
`status`	No	Status of an auth session. `completed_elsewhere` (terminal, no cookies): an email sign-in the person completed in ANOTHER browser by pressing "Sign in here" on the link's page — this session will never become `verified`.
`channel`	No	Authentication channel
`qr_code`	No	Base64-encoded PNG QR code for the deep link
`qr_text`	No	UTF-8 text QR for terminal/agent rendering
`user_id`	No
`sms_code`	No	Short code for SMS-channel reverse-OTP
`deep_link`	No
`created_at`	No
`email_sent`	No
`expires_at`	No
`email_error`	No
`sms_message`	No
`verified_at`	No
`instructions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.7.2Nov 6, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / email / pattern

Added value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "channel": {
+      "description": "Authentication channel"
+    },
+    "created_at": {},
+    "deep_link": {},
+    "email": {},
+    "email_error": {},
+    "email_sent": {},
+    "expires_at": {},
+    "id": {},
+    "instructions": {},
+    "qr_code": {
+      "description": "Base64-encoded PNG QR code for the deep link"
+    },
+    "qr_text": {
+      "description": "UTF-8 text QR for terminal/agent rendering"
+    },
+    "sms_code": {
+      "description": "Short code for SMS-channel reverse-OTP"
+    },
+    "sms_message": {},
+    "status": {
+      "description": "Status of an auth session. `completed_elsewhere` (terminal, no cookies): an email sign-in the person completed in ANOTHER browser by pressing \"Sign in here\" on the link's page — this session will never become `verified`."
+    },
+    "type": {
+      "description": "Outcome of an account-session creation. `account_creation` means a new User will be written on verification. `login` indicates the submitted identity matched an existing User and the session will log them in."
+    },
+    "user_id": {},
+    "verified_at": {}
+  },
+  "type": "object"
+}

First observedv1.1.0Sep 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: public endpoint, deliberately uniform response to avoid a user-enumeration oracle, email channel sends nothing (email_sent=false / send_required=true), SMS returns empty deep_link that render_auth_link rejects, and JWT + refresh cookies are set on completion. It also warns that most clients fold tool results away, which is operational context no annotation could carry.

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

Conciseness4/5

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

Purpose is front-loaded and the workflow is laid out as a scannable numbered sequence with reserved-capital emphasis on critical facts. It is on the long side, and a few asides (e.g. "The other channels dispatch nothing either way") could be tightened without losing meaning.

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?

For a multi-step, channel-varying, side-effect-bearing bootstrap call, nothing an agent needs is missing: return payload per channel, verification semantics, post-verification state, and the requirement to surface output in the agent's own reply text. Output schema exists, yet the description still adds the interpretation an agent needs.

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%, so baseline is 3; the description earns above that by explaining channel-dependent requirements — email address for the email channel, E.164 phone for SMS DID routing, and which channels return deep_link/qr versus sms_message.

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+resource ("Create an account-bootstrap session for agent-driven onboarding") and immediately scopes it as a public, no-API-key endpoint. It also names its workflow companions (send_account_email, render_auth_link, wait_for_account_creation, get_current_user), which separates it from the many sibling session/login tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit numbered agent workflow, states when to call the alternative (get_current_user after verification to distinguish new vs. returning users), and gives negative guidance (don't hand qr_text to a link renderer, don't invent a destination number for SMS, don't wait before showing the user the challenge).

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

Deploy Server