Skip to main content
Glama
Sign In
MCP Google Multi-Account Server

MCP Google Multi-Account Server

by bkbaheti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

gmail_mark_read_unread

Mark a Gmail message as read or unread by toggling its UNREAD label. Specify the account, message ID, and desired state.

Instructions

Mark a Gmail message as read or unread. This is a shortcut for modifying the UNREAD label. Requires full scope.

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": {
      "accountId": "<accountId>",
      "messageId": "<messageId>",
      "markAsRead": "<markAsRead>"
    },
    "name": "gmail_mark_read_unread"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountIdYesThe Google account ID, alias, or email
messageIdYesThe message ID to modify
markAsReadYestrue to mark as read, false to mark as unread

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.3

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden of disclosure. It states 'Requires full scope' (auth requirement) and clarifies that the operation modifies the UNREAD label, which explains the underlying mechanism. It does not detail return values or edge cases, but for a simple mutation this is adequate.

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?

Two sentences, with the primary action in the first sentence and the key differentiator in the second. No redundant information, perfectly front-loaded.

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 tool with three simple parameters, no output schema, and no nested objects, the description covers the essential context: the action, the underlying mechanism, and the required scope. It could mention that other labels are unaffected, but the 'shortcut for modifying the UNREAD label' already implies this.

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?

The schema already documents all three parameters with 100% coverage, so the description need not add much. It does not provide additional parameter-level detail beyond restating the markAsRead boolean semantics, earning the baseline score of 3.

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?

Description uses specific verb 'Mark' with resource 'Gmail message' and states the two possible states (read/unread). The phrase 'shortcut for modifying the UNREAD label' distinguishes it from the more general gmail_modify_labels sibling tool, making the purpose crystal clear.

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?

The 'shortcut' phrasing implies when to use this tool: when you specifically want to toggle read/unread without dealing with full label operations. It provides clear context but does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

Deploy Server

Other Tools