@proof-holdings/mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

update_public_page

Destructive

Update the selected sub-account's public profile page, covering display name, bio, avatar, theme, custom links, and verification display settings.

Instructions

Update the record get_current_sub_account reads: a sub-account key's own sub-account, otherwise the primary sub-account (never creates one). Takes presentation fields only — display name, bio, avatar, theme, custom links, and verification display settings; business details, the primary flag and email branding go through update_sub_account. In the dashboard, the Profile page (https://proof.holdings/profile) edits whichever sub-account is selected there.

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

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 (HTTPS URL or base64 data URI, null to remove)
`custom_links`	No	Custom links (max 20)
`display_name`	No	Display name
`show_delegations`	No	List the published, in-force delegations for the domains the profile shows (default true)
`show_proof_channels`	No	Show proof channels
`show_verification_dates`	No	Show verification dates

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

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description adds real context on top: it will never create a sub-account, it is restricted to presentation fields, and it requires configured credentials. What it does not disclose is mutation semantics an agent would want under destructiveHint=true — e.g. whether the custom_links array is replaced wholesale or merged, and whether omitted fields are left untouched or cleared.

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 compact paragraphs: scope first, then access, which is the right front-loading order. The opening clause 'Update the record get_current_sub_account reads' is awkward enough to require a second pass, and the dashboard URL reference is arguably decorative. No sentence is fully wasted, but the first one could be tightened.

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?

An output schema exists, so return values need no explanation, and the description covers the remaining essentials: target selection, field scope, sibling routing, and auth requirements. For a tool with nested objects and destructiveHint=true, the one meaningful omission is merge-versus-replace behavior for theme and custom_links.

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 schema coverage at 100% across all 9 parameters, the schema already carries the field-level meaning, so the baseline of 3 applies. The description adds a useful grouping ('display name, bio, avatar, theme, custom links, and verification display settings') and, more valuably, names categories that are deliberately absent, steering the agent away from inventing business-detail parameters. It stops short of explaining replacement or null-clearing behavior for the nested theme and links objects.

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?

States a specific verb and identifies the exact target: 'the record get_current_sub_account reads: a sub-account key's own sub-account, otherwise the primary sub-account (never creates one)'. It also explicitly separates its territory from update_sub_account, so an agent can distinguish the two mutation tools. The phrasing is indirect (defining the target by reference to another tool) rather than naming it outright, which keeps it short of a 5.

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?

Gives concrete routing guidance: presentation fields go here, while 'business details, the primary flag and email branding go through update_sub_account'. It also states the access precondition (PROOF_API_KEY + server restart) and explicitly rules out start_login as an entry point, which prevents a common wrong-path attempt. It does not address other profile-editing siblings such as update_my_profile or update_profile, leaving some ambiguity in the broader catalog.

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

Deploy Server