Skip to main content
Glama

Proof Holdings

by holdings.proof
OverviewDiscussionsAdmin

start_login

Start a login session by sending an authentication challenge to the user's chosen channel (Telegram, WhatsApp, SMS, or email). Returns a session ID and, FOR TELEGRAM AND WHATSAPP ONLY, deep_link, qr_code (base64 PNG) and qr_text (UTF-8 text QR for terminal display); on sms it returns sms_message with sms_dids instead, and on email nothing to display.

Agent usage: (1) Call start_login with the desired channel and phone_number (for SMS) or email (for email). (2) Present the challenge, and WHICH FIELD depends on the channel. On telegram/whatsapp pass deep_link to render_auth_link, which prints the clickable link and a QR code; in a chat client the link is what the user acts on, since they are usually on the same machine. On sms deep_link is an EMPTY STRING and render_auth_link will reject it — show sms_message and let the user pick a number from sms_dids. suggested_region is always set, but the matching ENTRY in sms_dids may be missing (europe and israel appear only when a number is configured) or present with an empty did, so offer that region first only when sms_dids[suggested_region] exists and carries a number, and otherwise offer whatever the object does. On email there is nothing to display at all, and nothing to check either: a result means the mail was accepted for delivery, so tell the user to open their inbox. A delivery failure is an ERROR here, not a field — the tool answers challenge_delivery_failed and NO session exists, so do not call wait_for_login; retry, or offer another channel. Never hand qr_text to a link renderer — it is the link already rendered as QR art, so print it verbatim inside a fenced code block or not at all, because its rows stop scanning the moment one wraps or a blank line lands between them. (3) Call wait_for_login with the returned session ID to poll until the user completes authentication. Terminal states: "verified" (login succeeded), "failed", "expired".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoEmail address (required for email channel)
channelYesAuthentication channel
phone_numberNoPhone number in E.164 format (required for SMS channel)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden and does so thoroughly: it discloses channel-dependent return fields, that SMS deep_link is an empty string and will be rejected by render_auth_link, that delivery failure is an error with no session, and the QR-text formatting constraint. This is far beyond a minimal restatement.

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

Conciseness5/5

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

The description is long but every block earns its place: it is front-loaded with the core purpose, then organized into clear channel-specific branches and a follow-up workflow. The density supports an otherwise multi-variant tool.

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?

Given no output schema and no annotations, the description fully compensates by documenting the response variants, the next-step wait_for_login call, failure semantics, and edge cases like missing sms_dids entries. An agent has enough context to invoke the tool correctly in every channel.

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. The description adds value by tying channel choice to concrete behavioral consequences, such as which response fields appear and which parameter is required for SMS versus email, though the schema already documents the element requirements.

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 description opens with a specific verb and resource: Start a login session by sending an authentication challenge to the user's chosen channel, listing the exact channels and naming the returned session ID. This clearly separates it from siblings like wait_for_login, render_auth_link, or start_2fa.

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 provides a numbered agent workflow, telling the agent to call start_login, present the challenge in a channel-specific way, then call wait_for_login. It explicitly handles negative cases, such as not calling wait_for_login when challenge_delivery_failed is returned, and routes Telegram/WhatsApp versus SMS versus email behavior.

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

All Proof Holdings toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources