Skip to main content
Glama
gmail-mcp

gmail-mcp

add_label

Assign a system or custom label to a Gmail message by message ID to organize emails and ensure label names match Gmail exactly.

Instructions

Add a label (system or custom) to an email.

Required:
  message_id (str) — Gmail message ID.
  label (str) — label name. System labels: STARRED, IMPORTANT,
    SENT, DRAFT, TRASH, SPAM. Custom labels: any name you've
    created in Gmail settings.

Returns on success:
  {"message_id": "...", "labels": ["INBOX", "IMPORTANT", "..."]}}

Workflow note: Label names are case-sensitive in Gmail.
  "STARRED" works, "starred" may not. Custom label names
  must exactly match how they appear in Gmail.

Input Schema

NameRequiredDescriptionDefault
labelYes
message_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description meaningfully discloses the success response, Gmail's case-sensitive label handling, and the exact-match requirement for custom labels. It does not cover failure behavior, idempotency, or the practical side effects of adding labels such as TRASH or SPAM.

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?

The definition is front-loaded with the action and then efficiently organizes parameter requirements, the success payload, and an important workflow caveat. Its examples and warnings are directly useful, with no substantial 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 simple two-parameter mutation with no annotations or output schema, the description covers nearly everything needed for a successful call, including the return shape. Explicit sibling routing and brief error or special-label behavior would make it more complete.

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?

Despite 0% schema description coverage, both parameters are fully explained with their expected meaning and types. The description also supplies valid system-label examples, the custom-label prerequisite, and case-sensitivity constraints needed to invoke the tool correctly.

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 sentence clearly states the verb, resource, and scope: adding one system or custom label to an email. The singular scope hints at the distinction from add_labels and remove_label, but those siblings are not explicitly addressed.

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 description supplies useful context by supporting both system and custom labels and requiring custom labels to already exist in Gmail settings. However, it gives no explicit guidance on when to choose this tool over add_labels for bulk operations or how special labels such as TRASH and SPAM relate to dedicated sibling tools.

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