Skip to main content
Glama

Put a clear-out back

sweeps_put_back
Idempotent

Return what sweeps_apply moved under a sweep handle - every group, or those named - each message to the Outlook folder, or the folder of a mailbox held by its password, it came from, or in Gmail connected by Google sign-in to the labels it held; mail it marked read is marked unread again, and only that, and mail it filed leaves the label or folder, a label it already carried staying on it. A message moved since the apply is left where it is (changed), and one the provider no longer holds is gone. A call works for about three minutes; the same call again reaches what it did not. Putting back counts no action against the daily allowance.

Input Schema

NameRequiredDescriptionDefault
sweepYesThe sweep handle sweeps_preview answered.
groupsNo
mailboxYesThe mailbox's name or its email address.

Output Schema

NameRequiredDescriptionDefault
sweepYes
failedYes
groupsYes
newestOnlyNoThe folders whose provider showed only their newest messages, each with how many it showed: what this put-back could not find there is counted under notReached, never gone, and stays to be put back - a call again reaches it only once that folder holds fewer messages than its provider shows.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / newestOnly
      Added value: +{
      +  "description": "The folders whose provider showed only their newest messages, each with how many it showed: what this put-back could not find there is counted under notReached, never gone, and stays to be put back - a call again reaches it only once that folder holds fewer messages than its provider shows.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "folder": {
      +        "type": "string"
      +      },
      +      "shown": {
      +        "type": "number"
      +      }
      +    },
      +    "required": [
      +      "folder",
      +      "shown"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  2. Added

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations: it specifies that only read-marking is reverted (and only that), that filed mail leaves the label/folder while a pre-existing label stays, that moved and deleted messages are handled distinctly (changed / gone), that a call runs for about three minutes and a repeat call picks up the remainder, and that it consumes no daily quota. None of that is derivable from readOnly/destructive/idempotent hints.

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?

Purpose is front-loaded, but the body is a single sprawling sentence chaining restore targets, edge cases, timeouts and quota in one breath. Every clause carries information, yet the nested 'or the folder of a mailbox held by its password, it came from' phrasing forces re-reading; splitting into short statements would preserve content and improve scanability.

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 mutating, retryable undo tool with an output schema already defining returns, the description supplies the operationally important facts: scope, partial-completion retry, timeout window, quota exemption, and per-message edge outcomes. The main remaining gap is an explicit precondition tying the call to a still-open apply window.

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 undocumented parameter (groups) is exactly the one the description explains: 'every group, or those named', making clear it is an optional subset selector defaulting to all groups. The sweep handle's origin is reinforced, though the mailbox parameter's password/sign-in framing adds only mild clarity beyond the schema's own text.

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 opening clause states a specific verb and resource: return what sweeps_apply moved under a sweep handle, per group, restoring folder/label placement. It clearly names its inverse sibling (sweeps_apply) so an agent can distinguish the pair. The long run-on structure around 'each message to the Outlook folder... or in Gmail...' muddies the read but does not obscure the core purpose.

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?

Usage is implied rather than stated: it references a prior sweeps_apply and a sweep handle from sweeps_preview, and 'every group, or those named' hints at the default-vs-subset choice. It also gives a partial exclusion ('a message moved since the apply is left where it is'), but there is no explicit when-to-use/when-not framing or statement of prerequisites (e.g., whether an apply must still be in effect).

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.