Proof Holdings

add_circle_member

Add a pending member to a Circle by name, with an optional pre-declared WhatsApp phone. The Telegram chat id is captured later when the member taps the enrollment deep link.

Agent usage: after adding a member, call invite_circle_member to mint the single-use enrollment link the member taps to bind their messenger identity.

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>",
      "name": "<name>"
    },
    "name": "add_circle_member"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Circle ID to add the member to
`name`	Yes	Display name of the member
`whatsapp_phone`	No	E.164 WhatsApp phone with a leading + (optional, declared)

Output Schema

Name	Required	Description
`id`	No	MongoDB ObjectId
`name`	No
`status`	No
`enrolled_at`	No
`has_telegram`	No	Whether the member has a Telegram channel (declared or verified)
`has_whatsapp`	No	Whether the member has a WhatsApp channel (declared or verified)
`mesh_opt_out`	No	The member sent /opt_out: they receive no drills, reminders or checks they did not start themselves
`mesh_opted_in`	No
`last_verified_at`	No	When this member last CONFIRMED an identity check asked of them — i.e. last proved it was them. Null until they have.
`enrolled_phone_hint`	No	Masked form of the phone the contact proved when they enrolled (the Telegram shared contact or the WhatsApp sender) — country prefix and last four digits only, never the full number. Lets the owner see who actually joined. Null until the member enrolls, and for members enrolled before it was recorded.

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": {
+    "enrolled_at": {},
+    "enrolled_phone_hint": {
+      "description": "Masked form of the phone the contact proved when they enrolled (the Telegram shared contact or the WhatsApp sender) — country prefix and last four digits only, never the full number. Lets the owner see who actually joined. Null until the member enrolls, and for members enrolled before it was recorded."
+    },
+    "has_telegram": {
+      "description": "Whether the member has a Telegram channel (declared or verified)"
+    },
+    "has_whatsapp": {
+      "description": "Whether the member has a WhatsApp channel (declared or verified)"
+    },
+    "id": {
+      "description": "MongoDB ObjectId"
+    },
+    "last_verified_at": {
+      "description": "When this member last CONFIRMED an identity check asked of them — i.e. last proved it was them. Null until they have."
+    },
+    "mesh_opt_out": {
+      "description": "The member sent /opt_out: they receive no drills, reminders or checks they did not start themselves"
+    },
+    "mesh_opted_in": {},
+    "name": {},
+    "status": {}
+  },
+  "type": "object"
+}

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

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes further by explaining the member is created in a pending state and that identity binding happens out-of-band when the member taps the deep link. The auth requirement is disclosed with a concrete remedy. It stops short of describing duplicate-name behavior or what the created record looks like, but the output schema covers the latter.

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?

Three tight blocks: what it does, the follow-up call, and the access requirement — all front-loaded and free of filler. The auth paragraph is the least essential sentence but it prevents a predictable failure mode, so it earns its place.

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 three-parameter mutation with an output schema, the description supplies everything an agent needs that structured fields don't: the pending-state lifecycle, the mandatory follow-up tool, and the authentication prerequisite. Nothing blocking remains undocumented.

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

Parameters3/5

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

Schema description coverage is 100%, so id, name, and whatsapp_phone are already documented with patterns and length bounds. The description adds only light framing ('by name', phone is 'pre-declared'), which does not materially extend what the schema says. Baseline 3 applies.

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 ('Add a pending member to a Circle') plus the optional WhatsApp phone and the fact that the Telegram chat id is bound later. That 'pending' framing cleanly separates it from add_circle_member_channel and from invite_circle_member, which mints the link rather than creating the record.

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 next-step sequencing rule: 'after adding a member, call invite_circle_member to mint the single-use enrollment link'. It also names the prerequisite (Proof account, client authentication) and rules out a wrong path by noting start_login does NOT open this tool.

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.