@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

send_account_email

Delivers the verification email for an email-channel account-bootstrap session, after the user confirms the address is theirs. Call it explicitly as a second step; each session sends at most one email.

Instructions

Deliver the verification email for an account-bootstrap session created with channel "email". Public endpoint (no API key required).

Why this is a separate call: create_account deliberately sends NOTHING. A message from proof.holdings arriving in someone's inbox is an act with a person on the other end, so it takes an explicit second step rather than being a side effect of creating a session. ASK THE USER to confirm the address is theirs before calling this — do not call it automatically after create_account.

The other channels (telegram, whatsapp, sms) never need this: the user sends the first message themselves (reverse OTP), so nothing is dispatched to them at all.

One session sends at most one email, including under concurrent calls. A repeat answers 410 already_sent, which means the material backing the send is gone: usually because the email went out, occasionally because an attempt was interrupted mid-send and nothing was delivered. Do not tell the user a message was sent on the strength of a 410 — create a new session instead. (A session the recipient cancelled via the decline link, or an expired one, answers 404, not 410.) If delivery fails the response carries email_sent=false and the call can be retried.

Input Schema

Name	Required	Description	Default
`id`	Yes	Account session id from create_account

Output Schema

Name	Required	Description	Default
`id`	No
`channel`	No
`email_sent`	No
`email_error`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.7.2Nov 6, 2026

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

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "channel": {},
+    "email_error": {},
+    "email_sent": {},
+    "id": {}
+  },
+  "type": "object"
+}

First observedv1.1.0Sep 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only say readOnlyHint=false / destructiveHint=false, so the description carries most of the weight and delivers: an irreversible external send (a human receives mail), one email per session even under concurrency, 410 already_sent semantics, 404 for cancelled/expired sessions, and email_sent=false meaning retry is safe. It doesn't mention rate limits or auth-scope details beyond "public endpoint", but the failure-mode mapping is unusually rich.

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?

Front-loaded with the action and the caller's confirmation obligation; the parenthetical about 404 vs 410 and the retry rule are load-bearing. The "Why this is a separate call" rationale paragraph is defensible design context but is the one part that could be trimmed.

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?

An output schema exists, yet the description still explains the error-status meanings and the email_sent flag that an agent must branch on. Combined with the preconditions, the caller has everything needed to decide whether and how to call it.

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% and the single parameter is already documented as "Account session id from create_account", so baseline is 3. The description adds a qualifying constraint the schema lacks: the id must come from a session created with channel "email", and a consumed session cannot be reused.

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 and resource ("Deliver the verification email") scoped to "an account-bootstrap session created with channel 'email'". It explicitly separates itself from create_account and from the other channel flows, so an agent can distinguish it from siblings without opening a schema.

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?

Gives an explicit when: only after asking the user to confirm the address, and explicitly when-not: "do not call it automatically after create_account" and "the other channels never need this". It also names the sibling behavior it must not be conflated with.

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

Deploy Server