Skip to main content
Glama

mu-mcp: MCP Server for the mu Mail Indexer

GitHub release GitHub license

A Model Context Protocol (MCP) server for querying your local mu mail index. This server enables fast, structured mail search from Claude Desktop and other MCP clients.

Features

  • Stdio MCP server for easy integration

  • Three tools: query, view emails and open attachments (using default OS viewer).

  • Fast, flexible mail search using the mu index

  • Claude Desktop ready: simple installation and config

  • Python, pixi, and MCP SDK based

Related MCP server: Gmail Plugin MCP Server

Installation

Clone this repository and install dependencies:

git clone https://github.com/danielfleischer/mu-mcp.git
cd mu-mcp
pixi install

Usage

Run the MCP Server

With pixi:

pixi run start

Or directly with Python:

python mu_mcp/mu_mcp.py

Claude Desktop Integration

Add to your claude_desktop_config.json:

"mcpServers": {
  "mu_mcp": {
    "command": "pixi",
    "args": [
      "run",
      "--manifest-path",
      "PROJECT_PATH",
      "start"
    ]
  }
}

Query

Ask Claude to find emails, e.g. "Find emails with a PDF attachment that were sent last April and open the PDF", "Show me the email I received from Alice last week", or "Find emails with the subject 'Meeting Notes'".

Development

  • Adding a tool to view an email.

  • Adding a tool to find and download attachments.

Available Tools

4 tools
get_attachmentB

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'
ParametersJSON Schema
NameRequiredDescriptionDefault
commandYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior3/5

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

The description discloses that the tool downloads the attachment to a temp dir and opens it, and warns about the command prefix. However, it lacks details on side effects, idempotency, or permissions, and the manpage dump is noisy.

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 description is unnecessarily long, including a full man page. The key information is front-loaded but diluted by excessive detail, making it less efficient for an AI agent.

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

Completeness2/5

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

The description does not explain the return value, error handling, or prerequisites despite having an output schema. It leaves gaps for an AI agent to infer.

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% coverage, and the description adds meaning by stating that command includes paths and pattern, and warns about forbidden prefix. But it is not fully explicit about the expected format.

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 first sentence clearly states the tool opens attachments in email by providing the email path. It distinguishes from sibling tools like health_check, query, and view.

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 implies usage for opening attachments but does not explicitly state when to use it versus alternatives or provide when-not-to-use guidance.

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

health_checkB

Health check for the MCP server.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the burden of disclosing behavior. It only says 'health check,' which implies a non-destructive read operation but does not specify details like what is checked or whether it affects server state.

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?

Extremely concise with one sentence that front-loads the purpose. No unnecessary words.

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?

For a simple tool with zero parameters and an output schema, the description is minimally adequate but lacks specifics like what the health check returns or covers. An output schema exists, so return values are documented, but the description could still add 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?

The tool has no parameters, so the description does not need to add parameter details. The input schema is fully covered (100% coverage), but the description adds no additional value beyond stating the purpose.

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 it's a health check for the MCP server, which distinguishes it from sibling tools like get_attachment, query, and view. However, it could be more specific about what 'health check' entails.

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 guidance on when to use this tool versus alternatives. For a health check, it's typically used to verify server status, but the description lacks explicit context or exclusion criteria.

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

queryC

Query mu by providing a valid query to be sent in the following way.

Syntax:

mu find $query

Here is the syntax guide for mu queries.

MU FIND(1) General Commands Manual MU FIND(1)

NAME mu-find - find e-mail messages in the mu database.

SYNOPSIS mu [COMMON-OPTIONS] find [OPTIONS] SEARCH_EXPRESSION

DESCRIPTION mu find is the mu command for searching e-mail message that were stored earlier using mu index(1).

