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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

render_auth_link

Read-only

Render an authorization or verification URL as a clickable link and scannable QR code block so you can paste it into a user-facing reply.

Instructions

Render an authorization or verification URL as a clickable link followed by a scannable QR code inside a fenced code block. This is a local computation tool — no HTTP request is made. Its output comes back to you, not to the user: copy the link, and the QR block inside its fence, into your reply.

Agent usage: pass a LINK field from an earlier response — deep_link (create_session, create_chat_id_discovery always; start_login, create_account, start_2fa, start_2fa_for_action, start_add_phone on telegram/whatsapp ONLY, where on sms and email that field is empty or absent altogether and this tool rejects it either way), challenge.deep_link (create_verification, messenger channels only), or telegram_deep_link / whatsapp_deep_link.

Do NOT pass qr_text to this tool: that field is a QR code already rendered as text, and this tool takes a link. When a response gives you qr_text and no link, print it verbatim inside a fenced code block instead — its rows only scan while they stay adjacent, so a blank line or wrapped row destroys the code.

The user does not see tool results — most clients fold them away, render_auth_link's output included. Before you wait or poll, put what the user must act on into your own reply text: the link itself (not a sentence announcing it), the SMS text and number, or a note to check their inbox.

Input Schema

NameRequiredDescriptionDefault
urlYesThe link to render — e.g. a deep_link response field. Never a qr_text value: that is the link already rendered as QR art.
labelNoOptional label to display above the link (e.g. "Verify your phone number")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.7.2
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint; the description adds genuinely new behavior: it is a local computation with no HTTP request, the output returns to the agent rather than the user, and clients fold the result away so the link must be copied into the reply. That is exactly the operational context an agent cannot infer from the annotation.

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?

Purpose is front-loaded in the first sentence and the dense parenthetical field list earns its length by preventing wrong-input calls. The final paragraph about user visibility is slightly tangential to rendering but is load-bearing for correct overall usage.

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?

There is no output schema, so the description must explain what comes back — and it does, including format (link plus QR inside a fence) and where it goes (agent, not user). Combined with the QR adjacency warning, nothing an agent needs to call and use it 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 100%, so the baseline is 3, but the description goes further by identifying the legitimate sources of `url` and stating that qr_text values are actively rejected — real semantic guidance beyond the schema. `label` is left to the schema, keeping it from a 5.

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 states a concrete verb and resource — render an authorization/verification URL as a clickable link plus QR code in a fenced block — and immediately scopes it against sibling render_template-style tools by naming the input type. An agent can distinguish it 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 Guidelines5/5

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

It enumerates exactly which upstream fields to pass (deep_link with per-channel caveats, challenge.deep_link, telegram_deep_link, whatsapp_deep_link) and explicitly excludes qr_text, with the alternate action (print qr_text verbatim in a fence) spelled out. When-to-use, when-not-to-use, and the fallback are all present.

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