Scribe Mail

Update a signature

update_signature

DestructiveIdempotent

Update a signature template by UUID. Stages draft_content (the working copy) — the live content only changes when you publish_signature. Only the fields you pass change (omit = leave as-is; draft_content: null / folder_id: null clear them). When editing draft_content, call get_content_schema first for the block-tree schema, enum values (incl. the non-obvious icon names), and a worked example; an invalid tree returns 422 naming each offending field and its allowed values. Blocks are CLOSED: every key you add must exist in the schema, so build each block by adapting the schema's example rather than attaching extra keys to carry styling or smart-field values — an invented key fails the whole update with unknown_property.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The signature's UUID (the `id` from list_signatures).
`name`	No
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
`priority`	No	Ordering priority (lower = higher).
`folder_id`	No	UUID of the folder to file the signature under; null detaches it.
`draft_content`	No	Draft block tree (ILayoutBlock): a `stack` root whose `children` are blocks. Strict-validated server-side. Omit to leave unchanged; null to clear. Every node (block AND token) needs an `id` that is a fresh LOWERCASE uuid — any other string, including an uppercase uuid, is rejected 422. Every numeric size is in PIXELS, never a CSS multiplier: `lineHeight` is a px line box (~1.3x fontSize, e.g. fontSize 14 -> 18), so 1.3 is rejected. Call get_content_schema for the full schema, every enum value, and a worked example.
`signature_installation_activated`	No	Whether installation is activated for this template.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover the safety profile (destructive, idempotent), yet the description adds genuinely non-derivable behavior: the draft-vs-live staging model, patch semantics ("Only the fields you pass change"), null-clearing via `draft_content: null` / `folder_id: null`, 422 responses naming offending fields, and the `unknown_property` failure mode for invented block keys. This is materially more than the annotations supply.

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 that are front-loaded with the core staging behavior before drilling into the block-tree hazard. It is dense but nearly every clause carries operational information; the final sentence overlaps somewhat with the earlier get_content_schema advice, so it is not perfectly tight.

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?

For a mutation tool with seven parameters, a rich nested schema, and an output schema, the description covers the staging lifecycle, error behavior, patch semantics, and the schema-discovery dependency. Nothing an agent needs in order to invoke it correctly is missing.

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 already 86%, so the baseline is 3; the description earns above that by defining partial-update semantics the schema never states (omit = leave as-is, null = clear) and by framing the block-tree constraints (closed keys, pixel units, fresh lowercase uuids). Some of this (uuid format, pixel lineHeight) duplicates the schema's own `draft_content` description, which caps it at 4.

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?

States a specific verb+resource ("Update a signature template by UUID") and immediately distinguishes its scope from siblings: it stages `draft_content` while "the live `content` only changes when you publish_signature." An agent can separate this from publish_signature, create_signature, and update_signature_variant without opening any schema.

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?

Gives explicit preconditions and sequencing — "When editing `draft_content`, call `get_content_schema` first" — and explains that publication is a separate step via publish_signature. It does not explicitly contrast with update_signature_variant or create_signature, so it stops short of full when/when-not routing.

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

All Scribe Mail tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.