Skip to main content
Glama
Sign In
apple-productivity-mcp

apple-productivity-mcp

by gambadio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

apple_mail_list_attachments

Read-onlyIdempotent

List attachment metadata for a specific Apple Mail message by providing its mail ID, optionally specifying account and mailbox.

Instructions

Read-only: list attachment metadata for one message.

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": {
      "mailId": "<mailId>"
    },
    "name": "apple_mail_list_attachments"
  }
}

Input Schema

NameRequiredDescriptionDefault
mailIdYes
accountNoiCloud
mailboxNoINBOX

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's 'Read-only' prefix is redundant. The genuinely additive term is 'metadata', which signals the tool returns attachment descriptors rather than downloading files. Beyond that, no auth, pagination, or return-shape context is given.

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?

A single front-loaded sentence with zero filler. It is efficient, though its brevity is partly under-specification rather than pure conciseness.

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?

This is a low-complexity list tool and annotations cover the safety profile, so the description need not do much. However, with no output schema and 0% param coverage, an agent still lacks the attachment fields returned and how account/mailbox scope the lookup.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only implies that a single message is targeted. The 'account' and 'mailbox' parameters with their iCloud/INBOX defaults are left entirely unexplained. This does not compensate for the coverage gap.

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 (list) and resource (attachment metadata) scoped to one message. The word 'metadata' distinguishes it from apple_mail_save_attachment, which presumably retrieves actual content. It does not name a sibling explicitly, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use guidance, no exclusions, and no named alternative. The phrase 'for one message' implies a mailId is required but does not tell the agent how this relates to apple_mail_get or apple_mail_save_attachment. Only the implicit 'metadata vs content' framing offers any routing signal.

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

Deploy Server

Other Tools