Courier

put_notification_element

Idempotent

Update a single element within a V2 notification template. The template stays a draft; making it live is a separate step this tool cannot perform.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "notification_id": "<notification_id>",
      "element_id": "<element_id>",
      "type": "<type>"
    },
    "name": "put_notification_element"
  }
}

Input Schema

Name	Required	Description
`if`	No	Conditional expression for element visibility
`ref`	No	Reference identifier
`data`	No	Element data payload
`loop`	No	Loop expression for repeating elements
`type`	Yes	Element type (e.g. text, action, image, divider, meta)
`state`	No	Must be "DRAFT". These tools cannot publish.
`channels`	No	Channels this element applies to
`element_id`	Yes	The element ID to update, from a prior get_notification or get_notification_draft_content response. Copy it exactly, character for character, from the response that returned it — never retype it from memory or reconstruct it.
`notification_id`	Yes	The notification template ID (nt_ prefix). Copy it exactly, character for character, from the response that returned it — never retype it from memory or reconstruct it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 15, 2026

changedInput schema / properties / element_id / description

Previous value: -"The element ID to update"New value: +"The element ID to update, from a prior get_notification or get_notification_draft_content response. Copy it exactly, character for character, from the response that returned it — never retype it from memory or reconstruct it."

changedInput schema / properties / notification_id / description

Previous value: -"The notification template ID (nt_ prefix)"New value: +"The notification template ID (nt_ prefix). Copy it exactly, character for character, from the response that returned it — never retype it from memory or reconstruct it."

changedInput schema / properties / state / description

Previous value: -"Template state after update"New value: +"Must be \"DRAFT\". These tools cannot publish."

changedInput schema / properties / state / enum

Previous value: -[
-  "DRAFT",
-  "PUBLISHED"
-]New value: +[
+  "DRAFT"
+]

AddedMay 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare the safety profile (not read-only, idempotent, not destructive). The description adds genuine behavioral context beyond that: updates keep the template in draft state and publishing is intentionally out of scope. No contradiction with annotations.

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?

Two sentences with zero filler: the action is stated first and the critical draft-state limitation follows immediately. Every word 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 9-parameter, no-output-schema tool, the schema carries the parameter documentation burden at 100% coverage and the state enum self-documents the DRAFT-only constraint. The description supplies the key behavioral limitation (no publishing). The only real gap is explicit routing among sibling tools like put_notification_content.

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%, so every parameter (if, ref, data, loop, type, state, channels, element_id, notification_id) is already documented in the input schema, including the copy-exactly guidance for IDs. The tool description itself adds no parameter-level detail beyond the schema, matching the baseline of 3.

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 description uses a specific verb (Update) and resource (a single element within a V2 notification template), making the tool's scope clear. It implies differentiation from siblings like put_notification_content and put_notification_locale by scope, though it never names an alternative explicitly.

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 description states a clear context — editing draft templates — and asserts a when-not boundary: 'making it live is a separate step this tool cannot perform.' It does not name the sibling tool that publishes (e.g., publish_notification), so the guidance is clear but not fully explicit.

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

All Courier 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.