Skip to main content
Glama

Update the account triage profile (cadence, junk rules, VIPs, quiet hours)

update_triage_profile
DestructiveIdempotent

Saves the person's triage preferences so every connected agent reads the same rules.

Use defaults.agentRules (a string, up to 2000 characters) for what the person's agents may do on their own, in their words, e.g. archive newsletters older than a week, never trash. Save it only when the person says so. Use notes (defaults or per inbox, up to 2000 characters; longer notes are cut on save) for standing instructions; the whole stored profile is capped at 64 KB and a patch that would exceed it is refused without changing anything.

Deep-merges patch onto the stored triageProfile and persists it, so every connected agent reads the same prefs afterward. patch.defaults merges onto account defaults (e.g. { vip: { people: [...], domains: [...] } }, { cadence: {...} }, { quietHours: {...} }); VIP addresses/domains are normalized (lowercased, trimmed, deduped) automatically. patch.byInboxId.<inboxId> merges onto (or, when the whole value is null, removes) that inbox's sparse override (same shape as defaults, partial). setupCompletedAt / setupVersion mark first-setup done. Also accepts defaults.staleDraftDays (0-30, default 3, 0 is off) for reminders about unsent drafts. Also accepts defaults.attentionDays (0-90, default 7, 0 is off): unread mail older than this many days no longer counts as needing attention, except VIP mail and mail from a person. Also accepts defaults.cleanup.auto (default false): when true, run_cleanup archives duplicate notifications and old calendar replies instead of only listing them. And defaults.cleanup.newsletterDays (0-90, default 14, 0 is off): unread newsletters older than this many days are archived by run_cleanup. Call this whenever the human tells you their triage prefs (cadence, what counts as junk, who is VIP, quiet hours) rather than guessing. VIP people/domains (triageProfile.defaults.vip, or an inbox's override) are never-auto: ask the human first or leave the message alone. Never archive, label as junk, or propose_unsubscribe a VIP's mail without the human approving that specific action in chat. A VIP domain counts only for mail addressed to you, not mail you were BCC'd on or list mail.

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

Input Schema

NameRequiredDescriptionDefault
patchYesPatch to deep-merge onto the stored triageProfile. Only include the fields you want to change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (destructive/idempotent), it discloses deep-merge semantics, null-removes-override behavior, automatic VIP normalization, 2000-char truncation on save, and a 64 KB profile cap where an oversized patch is 'refused without changing anything'. It also spells out the never-auto VIP policy that constrains downstream actions.

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

Conciseness3/5

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

Front-loaded with purpose and consent gating, but the single dense paragraph runs long and mixes field reference, merge mechanics, and a multi-sentence VIP policy. The opening sentence's 'every connected agent reads the same rules' is repeated verbatim mid-paragraph, wasting space in an already heavy block.

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?

For a single nested patch parameter with no output schema, it covers merge behavior, per-field ranges/defaults, failure modes (cap refusal), and the safety policy around VIP mail. An agent has everything needed to construct a correct call and know when not to.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% but the schema is effectively empty objects with additionalProperties, so the description carries real meaning: `defaults.agentRules` (≤2000 chars, intent-writing guidance), `notes`, `defaults.staleDraftDays` (0-30, default 3), `attentionDays` (0-90, default 7), `cleanup.auto`, `cleanup.newsletterDays` (0-90, default 14), and `byInboxId.<id>` sparse overrides.

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+resource ('Saves the person's triage preferences') plus the deep-merge-and-persist mechanism, and the scope ('so every connected agent reads the same rules'). This cleanly separates it from get_triage_profile (read) and the narrower add_vip/remove_vip siblings.

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?

'Call this whenever the human tells you their triage prefs (cadence, what counts as junk, who is VIP, quiet hours) rather than guessing' plus 'Save it only when the person says so' gives explicit when-to-use and a consent gate. It stops short of naming siblings like add_vip/remove_vip as the narrower alternative for VIP-only changes.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources