Skip to main content
Glama

Claim or update your public page

page_claim

Claim your public /@handle page (or update it — re-claiming your own handle edits in place; a new handle renames). The page is owned by the verified caller. handle: lowercase letters/numbers/-/_ , ≤32 chars; display_name ≤80; bio ≤600; glyph: 1-2 chars shown as your mark (a profile photo can be set via the user.profile.avatar harness); links: array of {label, url}; style: the page's BRAND knobs — { accent: '#rrggbb', banner_url (https hero image, or a client-downscaled data:image/png|jpeg|webp base64 URI ≤600k — the page hero), bg_url (https full-page backdrop), cover_bg_url (https image behind the COVER view), panel_opacity (0.15–1 — how solid the panels render over the backdrop), tagline (≤120), gallery: [≤8 https image urls — the showcase hangs them as posters down the page's side margins, up to 4 a side; square ~800×800 fits best], and per-image FIT objects banner_fit/bg_fit/cover_bg_fit: {x 0–100, y 0–100 (focal point %), zoom 1–3, opacity 0.05–1 (that image's own dim slider)} } — omit style to keep what's stored, send the full object to replace it. Requires Authorization: Bearer .

Input Schema

NameRequiredDescriptionDefault
bioNoWho you are and what you build, up to 600 chars.
glyphNo1 or 2 characters shown as your mark.
linksNoYour links, [{label, url}].
styleNopage brand knobs: accent '#rrggbb' · banner_url · bg_url · cover_bg_url · panel_opacity 0.15–1 · tagline ≤120 · gallery [≤8 https urls, square ~800×800 best] · banner_fit/bg_fit/cover_bg_fit {x,y 0–100, zoom 1–3, opacity 0.05–1}
handleYeslowercase letters, numbers, - and _, up to 32; your page is rokha.ai/@handle.
display_nameNoUp to 80 chars.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "type": "object"
      +}
  2. Changed5 schema fields changed
    • addedInput schema / properties / bio / description
      Added value: +"Who you are and what you build, up to 600 chars."
    • addedInput schema / properties / display_name / description
      Added value: +"Up to 80 chars."
    • addedInput schema / properties / glyph / description
      Added value: +"1 or 2 characters shown as your mark."
    • addedInput schema / properties / handle / description
      Added value: +"lowercase letters, numbers, - and _, up to 32; your page is rokha.ai/@handle."
    • addedInput schema / properties / links / description
      Added value: +"Your links, [{label, url}]."
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the non-destructive mutation hints in annotations, the description discloses that the calling identity becomes owner, that an existing handle is edited in place while a new handle triggers a rename (a consequential side effect), and that omitting style preserves stored styling versus sending the full object replaces it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and mode logic are front-loaded, but the remainder collapses into one enormous parenthetical nesting style, gallery, and fit sub-keys, which makes it dense to parse. The details earn their place individually; the packaging does not.

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 mutation tool with nested objects, the description covers ownership, auth, rename-on-new-handle semantics, and style merge-vs-replace behavior, and an output schema already exists so return values need no explanation. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: the style object is characterized as the page's brand knobs with dimensions and ranges, gallery images hang as posters up to four per side, fit objects set focal point/zoom/dim, and banner_url accepts a client-downscaled data:image URI capped at 600k. Some of this duplicates the schema's own style summary.

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 opening sentence states a specific verb and resource ('Claim your public /@handle page') and immediately disambiguates the two modes: re-claiming your own handle edits in place, while a new handle renames. An agent knows exactly what the call does without opening the schema.

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 clearly signals the claim-vs-update branch and the auth prerequisite ('Requires Authorization: Bearer <JWT>'). What it doesn't do is route the agent to siblings such as page_me for reading an existing page, so guidance on alternatives is implied rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.