archive_conversationMove an Inbox conversation out of your inbox view while keeping it in the archived scope for your account only. Use it to clear active conversations without deleting them.
Archive an Inbox conversation so it leaves your inbox view; it stays under the archived scope. Only affects you.
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | Inbox conversation ID (numeric string). Get it from list_conversations. |
Changes observed during successful MCP inspections.
v1.1.3Input schema / properties / conversation_id / descriptionPrevious value: -"Canvas ID (numeric string)"New value: +"Inbox conversation ID (numeric string). Get it from list_conversations."v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and readOnlyHint=false, so the safety profile is largely covered. The description adds genuinely useful scope information ("Only affects you", stays in the archived scope), but says nothing about idempotency, behavior on an already-archived conversation, or how to reverse it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly constructed sentence front-loads the action and effect, with the "stays archived" and "only affects you" qualifiers immediately following. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, non-destructive, no-output-schema mutation with annotations present, the description covers the essentials: what it does and who it affects. The remaining gap is reversibility (no unarchive tool is named) and repeat-call behavior, which an agent would want before archiving at scale.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage and a single required parameter that the schema already documents (numeric Inbox conversation ID, obtainable from list_conversations), the baseline of 3 applies. The description adds no format or sourcing detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ("Archive an Inbox conversation") and adds the outcome ("it leaves your inbox view; it stays under the archived scope"), which implicitly separates it from delete_conversation and mark_conversation_read. It never names a sibling explicitly, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the intended effect (clear the inbox while retaining the thread), which implies when to reach for it rather than delete_conversation. However, there is no explicit when-to-use/when-not phrasing, no mention of the unarchive path, and no pointer to batch_update_conversations for bulk archiving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.