Skip to main content
Glama
hgn

Notmuch

by hgn

Search mail

mail_search
Read-only

Search a notmuch email database and return paged summaries of conversations or individual messages. Filter by query terms like sender, subject, and date ranges; choose granularity, sort order, and response format.

Instructions

Search notmuch and return a paged summary, at thread or message granularity.

Use granularity="threads" for "what conversations are there about Y": each row is one thread, dated by its newest (or oldest) matched message, with an authors column that can mix matched and unmatched participants (see the legend in the output). Use granularity="messages" for "the last mail from X" or "how many mails did X write": each row is one matching message with its own date, from and subject.

Do not use this to fetch full bodies (use mail_read_message / mail_read_thread) or to turn a person's name into addresses first (use mail_list_addresses; from: also matches notification mail that merely mentions the name).

Args: query: A notmuch query, e.g. 'from:alice subject:invoice'. See notmuch-search-terms(7) for the full syntax, including 'date:this_year..', 'date:last_month..', 'date:1Y..' and 'date:2026-01-01..2026-06-30' for date ranges. scope: Name of a configured scope to AND with query (see mail_list_scopes). Defaults to the configured default scope. limit: Maximum number of rows to return. Omit for all results (the default); set it only to cap the number returned, and when it truncates the total is still reported. offset: Number of matching rows to skip, for paging through results already seen. response_format: 'concise' (one line per row) or 'detailed' (adds message counts/tags for threads, or the message_id for messages). granularity: 'threads' (one row per conversation) or 'messages' (one row per matching message). sort: 'newest-first' or 'oldest-first'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNonewest-first
limitNo
queryYes
scopeNo
offsetNo
granularityNothreads
response_formatNoconcise
Behavior5/5

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

Discloses paging behavior, truncation reporting, mixing of matched/unmatched authors in the authors column, and output legend. Despite readOnlyHint being already declared, the description adds substantive behavioral context beyond the annotation.

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?

Well-structured with usage scenarios up front and a clear Args list. Bullet points make parameters easy to scan, and every sentence adds value without unnecessary verbosity.

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?

For a 7-param search tool with no output schema, the description covers return values, paging, granularity options, parameter semantics, and alternative tools. It is self-sufficient and complete.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by explaining all 7 parameters with examples, defaults, and syntax hints. The query parameter even points to external documentation and gives date range 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 clearly states the tool searches notmuch and returns a paged summary at thread or message granularity. It distinguishes from siblings like mail_read_message, mail_read_thread, and mail_list_addresses by explicitly stating what this tool does not do.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance for granularity='threads' vs 'messages' with concrete examples. It also names alternatives for fetching full bodies and address lookup, including a warning about from:<name> matching notification mail.

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/hgn/mcp-server-notmuch'

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