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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

resend_confirmation

Resend a pending confirmation to active recipients with fresh recipient-bound links via their own channels; old links stop working. Use to renew confirmation links; responses return counts only.

Instructions

Send a pending confirmation again to the people it went to: each recipient gets a fresh link bound to them, through their own channel, expiring when the confirmation does; their earlier links stop working (410 approval_link_superseded). The response carries counts only, never a link. Recipients are the approvers whose authorization is still active and whose key the stored message is encrypted for, plus the owner; an approver added since needs a new confirmation. A charged send, like create_confirmation: an account past its included proofs with an empty prepaid balance is refused with 402 balance_empty, whose top_up_url is the Billing page (https://proof.holdings/billing). Refused 400 invalid_status once decided, expired, or config_archived. Read the decision with get_confirmation, or wait_for_confirmation.

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.

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": "resend_confirmation"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesConfirmation ID (24 hex characters)

Output Schema

NameRequiredDescriptionDefault
resentNoRecipients sent a fresh link, each through their own channel
skippedNoRecipients not sent it: no longer authorized, unable to open the message (an approver added after the confirmation was created), or a failed delivery
confirmation_idNoMongoDB ObjectId

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.10.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the substantive behavior an agent needs: prior links are invalidated (410 approval_link_superseded), the response returns counts only and never a link, the send is billed, and specific refusal codes (402 balance_empty with a top_up_url, 400 invalid_status) are enumerated. It also defines the exact recipient set (active approvers whose key the stored message is encrypted for, plus the owner), which no structured field conveys.

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 the core action and the superseded-link consequence, then costs and error codes, with the access requirement set off separately. It is information-dense but semicolon-chained and long; a few clauses (e.g. the encryption-key detail of the recipient set) could be tightened without losing routing value.

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 flags that the response carries counts only and never a link, which prevents an agent from fishing for a URL. Combined with the billing refusal path, the invalid_status conditions, the sibling read tools, and the API-key prerequisite, everything needed to invoke this correctly is present.

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?

There is a single required parameter with 100% schema description coverage ('Confirmation ID (24 hex characters)'), so the schema already carries the semantics and a baseline of 3 applies. The description references recipients and the stored message but adds nothing about the id itself beyond what the schema states.

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: re-send a pending confirmation to its existing recipients, each getting a fresh per-recipient link via their own channel. It distinguishes itself from create_confirmation by noting that an approver added since the original send 'needs a new confirmation', so an agent can tell the two apart without opening either schema.

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?

Gives clear conditions: use it to re-issue links to the current recipient set, and route to create_confirmation for newly added approvers. It also points to get_confirmation / wait_for_confirmation for reading the decision. It does not spell out an explicit exclusion for already-decided or expired confirmations beyond the 400 invalid_status note, so it stops short of a full when/when-not statement.

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