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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_circle

Destructive

Updates a Circle's name or owner name while leaving omitted fields unchanged; use it to correct group labels or clarify who owns the Circle.

Instructions

Update a Circle's name and/or owner name. Omitted fields are left unchanged; the profile/identity binding is create-only.

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
idYesCircle ID
nameNoNew name for the Circle
owner_nameNoHow this Circle's members know its owner ("Dad", "Giorgi"). The bots name the owner by it; while it is empty they name nobody — the Circle's name labels the group, never the person. Trimmed by the API; null or an empty value clears it.

Output Schema

NameRequiredDescriptionDefault
idNoMongoDB ObjectId
nameNo
statusNoLifecycle state of a Circle (archived = soft-retired)
membersNo
user_idNo
created_atNo
owner_nameNoHow this Circle's members know its owner; null when unset
profile_idNo
updated_atNo
environmentNo
member_countNo
proof_me_enabledNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.2
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "created_at": {},
+    "environment": {},
+    "id": {
+      "description": "MongoDB ObjectId"
+    },
+    "member_count": {},
+    "members": {},
+    "name": {},
+    "owner_name": {
+      "description": "How this Circle's members know its owner; null when unset"
+    },
+    "profile_id": {},
+    "proof_me_enabled": {},
+    "status": {
+      "description": "Lifecycle state of a Circle (archived = soft-retired)"
+    },
+    "updated_at": {},
+    "user_id": {}
+  },
+  "type": "object"
+}
  2. Changed1 schema field changedv1.6.0
    • addedInput schema / properties / owner_name
      Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "How this Circle's members know its owner (\"Dad\", \"Giorgi\"). The bots name the owner by it; while it is empty they name nobody — the Circle's name labels the group, never the person. Trimmed by the API; null or an empty value clears it."
+}
  3. First observedv1.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, and the description adds meaningful context beyond them: partial-update merge semantics, the create-only constraint on identity binding, and a concrete auth prerequisite (PROOF_API_KEY plus server restart, and that start_login does not unlock this tool). It does not explain why the update is flagged destructive or whether a name change is reversible, leaving a small gap.

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 purpose and partial-update rule are front-loaded in the first sentence, with the create-only caveat immediately after. The ACCESS block is separated and actionable rather than buried. Slightly verbose in the auth explanation, but every sentence carries operational value.

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?

With a fully described schema and an output schema present, the description covers what remains: mutation scope, partial-update behavior, and the account prerequisite. It omits any mention of failure modes (e.g., invalid ID format, permission errors) or effects on existing members, which is a minor but real gap for a destructive-flagged mutation.

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 coverage is 100% and the owner_name field already carries a rich explanation in the schema (including null-clearing and trimming behavior). The description adds only the aggregate rule that omitted fields are unchanged, which is useful but does not deepen any individual parameter's meaning. Baseline 3 applies when the schema does the heavy lifting.

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?

The description states a specific verb and resource ('Update a Circle's name and/or owner name') and names the exact mutable fields, so it is clearly distinguishable from create_circle, get_circle and delete_circle. It stops short of naming those siblings explicitly, so it is clear but not maximally differentiating.

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 gives a real usage rule: 'Omitted fields are left unchanged', which tells an agent that partial updates are safe and that absent fields need not be supplied. It also states that the profile/identity binding is create-only, steering the agent away from a use this tool cannot serve. No explicit alternative-tool routing is given, but the mutation scope is unambiguous.

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