How do I use ietf-imap-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ietf-imap-mcp Search ietf mailing list for recent messages on QUIC" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ietf-imap-mcp

by OR13

Overview Schema Related Servers Score Discussions

Python

Remote

ietf-imap-mcp

An MCP server for navigating IETF mailing-list archives over the IETF IMAP service (imap.ietf.org:993). It lets an MCP-capable assistant search, page through, and read list traffic — handy when chairing a working group or BoF and you need to track what the list is actually saying.

Built to be a good citizen of shared IETF infrastructure. See Respecting IETF resources.

Tools

Tool	What it does
`list_mailing_lists(pattern, limit)`	Discover list mailboxes (IMAP `LIST`).
`search_list(list_name, subject, from_addr, text, since, before, limit)`	Search a list; returns message summaries, newest first.
`page_list(list_name, offset, limit)`	Page through a list's messages, newest first.
`get_message(list_name, uid, include_body, max_body_chars)`	Fetch one message (headers + plain-text body) by UID.

Related MCP server: simple-email-mcp

Configuration

All configuration is via environment variables — no credentials are ever stored in the code or the repo.

Variable	Purpose	Default
`IETF_IMAP_USER`	`anonymous`, or your Datatracker username	`anonymous`
`IETF_IMAP_EMAIL`	Email used as the password for anonymous access	—
`IETF_IMAP_PASSWORD`	Datatracker password (authenticated access) — plaintext	—
`IETF_IMAP_PASSWORD_CMD`	Shell command whose stdout is the password (e.g. `op read …`)	—
`IETF_IMAP_PASSWORD_FILE`	Path to a file containing the password	—
`IETF_IMAP_MIN_INTERVAL`	Minimum seconds between IMAP commands	`1.0`
`IETF_IMAP_MAILBOX_PREFIX`	Prefix for bare list names	`Shared Folders/`

See .env.example for a copy-paste starting point.

Authentication

Per the IETF lists page, the IMAP service supports two modes.

Anonymous (recommended for public lists)

IMAP anonymous login uses your email address in the password field — this is not a secret. This is all you need for public list archives:

{
  "mcpServers": {
    "ietf-imap": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/ietf-imap-mcp", "python", "-m", "ietf_imap_mcp"],
      "env": { "IETF_IMAP_USER": "anonymous", "IETF_IMAP_EMAIL": "you@example.org" }
    }
  }
}

Authenticated (Datatracker — only when anonymous is not possible)

Set IETF_IMAP_USER to your Datatracker username and supply the password. The password is resolved in this order of preference: IETF_IMAP_PASSWORD → IETF_IMAP_PASSWORD_CMD → IETF_IMAP_PASSWORD_FILE.

⚠️ Keep the secret out of the config file. Values in an MCP client's env block sit in plaintext on disk (and often sync to the cloud). Prefer IETF_IMAP_PASSWORD_CMD (resolve from a secret manager at launch) or IETF_IMAP_PASSWORD_FILE (a chmod 600 file). Avoid IETF_IMAP_PASSWORD except for throwaway local testing, and never put a real password in a file you commit.

Recommended — resolve from a secret manager (no secret on disk):

{
  "mcpServers": {
    "ietf-imap": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/ietf-imap-mcp", "python", "-m", "ietf_imap_mcp"],
      "env": {
        "IETF_IMAP_USER": "your-datatracker-username",
        "IETF_IMAP_PASSWORD_CMD": "op read \"op://Private/IETF Datatracker/password\""
      }
    }
  }
}

(op is the 1Password CLI; substitute pass, gopass, security find-generic-password, vault kv get, etc.)

Alternative — a permission-restricted file:

install -m 600 /dev/null ~/.config/ietf-imap/datatracker.pw
printf '%s' 'your-password' > ~/.config/ietf-imap/datatracker.pw

"env": {
  "IETF_IMAP_USER": "your-datatracker-username",
  "IETF_IMAP_PASSWORD_FILE": "~/.config/ietf-imap/datatracker.pw"
}

Run

uv run ietf-imap-mcp          # stdio MCP server
# or
uv run python -m ietf_imap_mcp

Respecting IETF resources

The IMAP server is shared infrastructure. This server:

Read-only — mailboxes are opened with EXAMINE, never SELECT; it cannot flag, move, or delete anything.
Rate-limited — a minimum interval (default 1s) is enforced between IMAP commands.
Bounded — result counts are hard-capped (≤ 100 per call) so one call can't pull thousands of messages.
Connection-reusing — one TLS connection is kept open rather than reconnecting per call.

