@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

set_primary_sub_account

Destructive

Set a sub-account as the primary account and automatically demote the previous primary to secondary; requires a configured Proof API key.

Instructions

Make a sub-account the primary one. The previous primary sub-account becomes secondary.

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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "profile_id": "<profile_id>"
    },
    "name": "set_primary_sub_account"
  }
}

Input Schema

Name	Required	Description	Default
`profile_id`	Yes	Profile ID to set as primary

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

A4.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds the specific side effect the agent could not infer: the previous primary sub-account is demoted to secondary. It also discloses the authentication requirement and the restart dependency. It does not say whether the demotion is reversible or how failures are reported, which keeps it from a 5.

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?

The behavioral statement is front-loaded in two short sentences, and the access precondition is separated into its own block. The uppercase ACCESS header and the instruction to restart the server are slightly verbose but each carries actionable information.

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?

For a one-parameter mutation with an output schema, the definition covers purpose, side effect, and auth gating, which is most of what an agent needs. The remaining gap is error or failure semantics, which the output schema may partially cover.

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?

There is a single parameter with 100% schema description coverage, so the schema already explains profile_id. The description adds no format, sourcing, or validation detail beyond that baseline.

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?

The first sentence names a specific verb and resource ('Make a sub-account the primary one') and the second states the resulting state change. This clearly distinguishes it from the sibling set_primary_email, set_primary_phone, and set_primary_profile tools, which operate on different resources.

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?

The ACCESS block gives concrete preconditions (a Proof account, PROOF_API_KEY set, server restart) and an explicit negative case ('start_login does NOT open this tool'), which is exactly the kind of guidance that prevents wasted calls. It stops short of naming an alternative path for users who lack the key, so it is clear context rather than full when/when-not routing.

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

Deploy Server