Skip to main content
Glama

Archive a cluster

archive_cluster

Archive a whole cluster's conversations. THIS MOVES REAL MAIL: every message in them is queued to move out of the user's INBOX into the account's archive folder. One exception, and it is the one to check for: if the cluster is PINNED, this does not archive anything at all - it settles the pin back to resting, leaves the mail in the inbox and queues no move. The reply says which happened in its result field: archived when mail was filed, pin_cleared when a pinned cluster was settled instead, already_archived when the cluster is there but nothing in it could be filed - everything already archived, or not yet extracted, and nothing_to_archive when the key and category match no conversations at all. Read it rather than assuming the call did what its name says, and archived_conversations counts how many were filed. Takes a cluster_key and category exactly as list_feed reported them. Prefer asking the user first: this moves every message in the cluster.

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": {
      "cluster_key": "<cluster_key>",
      "category": "<category>"
    },
    "name": "archive_cluster"
  }
}

Input Schema

NameRequiredDescriptionDefault
categoryYesThe category list_feed reported for this cluster.
cluster_keyYesThe cluster key from list_feed.

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?

With no annotations, the description carries the full burden and does so: it warns that real mail is queued to move out of INBOX, discloses the pinned-cluster exception that causes no archiving at all, and enumerates the four result values (archived, pin_cleared, already_archived, nothing_to_archive) with their meanings. It also exposes archived_conversations as the count field. This is unusually strong disclosure of side effects and outcome states.

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?

The critical warning (real mail moves) is front-loaded, and the pinned exception follows immediately, which is the right ordering. Some sentences are dense and pronoun-heavy ('it is the one to check for'), but every clause carries operational information rather than filler.

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?

There is no output schema, but the description compensates by explaining the result field values and the count field, so an agent knows how to verify what happened. For a two-parameter mutation tool with no annotations, this covers side effects, exceptions, and outcomes adequately.

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 100%, so the enum and shape are already documented. The description still adds provenance value: both parameters must be taken 'exactly as list_feed reported them', which prevents an agent from fabricating or normalizing a category value.

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?

Specific verb and scope: 'Archive a whole cluster's conversations', which explicitly distinguishes it from the sibling archive_conversation that acts on one conversation. The domain ('conversations', 'cluster_key and category exactly as list_feed reported them') makes the resource unambiguous.

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?

Gives a clear directive to prefer asking the user first because the operation moves every message, and points at list_feed as the source of the required identifiers. It stops short of naming archive_conversation as the single-conversation alternative, so the choice between cluster and conversation scope is implied rather than spelled out.

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