Skip to main content
Glama
Sign In
@proof-holdings/mcp-server

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

claim_username

Claim a unique username for the authenticated user's public profile. Validates 3–30 alphanumeric and underscore characters to ensure a valid profile handle.

Instructions

Claim a unique username for the authenticated user's public profile. Usernames must be 3-30 characters, alphanumeric and underscores only.

ACCESS: needs a Proof account. Set PROOF_API_KEY and restart this server, or sign in with start_login — a session opens this tool — then call this tool again.

Input Schema

NameRequiredDescriptionDefault
usernameYesUsername to claim (3-30 chars, alphanumeric and underscores)

Output Schema

NameRequiredDescriptionDefault
usernameYes
profile_urlYesPath of the public profile
username_claimed_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.2
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "The claimed username",
+  "properties": {
+    "profile_url": {
+      "description": "Path of the public profile",
+      "type": "string"
+    },
+    "username": {
+      "type": "string"
+    },
+    "username_claimed_at": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "username",
+    "username_claimed_at",
+    "profile_url"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/non-destructive profile is covered. The description adds value beyond that by disclosing the authentication prerequisite and the session bootstrap path via start_login -- information an agent cannot get from the schema. It omits what happens when the username is already taken or whether the claim is idempotent, so it is good but not complete.

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 plus constraints first, then a clearly labelled ACCESS prerequisite. It is front-loaded and easy to scan. The constraint sentence duplicates the schema pattern, a minor redundancy that costs it the top score.

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?

For a one-parameter mutation with annotations and an output schema already supplied, the description covers what is claimed, the validation rules, and the exact authentication path needed to invoke it. Nothing essential to a correct first invocation 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% and the single parameter already carries the exact constraint text (3-30 chars, alphanumeric and underscores) plus a regex pattern. The description restates that rule verbatim rather than adding meaning such as case sensitivity, reserved names, or uniqueness-check behavior, so the baseline 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 states a specific verb and resource -- 'Claim a unique username for the authenticated user's public profile' -- which is unambiguous and does not overlap with any sibling such as update_my_profile or get_profile. It stops short of explicitly contrasting with those siblings, but the operation is distinct enough that no agent would confuse them.

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 real preconditions: the caller must have a Proof account, either via PROOF_API_KEY or by opening a session with start_login, and names the recovery path ('then call this tool again'). It does not address alternatives such as updating an existing username or whether re-claiming is permitted, which keeps it out of the top band.

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