@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

get_sub_account

Read-only

Retrieve one sub-account's full details by profile ID, including theme, custom links, and verification display settings; requires a Proof account and API key.

Instructions

Get one sub-account by ID, with its full details including theme, custom links, and verification display 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

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": "get_sub_account"
  }
}

Input Schema

Name	Required	Description	Default
`profile_id`	Yes	Profile ID

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.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered, and the description adds meaningful context beyond that: an authentication/configuration requirement and the explicit note that start_login does NOT unlock this tool, which prevents a plausible failure loop. It doesn't discuss rate limits or error behavior, but an output schema exists so return values needn't be described here.

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, front-loaded paragraphs: purpose first, then the access constraint. Every sentence carries information; only minor redundancy in separating the key requirement and the start_login caveat into a separate block.

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 read tool with an output schema, the definition covers purpose, the returned detail categories, and the authentication prerequisite. The remaining gap is how a caller obtains a valid profile_id, which is a small but real omission.

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?

With a single parameter at 100% schema description coverage, the schema already documents profile_id, and the description only adds that it is an ID lookup. It does not say where profile_id comes from (e.g., list_sub_accounts), which would be the one genuinely additive detail available.

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 states a specific verb and resource ('Get one sub-account by ID') and enumerates the detail areas returned (theme, custom links, verification display settings). The 'by ID' phrasing implicitly separates it from get_current_sub_account and list_sub_accounts, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

It gives a real access precondition (Proof account + PROOF_API_KEY, restart the server) and explicitly rules out start_login as a route to this tool, which is useful when-to-use guidance. However it never states when to fetch a sub-account by ID versus using get_current_sub_account or list_sub_accounts, so alternative selection 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