Skip to main content
Glama
Sign In
Timbre

Timbre

by alejandrosml
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

undo

Destructive

Revert a Timbre change using its returned token or the latest change, restoring moved messages, marks, rules, mailboxes, templates, and saved searches to their prior state.

Instructions

Take back a change Timbre made: by the undo_token its tool returned (or one from history), else the latest. Moved messages go back where they were (Gmail's come out of the trash into All Mail); marks, rules, mailboxes, templates and saved searches return as they were.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "undo"
  }
}

Input Schema

NameRequiredDescriptionDefault
tokenNoThe undo_token a tool returned (or one from history); omit to undo the latest change.

Output Schema

NameRequiredDescriptionDefault
doneYes
noteNo
failedNo
plannedNoWith preview: what would go where.
undo_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.2

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety bar is lower. The description adds real restoration semantics beyond them: what state is reverted (messages back to original location, Gmail items out of trash into All Mail) and which entity types are affected.

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?

Two tight sentences, front-loaded with the core action and followed by token-selection and restore-behavior detail. The parenthetical Gmail note is useful but slightly dense; nothing is superfluous.

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?

An output schema exists so return values need not be explained, and the description covers token sourcing, default behavior, and the per-entity restore semantics. Nothing an agent needs to call this correctly is missing.

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 coverage is 100% and the single token parameter's description already states it comes from a tool return or history and that omitting it targets the latest change — the description largely restates this. It adds only marginal value, such as hinting at a 'history' source.

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 and resource ('Take back a change Timbre made') plus the two selection modes: a given undo_token or the latest change. No sibling tool competes with it, so the agent can route here unambiguously.

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?

Clear usage context: pass an undo_token from a prior tool result or from history, otherwise omit to undo the latest change. It does not name an explicit when-not or point at the history sibling for finding tokens, but no alternative undo path exists among siblings.

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