Timbre

by alejandrosml

Overview Schema Source Related Servers Discussions Admin

Rust

Local

save_template

Idempotent

Save a reusable email template by name with subject, body placeholders, default recipients, or delete it.

Instructions

Keep a message template by name: subject, text with {{fields}} ({{first_name}}, {{name}} and {{email}} come from each recipient), default recipients. create_draft uses it with template and fields. delete: true removes one.

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": {
      "name": "<name>"
    },
    "name": "save_template"
  }
}

Input Schema

Name	Required	Description
`cc`	No
`to`	No	Recipients it goes to by default.
`body`	No	The text. {{first_name}}, {{last_name}}, {{name}} and {{email}} are filled from each recipient; any other {{field}} from the fields given when it is used.
`name`	Yes	Its name.
`delete`	No	true: delete the template of that name.
`subject`	No

Output Schema

Name	Required	Description
`name`	Yes
`fields`	No
`status`	Yes	saved, replaced, deleted.
`undo_token`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.2Nov 9, 2026

TDQS

A3.5/5.0

Behavior2/5

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

The description usefully discloses that 'delete: true removes one' and that saving is keyed by name (implying overwrite/idempotency), which goes beyond the annotations. But that disclosed deletion behavior conflicts with the supplied destructiveHint=false, so the agent receives contradictory signals about whether this tool can destroy data. The conflict is partial (only the delete mode) rather than total, hence 2 rather than 1.

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 compact clauses, front-loaded with the core action, then the templating model, then the delete mode. No filler sentences and nothing repeated from the schema verbatim.

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?

With an output schema present, return values need no explanation, and the description covers the templating semantics and the destructive mode that an agent most needs. The main gap is the undocumented 'cc' parameter and the absence of any note on overwrite behavior when a name already exists.

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 67%, and the description compensates well: it explains the {{field}} substitution model, names the built-in recipient fields ({{first_name}}, {{name}}, {{email}}), clarifies that other fields come from the caller at use time, and defines the delete flag. Only 'cc' is left unaddressed in both places.

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 names a specific verb and resource ('Keep a message template by name') and enumerates what a template holds: subject, templated text, default recipients. It also distinguishes the tool from create_draft by noting that create_draft consumes the template. The phrasing is telegraphic rather than polished, but an agent can identify the operation without opening the schema.

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?

It states a relationship to a sibling ('create_draft uses it with template and fields'), which implies the save-then-draft workflow, and it explains the delete mode. However, it never says when to prefer this over list_templates or when not to overwrite an existing template of the same name, so usage is only implied.

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