SEARCHING MAIL mu find starts a search for messages in the database that match some search pattern. The search patterns are described in detail in mu- query(7).

   For example:

      $ mu find subject:snow and date:2009..



   would find all messages in 2009 with `snow' in the subject field, e.g:

      2009-03-05 17:57:33 EET Lucia  <lucia@example.com> running in the snow
      2009-03-05 18:38:24 EET Marius <marius@foobar.com> Re: running in the snow

FIND OPTIONS The find-command has various options that influence the way mu displays the results. If you don't specify anything, the defaults are --fields="d f s", --sortfield=date and --reverse.

-f, --fields fields Specifies a string that determines which fields are shown in the output. This string consists of a number of characters (such as 's' for subject or 'f' for from), which will replace with the actual field in the output. Fields that are not known will be output as-is, allowing for some simple formatting.

   For example:

      $ mu find subject:snow --fields "d f s"



   lists the date, subject and sender of all messages with `snow' in the
   their subject.


   The table of replacement characters is superset of the list mentions
   for search parameters, such as:
      t       *t*o: recipient
      d       Sent *d*ate of the message
      f       Message sender (*f*rom:)
      g       Message flags (fla*g*s)
      l       Full path to the message (*l*ocation)
      s       Message *s*ubject
      i       Message-*i*d
      m       *m*aildir



   For the complete list, try the command: mu info fields.

