Scribe Mail

Update a marketing campaign

update_marketing_campaign

DestructiveIdempotent

Update a marketing campaign by UUID. Only the fields you pass change (omit = leave as-is; content: null clears it). status is read-only — use schedule/pause/resume to change it. Invalid enums, unknown smart fields, or unknown signature templates return 422.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The campaign's UUID (the `id` from list_marketing_campaigns).
`name`	No
`content`	No	Campaign 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.
`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."
`end_time`	No	ISO-8601 end of the campaign window.
`behaviour`	No	How the campaign content combines with the signature (replace or append).
`time_zone`	No	IANA time zone, e.g. 'Europe/Paris'.
`send_email`	No
`start_time`	No	ISO-8601 start of the campaign window.
`filter_kind`	No	Which targeting dimension applies: by signature_templates or by smart_fields conditions.
`signature_template_ids`	No	UUIDs of the signature templates to apply the campaign to (replaces the set; [] clears).
`smart_fields_conditions`	No	Smart-field targeting: an array of OR-groups, each an array of AND-conditions { smart_field_id (uuid), operator, values }.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds genuine value beyond those: partial-update behavior, the null-clears convention, the read-only nature of status, and the 422 failure conditions for invalid enums/smart fields/signature templates. It stops short of disclosing what specifically gets destroyed or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, all front-loaded and information-dense. The partial-update rule and the status routing come first, followed by error behavior. Every sentence earns its place.

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 12-parameter mutation tool with a complex nested content tree, the description covers the critical behavioral points (partial update, clearing, status routing, error conditions) and points the agent to get_content_schema for the full block schema. Output schema exists, so return values need not be described. Minor gap: no explicit note on targeting interplay (filter_kind vs smart_fields/signature_template_ids).

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 description coverage is already 83%, so the baseline is 3. The description adds meaningful semantics on top — omit-vs-null behavior for content and the read-only nature of status — which is more than the schema states for those fields.

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 ('Update a marketing campaign by UUID'), and distinguishes itself from the status-change siblings by routing status changes to schedule/pause/resume. Clear enough that an agent can identify the operation without opening the schema, though it doesn't contrast with create/delete siblings directly.

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?

Explains partial-update semantics (omit = leave as-is; content: null clears) and explicitly names the alternative tools for status changes (schedule/pause/resume). No explicit when-not-this-tool guidance beyond status, but the context is well covered.

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.