Skip to main content
Glama

Manage inbox

manage_inbox

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": {
      "action": "<action>"
    },
    "name": "manage_inbox"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesThe operation to perform. One of: - 'list_labels': List available labels (Gmail) or categories (Outlook). - 'apply_label': Apply a label/category to emails. Creates if it doesn't exist. Requires email_ids and label_name. - 'remove_label': Remove a label/category from emails. Requires email_ids and label_name. - 'archive': Archive emails (removes from inbox, keeps in account). Requires email_ids. - 'mark_read': Mark emails as read. Requires email_ids. - 'unsubscribe': Unsubscribe from a mailing list via List-Unsubscribe header. Requires email_ids (one email). ALWAYS confirm with the user before calling this. - 'search_by_label': Search emails by label (Gmail) or category (Outlook). Requires label_name. Returns matching emails directly from the provider API.
mailboxNoEmail address of a connected mailbox, for list_labels and search_by_label. When the user has multiple mailboxes and neither mailbox nor email_ids is given, ask which to use.
providerNoWhich email account to use ('outlook' or 'gmail'). Only needed if the user has both connected and no email_ids are provided.
email_idsNoList of email IDs from search_emails results. They may come from several mailboxes; each email is acted on in its own.
label_nameNoLabel name for apply_label, remove_label, or search_by_label actions.
max_resultsNoMaximum number of emails to return for search_by_label (default 20, max 50).
on_behalf_ofNoA teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
exclusive_labelsNoFor apply_label only. A set of mutually exclusive labels (e.g. inbox organization categories). When provided, applying a label automatically removes any other exclusive_labels from older messages in the same thread. This keeps one label per thread.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / email_ids / description
      Previous value: -"List of email IDs from search_emails results."New value: +"List of email IDs from search_emails results. They may come from several\nmailboxes; each email is acted on in its own."
    • changedInput schema / properties / mailbox / description
      Previous value: -"Email address of a connected mailbox. Optional — when not given and\nemail_ids are present, the mailbox is inferred from the email row's\nconnected_email. When neither is available and the user has multiple\nmailboxes, ask which to use."New value: +"Email address of a connected mailbox, for list_labels and search_by_label.\nWhen the user has multiple mailboxes and neither mailbox nor email_ids is given,\nask which to use."
  2. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"A teammate's email (one with team actions turned on), or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  3. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"Act on a consented teammate's inbox instead of your own — pass\ntheir email. Every action (label, archive, mark read, unsubscribe) runs\nagainst their mailbox. Gated on that teammate's act-on-behalf setting\n(stricter than conversation sharing); a teammate who hasn't granted it is\nrejected. Omit for your own inbox.\nOr pass an agency client's email, from list_agency_clients, to run the call in that client's account, where none of the teammate limits above apply."New value: +"A teammate's email (one with team actions turned on), or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  4. Changed2 schema fields changed
    • removedInput schema / properties / as_teammate
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Act on a consented teammate's inbox instead of your own — pass\ntheir email. Every action (label, archive, mark read, unsubscribe) runs\nagainst their mailbox. Gated on that teammate's act-on-behalf setting\n(stricter than conversation sharing); a teammate who hasn't granted it is\nrejected. Omit for your own inbox."
      -}
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Act on a consented teammate's inbox instead of your own — pass\ntheir email. Every action (label, archive, mark read, unsubscribe) runs\nagainst their mailbox. Gated on that teammate's act-on-behalf setting\n(stricter than conversation sharing); a teammate who hasn't granted it is\nrejected. Omit for your own inbox.\nOr pass an agency client's email, from list_agency_clients, to run the call in that client's account, where none of the teammate limits above apply."
      +}
  5. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation/read profile is at least conveyed structurally. Beyond that the description adds genuinely useful context the annotations do not cover — there is no output schema, and the <returns> block explains the multi-mailbox result shape and the per-mailbox success/error form. What it fails to disclose is the irreversibility of archive and unsubscribe and the fact that it dispatches to provider-specific semantics (Gmail labels vs Outlook categories), which is the kind of behavioral warning an agent needs before mutating.

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?

The summary sentence is front-loaded and free of filler, and the <returns> block earns its space because no output schema exists. Minor cost: the capability list is enumerated inconsistently with the actual enum (four of seven actions), which is wasted opportunity rather than verbosity.

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?

With 8 parameters, a 7-value action enum, and no output schema, the definition leans heavily on the schema, which is fine — the return shape is covered. But the description undersells the tool's scope by listing four actions, gives no confirmation-safety signal for the destructive unsubscribe path, and draws no boundary against the sibling list/search tools, leaving real gaps for a dispatcher-style tool of this complexity.

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% and every parameter, including the seven-value action enum and the exclusive_labels side effect, is documented in the schema. The description body adds no parameter meaning beyond that, so the baseline of 3 is appropriate — the schema does the work, the prose does not supplement it.

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?

The description names the resource (emails in the user's inbox) and enumerates concrete capabilities (labeling, archiving, mark-read, unsubscribe), which is far more specific than the bare name 'manage_inbox'. However, it omits two of the seven supported actions — list_labels and search_by_label — so an agent searching for a read/lookup path would not learn from the summary that this tool provides one, and no sibling (e.g. list_inbox_conversations) is referenced for differentiation.

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?

Usage is only implied by the enumerated capabilities; there is no explicit when-to-use or when-not statement and no named alternative. The most important usage rule in the whole definition — 'ALWAYS confirm with the user before calling this' for unsubscribe, and 'ask which mailbox to use' — lives in the schema property descriptions rather than in the description body, so the top-level text contributes no routing guidance.

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