@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

create_sub_account

Destructive

Creates a new sub-account with optional display name, bio, avatar, business info, email branding, and theme settings so you can manage separate Proof profiles.

Instructions

Create a new sub-account with optional display name, bio, avatar, business info, email branding (theme, support email), and theme settings.

ACCESS: needs a Proof account. Set PROOF_API_KEY and restart this server, then call this tool again. start_login does NOT open this tool.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_sub_account"
  }
}

Input Schema

Name	Required	Description
`bio`	No	Profile bio
`theme`	No	Profile theme settings
`is_public`	No	Whether the profile is publicly visible
`avatar_url`	No	Avatar as base64 data URI or URL (~75KB limit)
`is_primary`	No	Set as primary profile
`email_theme`	No	Theme of this sub-account's emails
`is_business`	No	Whether this is a business profile
`display_name`	No	Display name
`business_name`	No	Business name
`support_email`	No	Support email this sub-account's messages show

Output Schema

Name	Required	Description
`id`	Yes	MongoDB ObjectId
`bio`	No
`theme`	Yes	Profile theme customization
`username`	No	Absent until a username is claimed
`is_public`	Yes
`avatar_url`	No	A URL or a data URI; null once cleared
`created_at`	Yes
`is_primary`	Yes
`profile_id`	Yes	The public id used in profile URLs
`updated_at`	Yes
`view_count`	Yes
`email_theme`	Yes	Theme of this sub-account's emails; null when unset (read as `dark`).
`is_business`	Yes
`name_review`	Yes	Why a typed name is left out of the public reads: it reads as a protected brand's own, until a domain of that brand is checked. Null when nothing is held.
`proof_order`	Yes	Who decided the order of a profile's proofs. `default`: domain, social account, Telegram bot, email, phone, wallet, then each proof's `display_order`. `owner`: the owner's `display_order` alone — send it when the owner reorders. The first shown proof that is not hidden leads the profile's preview card, share tags and badge. Omitted on an update, the profile keeps its current setting.
`custom_links`	Yes
`display_name`	No
`business_name`	No
`name_headline`	Yes	Why a published name may not lead the page (it carries a protected brand word); it leads only when an OV/EV certificate names it. Null when not demoted.
`public_proofs`	Yes	The shown proofs, in the order the public profile shows them
`support_email`	Yes	Support address shown in this sub-account's messages; null when unset.
`show_delegations`	Yes
`channels_complete`	Yes	The owner's statement that the channels listed are all of theirs.
`verification_level`	Yes	Always 'basic'; no levels are computed; removed in the next major.
`show_proof_channels`	Yes
`username_is_default`	No	The username was given automatically (from the domain the profile shows, else its short id); the owner may replace it once with a name of their choice.
`show_verification_dates`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.10.0Nov 13, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation profile is known; the description adds genuinely useful runtime context about auth setup and the login workaround failing. However it never discloses side effects an agent should anticipate, such as whether is_primary displaces an existing primary sub-account, any cap on sub-account count, or whether creation is idempotent.

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?

Two short blocks: purpose first, hard access prerequisite second, with the most failure-prone fact ('restart this server, then call this tool again') stated plainly. No filler, though the optional-field enumeration in sentence one is somewhat redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Ten parameters are all optional, an output schema exists so return values need no explanation, and annotations carry safety. The remaining gap is behavioral: with zero required fields an agent would benefit from knowing what a bare invocation produces (default display name, public/private default), which the description omits.

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 description coverage is 100% across all 10 parameters including the nested theme object, so the schema already carries the semantics. The description's field list only mirrors the schema's own groupings rather than adding format, default, or interaction rules, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Create a new sub-account') and enumerates the optional payload groups (display name, bio, avatar, business info, email branding, theme settings), so an agent knows exactly what will be produced. It does not distinguish this from sibling creators such as create_account or create_profile, leaving that disambiguation to the agent.

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

Usage Guidelines4/5

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

It gives an explicit precondition for invocation (a Proof account plus PROOF_API_KEY set and server restart) and explicitly rules out one tempting alternative path by stating 'start_login does NOT open this tool.' What is missing is guidance on choosing between this and the update/create siblings, so it stops short of the full when/when-not/alternatives bar.

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

Deploy Server