Yahoo Mail MCP Server

move_emails

Move specified Yahoo Mail messages to a chosen folder using their permanent UIDs; set destination folder and optional source folder, defaulting to INBOX.

Instructions

Move emails to a specified folder using UIDs. UIDs are permanent identifiers. Use list_folders to see available folders.

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": {
      "uids": "<uids>",
      "folderName": "<folderName>"
    },
    "name": "move_emails"
  }
}

Input Schema

Name	Required	Description	Default
`uids`	Yes	Array of UIDs to move
`folderName`	Yes	Name of the destination folder (e.g., "Work", "Personal"). Use list_folders to see available folders.
`sourceFolder`	No	Source folder containing the emails (default: INBOX)	INBOX

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.1.0Sep 28, 2026

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the responsibility. It adds useful context that UIDs are permanent identifiers, which clarifies how to refer to emails. However, it does not disclose potential side effects such as whether the emails are removed from the source, what happens if the destination folder is invalid, or whether the operation is reversible. Some context is given, but a destructive mutation warrants more disclosure.

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 description is two sentences with no filler. The core action is front-loaded, and the additional information (UID permanence and list_folders reference) is relevant and concise. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a mutating operation without an output schema and no annotations. The description covers the action, prerequisites, and the permanence of UIDs, but it does not mention what response the agent can expect, error conditions, or any impact on source folders. For a straightforward move operation, this is adequate but not rich; a bit more detail (e.g., success indication) would improve completeness.

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 description coverage is 100%, so each parameter is already documented. The description adds value by explaining that UIDs are permanent and referencing list_folders for folder names, which supplements the schema. However, it does not add deeper semantics beyond what the schema already states, so it aligns with the baseline 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?

The description states a precise action ('Move emails to a specified folder'), a specific resource (emails by UIDs), and implies the target folder. It clearly differentiates from sibling tools like delete, archive, or mark_as_read by focusing on moving to a folder, and the mention of UIDs adds specificity.

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 provides a prerequisite by pointing to list_folders for available folders, which aids usage, but it does not explicitly guide when to prefer this tool over alternatives like archive_emails or delete_emails. The usage is implied rather than explicitly contrasted with siblings, so it earns a middle score.

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

Deploy Server