Skip to main content
Glama

Assign emails to a colleague

assign_email
Idempotent

Hand messages to a named person on this mailbox, so their assistant sees them as theirs. person is their email address, or their name as the mailbox owner entered it; an ambiguous name or one that matches nobody is refused with the people who could have been meant, so ask the user which and call again. A claim is a marker the mail server keeps on the message, so every colleague's assistant on this mailbox sees it as heldBy in list_emails and search_emails, and reply_email, forward_email, draft_reply and draft_forward warn when the message is held by somebody else. It moves nothing and marks nothing read: the message stays exactly where it is, and a colleague reading the mailbox in Outlook sees nothing different. A message a mail client has moved since it was claimed keeps its marker but not the record of who: it reads as held by "someone", and force: true clears that. Assigning takes over a message somebody else already holds, and the result says whose claim was replaced. Only the owner and people currently active on the mailbox can be assigned to.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidsYesThe UIDs to act on, from list_emails or search_emails. Pass every message you want in ONE call: it costs the user one call instead of one per message. Up to 500 at a time.
personYesWho to assign to: an email address, or a name.
mailboxNoIMAP folder the messages are in. Defaults to INBOX.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Far beyond the annotations: it states the message is not moved, not marked read, and appears unchanged in Outlook, discloses that assignment takes over an existing claim and reports whose claim was replaced, describes the 'someone' degraded-claim state, and explains downstream warnings in reply/forward/draft tools. No contradiction with readOnlyHint=false/idempotentHint=true/destructiveHint=false.

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?

Purpose and the claim concept are front-loaded, and most sentences carry non-obvious behavior. It is dense and long for a 3-parameter tool, with slight redundancy ('It moves nothing and marks nothing read: the message stays exactly where it is'), but little is truly disposable.

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

Completeness5/5

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

No output schema exists, so the description must carry results and edge cases — and it does: it specifies what the result reports (whose claim was replaced), the ambiguity failure mode, the orphaned-claim state, and the visibility of the marker in other tools. An agent can call this correctly with no further context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning for `person` (email address, or a name as the owner entered it, with ambiguity refusal semantics). It also references a `force: true` argument that does not appear in the input schema, which is mildly confusing but signals behavior rather than mislabeling a documented param.

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 verb and resource — 'Hand messages to a named person on this mailbox' — and defines what 'assigned' means (a claim marker the mail server keeps). It clearly differentiates this from sibling operations like list_emails/search_emails/reply_email by describing how those tools surface the heldBy state.

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?

Strong contextual guidance: it says to ask the user and re-call when a name is ambiguous or matches nobody, explains when `force: true` is needed (orphaned marker after a client move), and restricts who can be assigned to (owner plus active people). It never names a sibling that should be used instead in a given situation, so it stops 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources