@proof-holdings/mcp-server

Official

by ProofHoldings

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

create_dns_credential

Destructive

Store DNS provider credentials to enable automated domain verification through the Proof API.

Instructions

Store DNS provider credentials for automated domain verification. Note: credentials will be visible in the AI conversation context.

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

Name	Required	Description	Default
`provider`	Yes	DNS provider identifier (e.g. cloudflare, route53, digitalocean)
`credentials`	Yes	Provider-specific credential key-value pairs

Output Schema

Name	Required	Description
`id`	Yes	MongoDB ObjectId
`name`	Yes
`is_valid`	Yes
`provider`	Yes
`created_at`	Yes
`updated_at`	Yes
`last_used_at`	No	When the credential last made a DNS change; absent until it has. Sent by the list only.
`domains_count`	Yes
`validation_error`	No	Why the last check refused the credential; absent unless one did. Sent by the list only.
`last_validated_at`	No	When the credential was last checked against its provider; absent when never recorded. Sent by the list only.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.7.2Nov 6, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
addedInput schema / properties / credentials / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "A saved DNS provider credential. The secret is never returned.",
+  "properties": {
+    "created_at": {
+      "type": "string"
+    },
+    "domains_count": {
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "id": {
+      "description": "MongoDB ObjectId",
+      "type": "string"
+    },
+    "is_valid": {
+      "type": "boolean"
+    },
+    "last_used_at": {
+      "description": "When the credential last made a DNS change; absent until it has. Sent by the list only.",
+      "type": "string"
+    },
+    "last_validated_at": {
+      "description": "When the credential was last checked against its provider; absent when never recorded. Sent by the list only.",
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "provider": {
+      "type": "string"
+    },
+    "updated_at": {
+      "type": "string"
+    },
+    "validation_error": {
+      "description": "Why the last check refused the credential; absent unless one did. Sent by the list only.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "provider",
+    "name",
+    "is_valid",
+    "domains_count",
+    "created_at",
+    "updated_at"
+  ],
+  "type": "object"
+}

First observedv1.1.0Sep 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The description adds real behavioral context beyond the annotations, most notably that credentials become visible in the AI conversation context — a non-obvious and important side effect for a secret-storing tool. It also states the auth prerequisite and restart requirement. It does not explain storage lifetime, encryption, or how stored credentials relate to list_dns_credentials/delete_dns_credential cleanup, which keeps it below a 5.

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?

Purpose is front-loaded in one sentence, followed by a security warning and an access block, with no filler. The ACCESS section is slightly verbose but earns its space by unlocking invocation for an unauthenticated agent.

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?

Given an output schema exists and both parameters are fully documented in the schema, the remaining burden on the description is behavior and access, both of which are covered — including the credential-exposure caveat and the login path. An agent has enough to call it correctly, with only sibling differentiation missing.

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%, with both provider (including example identifiers) and the provider-specific credentials object documented in the schema itself. The description adds no syntax or per-provider credential key guidance, so the baseline 3 applies — 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 first sentence gives a specific verb and resource: store DNS provider credentials, tied to the purpose of automated domain verification. It is clear what the tool does, but it never distinguishes itself from close siblings such as connect_dns_provider, connect_godaddy, or verify_domain_with_credentials, so an agent cannot route between them from the description alone.

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 only implied: the agent infers it should call this to persist credentials before automated verification. The ACCESS paragraph is genuinely useful setup guidance (PROOF_API_KEY or start_login), but it explains authentication, not when to pick this tool over the sibling connectors that also register DNS providers.

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

Deploy Server