Proof Holdings

add_circle_member_channel

Declare a channel for a Circle member. Returns 409 if that channel type already exists on the member. The identifier is a Telegram chat id or an E.164 WhatsApp phone (per-channel format validated server-side).

ACCESS: needs a Proof account. Authenticate this client (Claude Code: /mcp → Authenticate), then call this tool again. start_login does NOT open this tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "member_id": "<member_id>",
      "channel": "<channel>",
      "identifier": "<identifier>"
    },
    "name": "add_circle_member_channel"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Circle ID
`channel`	Yes	Channel type (telegram or whatsapp)
`member_id`	Yes	Member ID to add the channel to
`identifier`	Yes	Telegram chat id, or E.164 WhatsApp phone with a leading +

Output Schema

Name	Required	Description
`id`	No	MongoDB ObjectId
`status`	No
`channel`	No
`created_at`	No
`verified_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "channel": {},
+    "created_at": {},
+    "id": {
+      "description": "MongoDB ObjectId"
+    },
+    "status": {},
+    "verified_at": {}
+  },
+  "type": "object"
+}

Changed1 schema field changedOct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedSep 19, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false / destructiveHint=false; the description adds real behavioral facts beyond that: a 409 is returned when the channel type already exists on the member, format validation is server-side and per-channel, and authentication is required before invocation. It does not describe what a successful call returns, but an output schema exists to cover that.

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?

The core behavior and the duplicate/409 rule are front-loaded in the first sentence, and the access requirement is separated into its own block. Nothing is padded, though the ACCESS paragraph is slightly verbose relative to the one fact it delivers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-required-parameter mutation with a full schema and an output schema, the description covers purpose, error case, format expectations, and the auth gate. The only meaningful omission is any hint of what distinguishes this from add_circle_member or how to undo it (remove_circle_member_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 goes further by explaining that 'identifier' has two different accepted formats depending on the channel (Telegram chat id vs. E.164 WhatsApp with leading +) and that format is validated server-side, which is meaning the schema's terse field descriptions only partially convey.

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?

"Declare a channel for a Circle member" names a specific verb (declare/add) and resource (a member's channel), and the identifier-format sentence pins down exactly what kind of channel record is created. It does not name the sibling it contrasts with (add_circle_member, remove_circle_member_channel, list_circle_member_channels), so an agent must infer the distinction from the resource wording.

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 states the precondition (needs a Proof account, must authenticate the client) and explicitly excludes the obvious wrong path: "start_login does NOT open this tool." It also flags the duplicate case (409 if that channel type already exists). What it lacks is a pointer to the sibling for viewing or deleting channels, but the usage context is otherwise clear.

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

All Proof Holdings tools Inspect

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.