Skip to main content
Glama
ProofHoldings

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

send_account_email

Delivers the verification email for an email-based account session. Call only after the user confirms the address is theirs to complete email verification.

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

TableJSON Schema
NameRequiredDescriptionDefault
idYesAccount session id from create_account

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes well beyond by disclosing the public/no-API-key endpoint, the one-email-per-session invariant, the 410 already_sent semantics (material gone, do not claim delivery), the 404 for cancelled/expired sessions, and the email_sent=false retryable failure mode.

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 in the first sentence and the when/when-not routing follows immediately. It is longer than typical, but the length is spent on genuinely load-bearing idempotency and error semantics rather than filler, so the density justifies most of it.

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?

No output schema exists, yet the description explains the meaningful response outcomes (410 already_sent, 404, email_sent=false) and the retry path. For a one-parameter send tool, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single well-documented parameter ('Account session id from create_account'), so the schema carries the parameter semantics. The description reinforces the id's origin but adds no format or syntax detail beyond it, making the baseline 3 appropriate.

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 for an account-bootstrap session created with channel 'email'. It explicitly distinguishes itself from create_account and from the other channel flows, so an agent can identify its role without opening the 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?

Explicit when-to-use (session created with channel 'email'), when-not (telegram/whatsapp/sms sessions never need it), and a hard procedural instruction to confirm the address with the user rather than call it automatically after create_account. Nothing is left to inference.

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

Deploy Server

Other Tools