Skip to main content
Glama

get_attachment

Open email attachments from local mail files by specifying the message path and filename pattern. Extracts files to a temporary directory and launches them with the default application.

Instructions

Open attachments in email by providing the email path.

The tool downloads the attachment into a temp dir and open it.

The command includes the paths and the pattern of attachment files.

The prefix mu extract --target-dir /tmp --overwrite --play SHOULD NOT appear in command.

See the man page for mu extract.

MU EXTRACT(1) General Commands Manual MU EXTRACT(1)

NAME mu-extract - display and save message parts (attachments), and open them with other tools.

SYNOPSIS mu [COMMON-OPTIONS] extract [OPTIONS] [FILE]

   mu [COMMON-OPTIONS] extract [OPTIONS] FILE PATTERN

DESCRIPTION mu extract is the mu sub-command for extracting MIME-parts (e.g., attachments) from mail messages. The sub-command works on message files, and does not require the message to be indexed in the database.

   For attachments, the file name used when saving it is the name of the
   attachment in the message. If there is no such name, or when saving
   non-attachment MIME-parts, a name is derived from the message-id of the
   message.


   If you specify a regular express pattern as the second argument, all
   attachments with filenames matching that pattern will be extracted. The
   regular expressions are basic PCRE, and are case-sensitive by default;
   see pcre(3) for more details.


   Without any options, mu extract simply outputs the list of leaf MIME-
   parts in the message. Only `leaf' MIME-parts (including RFC822
   attachments) are considered, multipart/* etc. are ignored.


   Without a filename parameter, mu extract reads a message from standard-
   input. In that case, you cannot use the second, PATTERN parameter as
   this would be ambiguous; instead, use the --matches option.

EXTRACT OPTIONS -a, --save-attachments Save all MIME-parts that look like attachments.

--save-all Save all non-multipart MIME-parts.

--parts parts Only consider the following numbered parts (comma-separated list). The numbers for the parts can be seen from running mu extract without any options but only the message file.

--target-dir dir Save the parts in dir rather than the current working directory.

--overwrite Overwrite existing files with the same name; by default overwriting is not allowed.

-u,--uncooked By default, mu transforms the attachment filenames a bit (such as by replacing spaces by dashes); with this option, leave that to the minimum for creating a legal filename in the target directory.

--matches pattern Attachments with filenames matching pattern will be extracted. The regular expressions are basic PCRE, and are case-sensitive by default; see pcre(3) for more details.

--play Try to `play' (open) the attachment with the default application for the particular file type. On MacOS, this uses the open program, on other platforms it uses xdg-open. You can choose a different program by setting the MU_PLAY_PROGRAM environment variable.

COMMON OPTIONS -d, --debug Makes mu generate extra debug information, useful for debugging the program itself. Debug information goes to the standard logging location; see mu(1).

-q, --quiet Causes mu not to output informational messages and progress information to standard output, but only to the log file. Error messages will still be sent to standard error. Note that mu index is much faster with --quiet, so it is recommended you use this option when using mu from scripts etc.

--log-stderr Causes mu to not output log messages to standard error, in addition to sending them to the standard logging location.

--nocolor Do not use ANSI colors. The environment variable NO_COLOR can be used as an alternative to --nocolor.

-V, --version Prints mu version and copyright information.

-h, --help Lists the various command line options.

EXAMPLES To display information about all the MIME-parts in a message file: $ mu extract msgfile

   To extract MIME-part 3 and 4 from this message, overwriting existing
   files with the same name:
      $ mu extract --parts=3,4 --overwrite msgfile



   To extract all files ending in `.jpg' (case-insensitive):
      $ mu extract msgfile '.*\.jpg'



   To extract an mp3-file, and play it in the default mp3-playing
   application:
      $ mu extract --play msgfile 'whoopsididitagain.mp3'



   when reading from standard-input, you need --matches, so:
      $ cat msgfile | mu extract --play --matches 'whoopsididitagain.mp3'

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function that executes the 'get_attachment' tool. It runs the 'mu extract' command with --target-dir /tmp, --overwrite, and --play flags to download and open email attachments.
    def get_attachment(command: str) -> str:
        r"""Open attachments in email by providing the email path.
    
        The tool downloads the attachment into a temp dir and open it.
    
        The `command` includes the paths and the pattern of attachment files.
    
        The prefix `mu extract --target-dir /tmp --overwrite --play` SHOULD NOT appear in `command`.
    
        See the man page for `mu extract`.
        """
        import subprocess
    
        try:
            result = subprocess.run(
                ["mu", "extract", "--target-dir", "/tmp", "--overwrite", "--play"] + command.split(),
                capture_output=True,
                text=True,
                check=True,
            )
            return result.stdout.strip()
        except subprocess.CalledProcessError as e:
            return f"Error: {e.stderr.strip()}"
  • mu_mcp/mu_mcp.py:99-99 (registration)
    Registration of the 'get_attachment' tool with the MCP server using the mcp.tool decorator pattern.
    mcp.tool("get_attachment")(get_attachment)
Behavior4/5

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

With no annotations provided, the description carries the full burden and discloses key behavioral traits: it downloads files to a temporary directory, opens them with default applications (via mu extract --play), and modifies the filesystem. It also notes the internal command construction, though it does not mention error handling or blocking behavior.

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

Conciseness2/5

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

The first four sentences are concise and front-loaded with essential information. However, the description appends the entire mu extract man page (100+ lines), which includes irrelevant details (--nocolor, --version, etc.) that do not earn their place in a tool description, significantly harming 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?

Given that an output schema exists, the description appropriately avoids detailing return values. It covers the main workflow (download to temp, open) and references external documentation. However, the inclusion of the full man page creates information overload rather than focused completeness, and critical practical details (like error scenarios) are not highlighted.

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?

The schema has 0% description coverage. The description compensates by stating that the command parameter 'includes the paths and the pattern of attachment files' and specifies prohibited content. However, it lacks examples or detailed format specifications (e.g., whether it expects 'filepath pattern' or just 'filepath'), leaving some ambiguity.

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 clearly states the tool 'Open attachments in email by providing the email path' and mentions it downloads to a temp dir and opens the file. While it distinguishes implicitly from siblings (view/query) by focusing on attachments rather than message content, it does not explicitly contrast with them.

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?

The description provides a specific constraint that 'The prefix mu extract --target-dir /tmp --overwrite --play SHOULD NOT appear in command,' which guides correct invocation. However, it lacks explicit guidance on when to choose this tool over siblings like view or query, relying on the user to infer from the resource type.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielfleischer/mu-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server