Timbre

by alejandrosml

Overview Schema Source Related Servers Discussions Admin

Rust

Local

change_rule

Destructive

Enable, disable, or delete a Mail rule by name; deleting is reversible because undo restores the rule.

Instructions

Switch one of Mail's rules on or off, or delete it (undo puts it back). Switching one on asks the user in a window on the Mac.

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>",
      "action": "<action>"
    },
    "name": "change_rule"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	The rule's name, as list_rules gives it.
`action`	Yes	"enable", "disable" or "delete".

Output Schema

Name	Required	Description
`note`	Yes
`rule`	No
`trial`	No
`status`	Yes	preview, awaiting_approval, created, cancelled, enabled, disabled or deleted.
`undo_token`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.2Nov 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, and the description usefully adds two things annotations cannot: deletion is recoverable via undo, and enabling triggers a user confirmation window on the Mac. It doesn't cover failure behavior for a missing rule name, but the behavioral picture is materially richer than the annotations alone.

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 tight sentences, front-loaded with the operation and followed by the one non-obvious consequence (the Mac prompt). No redundant restatement of the title or parameter names.

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 two-parameter mutation with full schema coverage, annotations, and an output schema, the description covers the essentials: what changes, how to reverse it, and what the user will see. Only the error path for an unknown rule name is unaddressed.

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 both parameters are already documented, including the three action values. The description adds only the cross-reference that 'name' matches what list_rules returns, which is a modest gain over the schema; baseline 3 applies.

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?

The description uses a specific verb plus resource — 'Switch one of Mail's rules on or off, or delete it' — and the schema's action values enumerate exactly the three operations. An agent can immediately distinguish this from create_rule and list_rules in the sibling set.

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?

Usage context is clear: this is the tool for toggling or removing an existing rule, with 'undo puts it back' implicitly steering restore flows to the undo sibling. It stops short of an explicit exclusion (e.g., 'to create a new rule, use create_rule'), which keeps it from a 5.

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