Skip to main content
Glama
borystam

homepl-email-mcp

by borystam

mail_move

Destructive

Move or copy a specific email message to a folder, or move it to Trash, using account and UID details for precise mail organization.

Instructions

Move or copy one exact message to a folder, or move it to the configured Trash. Requires user intent and observed UIDVALIDITY. This does not permanently delete trash contents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYes
actionYes
folderYes
accountIdYes
destinationNo
uidValidityYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, non-idempotent, open-world. The description adds key context: it doesn't permanently delete Trash contents, and requires observed UIDVALIDITY. This goes beyond annotations usefully, though it doesn't detail permission requirements or error modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences front-loaded with the core action, then constraints. No waste, though the Trash exception could be integrated more naturally.

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?

Covers the 'what' and key behavioral caveats (user intent, UIDVALIDITY, non-permanent delete) but with six parameters at 0% schema description coverage and no output schema, it leaves significant gaps: what destination does, what happens on copy, return values, and error conditions.

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 is 0%, so the description should compensate for 6 undocumented parameters. It explains the UIDVALIDITY requirement and destination (via folder/Trash mention) but leaves accountId, folder, uid, and the move/copy/trash action semantics largely to the schema enum. Partial compensation only.

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 (move/copy) and resource (exact message to a folder/Trash). Clear enough to distinguish from siblings like mail_delete_permanently, though it doesn't explicitly name alternatives.

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?

Mentions 'Requires user intent' and distinguishes move-to-Trash from permanent deletion, implying when to use it. But it doesn't state when to use copy vs move vs trash, or route to siblings explicitly.

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