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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

resend_email_otp

Resend the one-time password for an in-progress email addition using its session ID, so users can complete email verification when the original code is missing or expired.

Instructions

Resend the OTP code for an in-progress email addition.

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_idYesAdd-email session ID

Output Schema

NameRequiredDescriptionDefault
messageNo
successYes

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": "Generic success response",
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description is consistent with that by implying an outbound send that changes state without destroying data. It adds useful auth and preconditions context, but omits key behavioral traits an agent needs for a resend tool: any cooldown/rate limit, which address the code goes to, and whether the previous code is invalidated.

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 is front-loaded in one short sentence and the environment/access note is separated into its own labeled block. The ACCESS text is operationally verbose boilerplate, but it is clearly partitioned rather than buried mid-sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and auth prerequisites are covered. For a one-parameter resend operation, however, the definition leaves out resend-specific behavior (throttling, code supersession, transition to verify_email_otp) that an agent would need to call it safely.

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% and the single session_id parameter is documented as "Add-email session ID," so baseline 3 applies. The description adds only indirect meaning via "in-progress email addition" and does not say where the session_id is obtained (start_add_email) or what happens if it is stale.

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?

States a specific verb and resource ("Resend the OTP code") scoped to "an in-progress email addition," which distinguishes it from start_add_email and verify_email_otp in the sibling list. It does not name those siblings explicitly, so the differentiation is inferable rather than explicit.

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?

The phrase "for an in-progress email addition" gives a clear triggering condition, and the ACCESS block explains the prerequisite path (PROOF_API_KEY or start_login). It stops short of stating when not to use it or pointing to verify_email_otp as the next step.

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