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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

check_user_domain_verification

Triggers a check on a domain verification challenge after you place the required DNS record or HTTP file, confirming whether domain ownership verification succeeds.

Instructions

Trigger a check on the domain verification challenge. Call after placing DNS record or HTTP file.

ACCESS: needs a Proof account. Set PROOF_API_KEY and restart this server, or sign in with start_login — a session opens this tool — then call this tool again.

Input Schema

NameRequiredDescriptionDefault
session_idYesDomain verification session ID

Output Schema

NameRequiredDescriptionDefault
assetNoThe domain asset holding the proof; present when `status` is `verified`
statusYes
messageNoWhy the check is still pending; present when `status` is `pending`
verified_atNoPresent when `status` is `verified`

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": {},
+  "description": "The result of one check of the published record or file",
+  "properties": {
+    "asset": {
+      "additionalProperties": {},
+      "description": "The domain asset holding the proof; present when `status` is `verified`",
+      "properties": {
+        "id": {
+          "type": "string"
+        },
+        "identifier": {
+          "type": "string"
+        },
+        "proof_expires_at": {
+          "type": "string"
+        },
+        "type": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "type",
+        "identifier"
+      ],
+      "type": "object"
+    },
+    "message": {
+      "description": "Why the check is still pending; present when `status` is `pending`",
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "verified_at": {
+      "description": "Present when `status` is `verified`",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations, the description adds meaningful operational context: it requires a Proof account, can be authenticated via PROOF_API_KEY, and otherwise needs a login session from start_login. It does not fully explain the side effects of 'triggering' a check, but the auth and timing details materially help correct invocation.

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 description is compact and front-loads the purpose and timing before the access note. Every sentence carries useful information, though the phrase 'a session opens this tool' is slightly awkward and could be clearer.

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 single-parameter tool with an output schema and annotations, the description covers the essential purpose, call timing, and authentication prerequisite. The main remaining gap is sibling disambiguation, which is more a usage-guideline issue than missing core context.

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% for the single session_id parameter, so the schema already documents its meaning as the domain verification session ID. The description does not add parameter-level detail beyond indirectly referring to a session, which is acceptable given the high schema coverage but not enriching.

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: 'Trigger a check on the domain verification challenge.' It is clear what the tool does, but it does not distinguish this user-domain check from the similarly named sibling check_domain_verification or from get_user_domain_verification_status.

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 concrete trigger condition: call after placing the DNS record or HTTP file. It also explains the Proof account prerequisite. However, it does not name alternatives or clarify when to use this instead of sibling verification-status or domain-verification tools.

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