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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_chat_id_discovery

Generates a Telegram chat ID discovery link and QR code so users can reveal their chat ID and set up human-in-the-loop configuration.

Instructions

Create a Telegram chat ID discovery token. Returns a deep_link, qr_code (base64 PNG), and qr_text (UTF-8 text QR for terminal display). The user opens the link in Telegram, which reveals their chat ID for HITL config setup.

Agent usage: pass the response's deep_link to render_auth_link so the user can click or scan it. Never hand qr_text to a link renderer — it is that same link already rendered as QR art. Print it verbatim inside a fenced code block only when a real terminal needs the QR. Then poll poll_chat_id_discovery with the returned token until the chat_id appears. Use the discovered chat_id when creating a HITL config with a Telegram channel.

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.

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.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
tokenYes
qr_codeYesQR code data URL for the deep link
qr_textYesUTF-8 text representation of the QR code for terminal/agent display
deep_linkYes
expires_inYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.7.2
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "Chat ID discovery token and Telegram deeplink",
+  "properties": {
+    "deep_link": {
+      "type": "string"
+    },
+    "expires_in": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "qr_code": {
+      "description": "QR code data URL for the deep link",
+      "type": "string"
+    },
+    "qr_text": {
+      "description": "UTF-8 text representation of the QR code for terminal/agent display",
+      "type": "string"
+    },
+    "token": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "token",
+    "deep_link",
+    "qr_code",
+    "qr_text",
+    "expires_in"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint=false/destructiveHint=false annotations by disclosing the auth prerequisite (PROOF_API_KEY, restart required, start_login does not unlock it) and the client-level behavior that users never see tool results, which changes how the agent must respond. It also explains what each returned artifact is and what it must not be used for.

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?

Front-loaded with purpose, then a labeled 'Agent usage' block and an access note — good structure. Minor waste: the user-invisibility paragraph mentions 'SMS text and number' and inbox checks, which belong to other tools and do not apply here.

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?

An output schema exists, yet the description still usefully names the returned fields and their roles in the flow, plus the auth gate and the downstream poll step. Nothing an agent needs to invoke this correctly and continue the workflow is missing.

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

Parameters5/5

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

The tool takes zero parameters, so there is no parameter meaning for the description to carry; it correctly spends its words on the returned token and artifacts instead.

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?

States a specific verb and resource ('Create a Telegram chat ID discovery token') and immediately names the three return artifacts (deep_link, qr_code, qr_text). It is clearly distinguishable from siblings poll_chat_id_discovery and wait_for_chat_id_discovery, which it explicitly hands off to.

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?

Gives an explicit 'Agent usage' sequence: pass deep_link to render_auth_link, do not pass qr_text to a renderer, then poll poll_chat_id_discovery until chat_id appears, then use it in a Telegram-channel HITL config. It names the follow-up tools and the terminal-state condition ('until the chat_id appears').

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