@proof-holdings/mcp-server

Official

by ProofHoldings

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

archive_approval_channel

Destructive

Archive an approval channel by setting its status to archived so it cannot be used for new confirmations.

Instructions

Delete (archive) an approval channel. Sets status to archived. Cannot be used for new confirmations after deletion.

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

Input Schema

Name	Required	Description	Default
`id`	Yes	Approval channel ID to delete

Output Schema

Name	Required	Description
`id`	Yes	MongoDB ObjectId
`name`	No
`status`	Yes	Status of a HITL configuration
`keypair`	Yes	Encryption keypair metadata (null if not configured)
`user_id`	Yes	Owner user ID (useful for SDK encryption AAD)
`channels`	Yes
`circle_id`	No	Backing Circle for a circle-backed Approvals config (null for channel-list configs)
`created_at`	Yes
`profile_id`	No
`updated_at`	Yes
`environment`	Yes
`timeout_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.10.0Nov 13, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare this as destructive and non-read-only, and the description adds meaningful context beyond them: it is a soft delete that sets status to archived, it prevents new confirmations afterward, and it requires a Proof account with PROOF_API_KEY configured. It does not describe output or whether archived channels can be restored, but the behavioral disclosure is strong.

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 purpose is front-loaded and the access note is separated below, making the structure easy to scan. The sentence 'start_login does NOT open this tool' is unusual but clarifies a confusing prerequisite; overall the content earns its place without significant waste.

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 an output schema present, annotations covering the destructive nature, and a fully documented single parameter, the description supplies what remains: archive behavior, post-condition, and authentication prerequisites. It is nearly complete, though it could state whether restoration is possible or what happens to existing confirmation data.

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 one parameter with 100% schema description coverage, and the schema already says it is the 'Approval channel ID to delete.' The description adds no further meaning about the id parameter, so the baseline of 3 is appropriate when the schema carries that burden.

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: 'Delete (archive) an approval channel,' and clarifies the archive semantics with 'Sets status to archived.' It is clear enough to distinguish from read/update siblings, though it does not explicitly name an alternative such as update_approval_channel or delete_approval_channel_keys.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb and the post-condition 'Cannot be used for new confirmations after deletion,' but no explicit when-to-use or when-not-to-use guidance is given relative to siblings. The access prerequisites are documented, which helps operationally, but alternative tools are not mentioned.

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

Deploy Server