Inbox Triage

Mark people or domains as VIPs

add_vip

Idempotent

Adds email addresses and/or whole domains to the account VIP list. Addresses are stored lowercased and duplicates are ignored, so re-adding someone is safe. Returns only what was added and the new totals (not the whole VIP list, which can include other people's addresses). Say who you added in plain language afterwards. VIPs are account-wide and apply to every connected inbox. Messages from them come back with vip: true on list_messages and get_message, and VIP mail is never-auto: ask before archiving, labelling as junk, or unsubscribing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "add_vip"
  }
}

Input Schema

Name	Required	Description	Default
`emails`	No	Email addresses to mark as VIP, e.g. ["dana@client.com"]
`domains`	No	Bare domains to mark as VIP, e.g. ["client.com"]

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that addresses are stored lowercased, duplicates are ignored, and the return contains only what was added plus new totals rather than the full VIP list. It also explains downstream effects such as vip: true appearing on messages and VIP mail being never-auto, which is exactly the kind of behavioral context an agent needs.

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 core action is front-loaded in the first sentence, and every subsequent sentence adds useful scope, return shape, or follow-up guidance. There is no redundant padding despite the description being longer than a bare minimum.

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?

With no output schema, the description correctly explains what the tool returns: only the added entries and new totals, not the whole VIP list. It also covers account-wide scope and downstream VIP behavior, leaving nothing material missing for correct invocation.

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 parameter definitions already carry the baseline weight. The description still adds value by explaining that addresses are lowercased and duplicates are ignored, and by clarifying the emails/domains distinction in behavioral terms beyond the schema examples.

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 specific verb and resource: adding email addresses and/or whole domains to the account VIP list. It also distinguishes scope clearly by noting VIPs are account-wide and apply to every connected inbox, which differentiates it from inbox-specific siblings.

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 description provides clear context for when this tool is appropriate, including what the VIP status means downstream and how the agent should communicate the result. It does not explicitly name alternatives such as remove_vip or explain when not to use it, which keeps it below a 5.

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

All Inbox Triage tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?