-s, --sortfield field and -z,--reverse Specify the field to sort the search results by and the direction (i.e., `reverse' means that the sort should be reverted - Z-A). Examples include:

      cc,c	      Cc (carbon-copy) recipient(s)
      date,d	      Message sent date
      from,f	      Message sender
      maildir,m       Maildir
      msgid,i	      Message id
      prio,p	      Nessage priority
      subject,s       Message subject
      to,t	      To:-recipient(s)



   For the complete list, try the command: mu info fields.


   Thus, for example, to sort messages by date, you could specify:

      $ mu find fahrrad --fields "d f s" --sortfield=date --reverse

-n, --maxnum number If number > 0, display maximally that number of entries. If not specified, all matching entries are displayed.

--summary-len number If number > 0, use that number of lines of the message to provide a summary.

--format plain|links|xml|sexp Output results in the specified format.

   —   The default is plain, i.e normal output with one line per message.

   —   links outputs the results as a maildir with symbolic links to the
   found messages. This enables easy integration with mail-clients
   (see below for more information). This requires --linksdir.

   —   xml formats the search results as XML.

   —   sexp formats the search results as an s-expression as used in Lisp
   programming environments.

--linksdir dir and -c, --clearlinks When using --format=links, output the results as a maildir with symbolic links to the found messages. This enables easy integration with mail-clients (see below for more information). mu will create the maildir if it does not exist yet.

--after timestamp Only show messages whose message files were last modified (mtime) after timestamp. timestamp is a UNIX time_t value, the number of seconds since 1970-01-01 (in UTC).

   From the command line, you can use the date command to get this value.
   For example, only consider messages modified (or created) in the last 5
   minutes, you could specify
      --after=`date +%s --date='5 min ago'`

-b, --bookmark bookmark Use a bookmarked search query. Using this option, a query from your bookmark file will be prepended to other search queries. See mu- bookmarks(5) for the details of the bookmarks file.

-u, --skip-dups Whenever there are multiple messages with the same message-id field, only show the first one. This is useful if you have copies of the same message, which is a common occurrence when using e.g. Gmail together with offlineimap.

-r, --include-related Include messages being referred to by the matched messages -- i.e.. include messages that are part of the same message thread as some matched messages. This is useful if you want Gmail-style `conversations'.

-t, --threads Show messages in a `threaded' format -- that is, with indentation and arrows showing the conversation threads in the list of matching messages. When using this, sorting is chronological (by date), based on the newest message in a thread.

   Messages in the threaded list are indented based on the depth in the
   discussion, and are prefix with a kind of arrow with thread-related
   information about the message, as in the following table:
      | 	    | normal | orphan | duplicate |
      |-------------+--------+--------+-----------|
      | first child | `->    | `*>    | `=>	  |
      | other	    | |->    | |*>    | |=>	  |MU QUERY(7)	       Miscellaneous Information Manual 	   MU QUERY(7)

NAME mu-query - a language for finding messages in mu databases.

DESCRIPTION The mu query language is the language used by mu find and mu4e to find messages in mu's Xapian database. The language is quite similar to Xapian's default query-parser, but is an independent implementation that is customized for the mu/mu4e use-case.

   Here, we give a structured but informal overview of the query language
   and provide examples. As a companion to this, we recommend the mu info
   fields command to get an up-to-date list of the available fields and
   flags.


   NOTE: if you use queries on the command-line (say, for mu find), you
   need to quote any characters that would otherwise be interpreted by the
   shell, such as *--analyze option can be useful.

TERMS The basic building blocks of a query are terms; these are just normal words like "banana" or "hello", or words prefixed with a field-name which makes them apply to just that field. See mu info fields for all the available fields.

   Some example queries:

      vacation
      subject:capybara
      maildir:/inbox


   The language is case-insensitive for terms and attempts to "flatten"
   diacritics, so angtrom matches Ångström.


   If terms contain whitespace, they need to be quoted.

      subject:"hi there"

Quoting queries for the shell Remember that you need to escape the quotes for a search query when using this from the command-line; otherwise, the shell (or most shells) process the queries and mu never sees them.

LOGICAL OPERATORS We can combine terms with logical operators -- binary ones: and, or, xor and the unary not, with the conventional rules for precedence and association. The operators are case-insensitive.

   You can also group things with ( and ), so you can write:
      (subject:beethoven or subject:bach) and not body:elvis

   Note that a pure not - e.g. searching for not apples is quite a "heavy"
   query.

WILDCARDS Wildcards are a Xapian built-in mechanism for matching.

   A search term with a rightmost * (and only in that position) matches
   any term that starts with the part before the *; they are less powerful
   than regular expressions, but also much faster:


   An example:
      $ mu find "hello*"

REGULAR EXPRESSIONS The query language supports matching basic PCRE regular expressions, as per pcre(3), with some limitations.

   Regular expressions are enclosed in //. For example:

      subject:/h.llo/	       # match hallo, hello, ...



   Note the difference between "maildir:/foo" and "maildir:/foo/"; the
   former matches messages in the "/foo" maildir, while the latter matches
   all messages in all maildirs that match "foo", such as "/foo",
   "/bar/cuux/foo", "/fooishbar", and so on.

Whitespace in regular expression literals To avoid ambiguities in the query parsing, regular express must not contain whitespace, so the search for a message with subject "hello world", you can write mu find 'subject:/hello\040world/'

   In many cases, mu find 'subject:/hello.world/'
   may be good enough, and easier to type.

FIELDS We already saw a number of search fields, such as subject: and body:. For the full table with all details, including single-char shortcuts, try the command: mu info fields.

      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | field-name | alias     | short | search  | value | sexp | example query 		| description			   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | bcc	   |	       | h     | phrase  | yes	 | yes	| bcc:foo@example.com		| Blind carbon-copy recipient	   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | body	   |	       | b     | phrase  | no	 | no	| body:capybara 		| Message plain-text body	   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | cc	   |	       | c     | phrase  | yes	 | yes	| cc:quinn@example.com		| Carbon-copy recipient 	   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | changed    |	       | k     | range	 | yes	 | yes	| changed:30M.. 		| Last change time		   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | date	   |	       | d     | range	 | yes	 | yes	| date:20220101..20220505	| Message date			   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | embed	   |	       | e     | phrase  | no	 | no	| embed:war OR embed:peace	| Embedded text 		   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | file	   |	       | j     | boolean | no	 | no	| file:/image\.*.jpg/		| Attachment file name		   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | flags	   | flag      | g     | boolean | yes	 | yes	| flag:unread AND flag:personal | Message properties		   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | from	   |	       | f     | phrase  | yes	 | yes	| from:jimbo			| Message sender		   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | language   | lang      | a     | boolean | yes	 | yes	| lang:nl			| ISO 639-1 language code for body |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | maildir    |	       | m     | boolean | yes	 | yes	| maildir:/private/archive	| Maildir path for message	   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | list	   |	       | v     | boolean | yes	 | yes	| list:mu-discuss.example.com	| Mailing list (List-Id:)	   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | message-id | msgid     | i     | boolean | yes	 | yes	| msgid:abc@123 		| Message-Id			   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | mime	   | mime-type | y     | boolean | no	 | no	| mime:image/jpeg		| Attachment MIME-type		   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | path	   |	       | l     | boolean | yes	 | yes	| path:/a/b/Maildir/cur/msg:2,S | File system path to message	   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | priority   | prio      | p     | boolean | yes	 | yes	| prio:high			| Priority			   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | references | ref       | r     | boolean | yes	 | yes	|				| References to related messages   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | size	   |	       | z     | range	 | yes	 | yes	| size:1M..5M			| Message size in bytes 	   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | subject    |	       | s     | phrase  | yes	 | yes	| subject:wombat		| Message subject		   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | tags	   | tag       | x     | boolean | yes	 | yes	| tag:projectx			| Message tags			   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | thread	   |	       | w     | boolean | yes	 | no	|				| Thread a message belongs to	   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+
      | to	   |	       | t     | phrase  | yes	 | yes	| to:flimflam@example.com	| Message recipient		   |
      +------------+-----------+-------+---------+-------+------+-------------------------------+----------------------------------+



   There are also combination fields which allow you to search for
   multiple related fields at once:

      # Combination fields
      +-------------+-----------------------------------------+
      | combi-field | fields				      |
      +-------------+-----------------------------------------+
      | recip	    | to, cc, bcc			      |
      +-------------+-----------------------------------------+
      | contact     | to, cc, bcc, from 		      |
      +-------------+-----------------------------------------+
      | related     | message-id, references		      |
      +-------------+-----------------------------------------+
      | <empty>     | to, cc, bcc, from, subject, body, embed |
      +-------------+-----------------------------------------+

DATE RANGES The date: field takes a date-range, expressed as the lower and upper bound, separated by ... Either lower or upper (but not both) can be omitted to create an open range.

   Dates are expressed in local time and using ISO-8601 format (YYYY-MM-DD
   HH:MM:SS); you can leave out the right part and mu adds the rest,
   depending on whether this is the beginning or end of the range (e.g.,
   as a lower bound, "2015" would be interpreted as the start of that
   year; as an upper bound as the end of the year).


   You can use `/' , `.', `-', `:' and "T" to make dates more human-
   readable.


   Some examples:
      date:20170505..20170602
      date:2017-05-05..2017-06-02
      date:..2017-10-01T12:00
      date:2015-06-01..
      date:2016..2016



   You can also use the special "dates" now and today:
      date:20170505..now
      date:today..



   Finally, you can use relative "ago" times which express some time
   before now and consist of a number followed by a unit, with units s for
   seconds, M for minutes, h for hours, d for days, w for week, m for
   months and y for years. Some examples:

      date:3m..
      date:2017.01.01..5w

SIZE RANGES The size or z field allows you to match size ranges -- that is, match messages that have a byte-size within a certain range. Units (b (for bytes), K (for 1000 bytes) and M (for 1000 * 1000 bytes) are supported). Some examples:

      size:10k..2m
      size:10m..

FLAG FIELD The flag/g field allows you to match message flags. The following fields are available: +-----------+----------+----------+-----------------------------+ | flag | shortcut | category | description | +-----------+----------+----------+-----------------------------+ | draft | D | file | Draft (in progress) | +-----------+----------+----------+-----------------------------+ | flagged | F | file | User-flagged | +-----------+----------+----------+-----------------------------+ | passed | P | file | Forwarded message | +-----------+----------+----------+-----------------------------+ | replied | R | file | Replied-to | +-----------+----------+----------+-----------------------------+ | seen | S | file | Viewed at least once | +-----------+----------+----------+-----------------------------+ | trashed | T | file | Marked for deletion | +-----------+----------+----------+-----------------------------+ | new | N | maildir | New message | +-----------+----------+----------+-----------------------------+ | signed | z | content | Cryptographically signed | +-----------+----------+----------+-----------------------------+ | encrypted | x | content | Encrypted | +-----------+----------+----------+-----------------------------+ | attach | a | content | Has at least one attachment | +-----------+----------+----------+-----------------------------+ | unread | u | pseudo | New or not seen message | +-----------+----------+----------+-----------------------------+ | list | l | content | Mailing list message | +-----------+----------+----------+-----------------------------+ | personal | q | content | Personal message | +-----------+----------+----------+-----------------------------+ | calendar | c | content | Calendar invitation | +-----------+----------+----------+-----------------------------+

   Some examples:
      flag:attach
      flag:replied
      g:x

PRIORITY FIELD The message priority field (prio:) has three possible values: low, normal or high. For instance, to match high-priority messages: prio:high

MAILDIR The Maildir field describes the directory path starting after the Maildir root directory, and before the /cur/ or /new/ part. So, for example, if there's a message with the file name ~/Maildir/lists/running/cur/1234.213:2,, you could find it (and all the other messages in that same maildir) with: maildir:/lists/running

   Note the starting `/'. If you want to match mails in the "root"
   maildir, you can do with a single `/':
        maildir:/

MORE EXAMPLES

   Find all messages with both "bee" and "bird" (in any field)
      bee AND bird


   Find all messages with either Frodo or Sam:
      Frodo OR Sam

   Find all messages with the "wombat" as subject, and "capybara"
   anywhere:
      subject:wombat and capybara

   Find all messages in the "Archive" folder from Fred:
      from:fred and maildir:/Archive

   Find all unread messages with attachments:
      flag:attach and flag:unread

   Find all messages with PDF-attachments:
      mime:application/pdf

   Find all messages with attached images:
      mime:image/*
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool searches/finds email messages, implying read-only, but does not explicitly declare side effects, permissions, or rate limits. The extensive focus on query syntax leaves behavioral traits unaddressed.

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

Conciseness1/5

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

The description is a huge wall of text, clearly copied from a man page. It is not front-loaded, and most of the content is irrelevant for an agent invoking the tool. Every sentence does not earn its place; the description is severely overlong and poorly structured.

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

Completeness2/5

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

Despite the existence of an output schema, the description does not explain return values or the overall behavior beyond finding messages. It discusses command-line options that are not part of the tool's parameters, creating confusion. The description is detailed for input but incomplete for the tool's actual interface and output.

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 0%, so the description must compensate. It does so with a detailed guide on the query language, covering syntax, operators, fields, etc. This provides substantial meaning beyond the bare schema parameter name. However, the information is not structured as parameter-level docs and includes many options not reflected in the actual parameter (e.g., formatting options), which slightly reduces clarity.

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 starts with 'Query `mu` by providing a valid query', clearly stating the verb and resource. It distinguishes from siblings (get_attachment, health_check, view) by focusing on searching mu. However, the purpose is somewhat buried in a large block of text, making it less immediately clear.

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 guidance on when to use this tool vs alternatives. The description provides examples but does not compare with siblings or state when not to use it. The agent must infer usage from context.

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

viewA

View emails using mu, by providing their paths.

mu view $paths

Paths can be extracted using the following:

mu find --fields "l" SOME_QUERY
ParametersJSON Schema
NameRequiredDescriptionDefault
pathsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, and the description lacks any behavioral disclosure such as read-only nature, side effects, authentication needs, or error conditions. It only states the basic action.

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 description is very concise at two sentences plus code examples, with no extraneous information. Every element serves a purpose.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, output schema exists), the description is largely complete. It covers the core action and provides a usage example, though it could mention expected output or behavior.

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?

With 0% schema description coverage, the description adds limited value by mentioning that paths come from mu find, but does not explain path format, constraints, or validation beyond the schema's title 'Paths'.

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 clearly states 'View emails using mu, by providing their paths,' which is a specific verb and resource. It includes an example and distinguishes from sibling tools like query and get_attachment.

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 an example of extracting paths via mu find, implying prerequisites, but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv0.3.0
    • First observedget_attachment
    • First observedhealth_check
    • First observedquery
    • First observedview

TDQS

B3.3/5.0
Disambiguation5/5

The four tools have clearly distinct purposes: extracting attachments, checking server health, executing search queries, and viewing email contents. There is no ambiguity between them.

Naming Consistency4/5

All tool names use lowercase snake_case. 'get_attachment' follows verb_noun pattern, while 'query' and 'view' are single verbs but still consistent in style. 'health_check' is adjective_noun. Minor inconsistency in structure but clear naming.

Tool Count4/5

With only 4 tools, the server is concise but covers essential email interactions (search, view, attachment extraction) plus health check. Could benefit from a few more like listing folders, but the count is reasonable for its scope.

Completeness3/5

The server provides core read operations (query, view, attachment extraction) but lacks write capabilities like sending, deleting, or moving messages. This limits workflow completeness for email management.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    A Model Context Protocol server that provides a seamless email management interface through Claude, allowing users to search, read, and send emails directly through natural language conversations.
    4
    114
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables Gmail integration, allowing users to manage emails (send, receive, read, trash, mark as read) directly through MCP clients like Claude Desktop.
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A cross-platform MCP server that provides Claude with email access via IMAP, supporting multiple email providers and account management.
    MIT

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