Please don't lower the interval or remove the caps to hammer the service. For bulk needs, use rsync archive downloads instead.

Development

uv run pytest        # tests are fully mocked — no network, no live IMAP

License

Available Tools

4 tools

get_messageA

Fetch a single message by UID (from a prior search/page result).

Args: list_name: Mailbox / list name, e.g. "agent2agent". uid: The message UID returned by search_list / page_list. include_body: Include the plain-text body (default True). max_body_chars: Truncate the body to this many characters.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`list_name`	Yes
`include_body`	No
`max_body_chars`	No

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that include_body defaults to True and max_body_chars truncates the body, which is useful behavioral detail. However, it doesn't mention what happens if the UID is not found, or any other side effects or error behavior.

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 concise and well-structured: a single clear purpose sentence followed by a bullet-like arg list. Every sentence earns its place, no filler or repetition.

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?

With no output schema, the description might need to cover return format, but it's a simple get operation. The parameters are fully documented, usage context is clear, and behavioral details like truncation are provided. Minor gap: no mention of error/not-found behavior, but overall it's adequate for a straightforward tool.

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?

Schema coverage is 0%, but the description fully compensates by explaining each parameter: list_name is the mailbox/list name, uid is from search/page results, include_body controls body inclusion, max_body_chars truncates the body. This adds meaningful semantics beyond the bare schema.

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 begins with a specific verb+resource: "Fetch a single message by UID". It clearly distinguishes this from sibling tools (search_list, page_list) by stating it retrieves one message based on a UID from a prior search/page result.

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

Usage Guidelines4/5

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

The description states the UID must come from a prior search/page result, which implies the tool should be used after those. It gives clear context for when to use the tool, though it doesn't explicitly mention when not to use it or list alternatives.

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

list_mailing_listsA

List IETF mailing-list mailboxes available over IMAP.

Args: pattern: IMAP LIST pattern, e.g. "agent*" or "*". limit: Maximum mailbox names to return (hard-capped at 100).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`pattern`	No		*

TDQS

A4.3/5.0

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 of behavioral disclosure. It adds valuable context beyond the schema by noting the 'hard-capped at 100' limit for the 'limit' parameter, which is a concrete behavioral constraint. It also clarifies that the mailboxes are 'available over IMAP'. However, it does not mention permissions, error behavior, or whether the operation is read-only, though for a listing tool this is less critical.

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 concise and well-structured: a one-sentence purpose statement followed by a compact Args section. Every line contributes meaningful information without redundancy or fluff. It is appropriately sized for a tool with two simple parameters.

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?

The tool is simple with two parameters and no output schema, and the description covers its purpose and parameters well. It mentions the hard-cap for limit, which is important. However, it lacks any mention of the return format or pagination behavior, which could be relevant for a listing operation. Given the tool's simplicity, this is a minor gap.

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?

The input schema has 0% coverage, but the description fully compensates by explaining both parameters. For 'pattern', it provides IMAP LIST patterns with examples like '"agent*"' and '"*"'. For 'limit', it clarifies meaning and 'hard-capped at 100'. This adds semantic depth beyond the schema's type/default fields.

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's function: 'List IETF mailing-list mailboxes available over IMAP.' This provides a specific verb ('List'), a specific resource ('IETF mailing-list mailboxes'), and a specific context ('available over IMAP'), which distinguishes it from sibling tools like search_list or get_message that operate on messages rather than mailboxes.

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 gives a clear purpose but does not explicitly state when to use this tool over alternatives. It does not mention any conditions, prerequisites, or exclusions. The usage context is implied through the tool name and description, but there is no direct comparison to sibling tools, so the guidance is limited.

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

page_listA

Page through a list's messages, newest first.

Args: list_name: Mailbox / list name, e.g. "agent2agent". offset: How many messages back from the newest to start (0 = newest). limit: Page size (default 25, hard-capped at 100).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`list_name`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Discloses pagination order (newest first), offset semantics, and limit cap. With no annotations, the description carries full burden; still lacks return format and edge-case behavior.

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?

Two sections: purpose sentence and concise arg list with examples. No superfluous text, front-loaded.

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?

Good coverage of purpose and params, but no output schema or return value description. For a simple pagination tool, it is mostly complete, but return format would strengthen it.

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?

Schema has zero descriptions (0% coverage), and the description fully explains all three parameters with examples and constraints, adding significant meaning beyond the schema.

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?

Clearly states the tool pages through a list's messages newest first, with specific verb and resource. Distinguishes from siblings like search_list and get_message by focusing on sequential paging.

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?

