Skip to main content
Glama
CapyKkuing

naver-mail-mcp

unlabel_thread

Idempotent

Removes specified labels from all messages in a mail thread, such as clearing UNREAD to mark the entire conversation as read.

Instructions

Removes labels from every message in a thread, e.g. remove UNREAD to mark the whole conversation as read.

Input Schema

NameRequiredDescriptionDefault
labelIdsYesLabel ids: STARRED, UNREAD, INBOX, TRASH, SPAM, or a user label id from list_labels. Adding a folder label moves the message to that folder (one folder per message); removing the current folder label moves it back to INBOX.
threadIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare safe, idempotent, non-destructive mutation, so the bar is lower. The description's real addition is batch scope — that the label change cascades across every message in the thread rather than one message — which is exactly the behavior an agent needs to know before committing.

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?

A single sentence, front-loaded with the action, with the example earning its space by translating the mechanic into a user-visible outcome. No filler.

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 idempotent mutation with annotations covering safety and no output schema, the description gives action, scope, and a worked example. Minor gap: no mention of behavior when a label is absent from some messages in the thread.

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 coverage sits at 50%: labelIds carries a rich description (allowed values, folder-moving semantics) while threadId has none. The description only echoes 'UNREAD' from the schema and adds no format or constraint detail, so it neither compensates for nor worsens the gap. Baseline 3.

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?

States a specific verb and resource ('removes labels from every message in a thread') and the 'every message' qualifier implicitly separates it from unlabel_message. It does not explicitly name the sibling, but the thread-level scope is unambiguous.

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?

The example ('remove UNREAD to mark the whole conversation as read') gives one concrete use case, which implies when to reach for this tool. It offers no exclusions or comparison to unlabel_message / update_message_labels for single-message or mixed-operation cases.

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