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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_template

Destructive

Create or replace a sub-account-specific message template for a channel and message type, overriding the default only for that sub-account.

Instructions

Create or update a sub-account's custom template for a channel and message type, replacing the default for that sub-account only. Name the brand with {{business_name}}: a template spelling out a sub-account's own name is refused (template_hardcoded_name). A template for a channel and message type no message is sent for, or using a variable that message never fills, is still saved, with an entry in warnings (template_not_sent / template_variable_not_filled) saying why it will not be sent as written (an API that predates warnings omits the field).

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.

Input Schema

NameRequiredDescriptionDefault
bodyYesTemplate body text with variable placeholders
channelYesMessage channel
subjectNoEmail subject line (email channel only)
profile_idNoThe sub-account to act on; omitted → your key's sub-account, or the primary sub-account for an account-wide key
button_textNoButton text (email channel only)
message_typeYesMessage type (e.g. verification_request, login_request)
button_url_templateNoButton URL template with placeholders

Output Schema

NameRequiredDescriptionDefault
successNo
templateNoMessage template
warningsNoWhy this template would never be sent as written; empty when it would be. Always sent; absent from an API that predates it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.2
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / profile_id / description
      Previous value: -"The sub-account (project) to act on; omitted → your key's project, or the primary project for an account-wide key"New value: +"The sub-account to act on; omitted → your key's sub-account, or the primary sub-account for an account-wide key"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "success": {},
+    "template": {
+      "description": "Message template"
+    },
+    "warnings": {
+      "description": "Why this template would never be sent as written; empty when it would be. Always sent; absent from an API that predates it."
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changedv1.7.0
    • addedInput schema / properties / profile_id
      Added value: +{
+  "description": "The sub-account (project) to act on; omitted → your key's project, or the primary project for an account-wide key",
+  "pattern": "^[0-9a-fA-F]{24}$",
+  "type": "string"
+}
  3. First observedv1.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the destructiveHint=true annotation, it discloses the overwrite effect on the sub-account default, the hard refusal rule with its error code (template_hardcoded_name), and the non-obvious save-with-warnings behavior with both warning codes (template_not_sent / template_variable_not_filled) plus the older-API caveat that `warnings` may be absent. These are exactly the behaviors an agent cannot infer from annotations or schema.

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?

Three sentences, front-loaded with the action and scope before the rules and the access block. The access paragraph is boilerplate but necessary for a tool gated behind an API key, and no sentence is padding.

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 7-parameter mutation with an output schema, it covers the action, overwrite semantics, failure and warning modes, and auth requirements. Only minor gaps remain: whether subject/button fields are rejected or ignored on non-email channels, and what the response contains on a successful create versus update.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for the placeholder-bearing fields: the {{business_name}} variable is required for branding and a hardcoded sub-account name is refused, and variables must be ones the message type actually fills. It says nothing extra about profile_id resolution beyond the schema, so it stops short of a 5.

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?

The first sentence gives a specific verb pair (create or update), the exact resource (a sub-account's custom template), and the scoping keys (channel and message type), plus the qualifier 'replacing the default for that sub-account only'. That distinguishes it from list_templates, get_template, preview_template, render_template and delete_template without naming them.

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 states the access precondition explicitly (needs a Proof account, set PROOF_API_KEY, restart the server) and pre-empts a wrong path by noting 'start_login does NOT open this tool', which is real when-not guidance. What's missing is routing to the read-side siblings, e.g. preview_template to check a body before saving or get_template to read the current one.

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