Implies use for paging through messages but does not explicitly contrast with siblings. No when-not-to-use or alternatives mentioned.

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

search_listA

Search a mailing list, returning matching message summaries (newest first).

Args: list_name: Mailbox / list name, e.g. "agent2agent". subject: Substring to match in the Subject header. from_addr: Substring to match in the From header. text: Free-text search across the whole message. since: Only messages on/after this ISO date (YYYY-MM-DD). before: Only messages before this ISO date (YYYY-MM-DD). limit: Max summaries to return (default 25, hard-capped at 100).

ParametersJSON Schema

Name	Required	Description	Default
`text`	No
`limit`	No
`since`	No
`before`	No
`subject`	No
`from_addr`	No
`list_name`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses important behaviors: results are summaries, sorted newest first, limit defaults to 25 and hard-capped at 100. It doesn't mention pagination or error handling, but the described behavior is sufficient for basic usage.

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 a compact, well-structured docstring with a clear summary line followed by a parameter list. Every sentence is informative, no fluff, and the key behavior (newest first, default limit, cap) is front-loaded.

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?

The tool has no output schema and no annotations, so the description must cover return behavior. It states 'matching message summaries' and ordering, which is mostly adequate, though it could mention whether summaries contain message IDs or how to fetch full messages. Still, given the presence of sibling get_message, this is a minor gap.

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?

Schema coverage is 0%, so the description must fully explain parameters. It does so excellently: each parameter has a clear semantic ('substring to match', 'free-text across whole message', 'ISO date'), plus helpfully documents defaults and limits that aren't in the schema.

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 a mailing list and returns matching message summaries, with an explicit ordering (newest first). This is a specific verb+resource combination that distinguishes it from sibling tools like list_mailing_lists, page_list, and get_message.

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

Usage Guidelines4/5

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

The description provides clear context: it's for searching across messages in a mailing list with various filters. It doesn't explicitly state when to prefer this over alternatives, but the purpose is unambiguous from the name and description, giving the agent enough guidance to choose it appropriately.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation4/5

The tools are mostly distinct: list_mailing_lists discovers lists, search_list filters by criteria, page_list browses without filters, and get_message fetches a specific message. However, search_list with no criteria could overlap with page_list, though descriptions clarify the intended use.

Naming Consistency5/5

All four tool names follow a consistent verb_noun pattern (list_mailing_lists, search_list, page_list, get_message) with underscore separation, making the naming predictable and easy to navigate.

Tool Count5/5

With only 4 tools, the server is well-scoped for a read-only IMAP mailing list client. Each tool serves a clear purpose and the count is appropriate for the domain.

Completeness4/5

The core workflows are covered: discovering lists, searching or browsing messages, and fetching a full message. Minor gaps exist, such as no direct message count or raw header retrieval, but these are not critical for typical usage.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
AgentMail
to.agentmail
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email Communication
2
MCP Emails A
com.mcpemails
Read, search, send, organize, draft and schedule email across your inboxes from any MCP client.
Communication Email
25
gmail AOAuth
com.mintmcp
A MCP server for Gmail that lets you search, read, and draft emails and replies.
Communication App Automation Workplace & Productivity
48

Related MCP Servers

imap-mcp-server
Email Communication
vivier
A
license
Not graded
quality
C
maintenance
Bridges an MCP-capable agent to an IMAP4 mailbox, enabling folder exploration, message search, retrieval, keyword management, PGP/MIME decryption, and draft creation.
Updated 4 months ago (2026-04-30 18:51 UTC)
GPL 2.0
simple-email-mcp
mexican75
A
license
B
quality
B
maintenance
Enables users to manage email accounts via IMAP/SMTP, including reading, searching, sending emails with attachments and calendar invites, all through natural language interactions with MCP-compatible clients.
Updated 16 days ago (2026-08-18 20:03 UTC)
1
4
MIT
imap-mcp
Email Communication
LeeFlannery
A
license
A
quality
B
maintenance
Read-only MCP server that connects to multiple IMAP accounts, enabling cross-account email listing, search, and retrieval without modifying mailboxes.
Updated a month ago (2026-08-02 18:47 UTC)
4
MIT
MailBridge MCP
Email Communication
gexiro-global
A
license
Not graded
quality
A
maintenance
Enables MCP-compatible AI assistants to securely search multiple mailboxes, reconstruct email threads, and inspect attachments through read-only tools without altering mailbox state.
Updated 15 hours ago (2026-09-03 04:16 UTC)
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/OR13/ietf-imap-mcp'

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