Skip to main content
Glama
seandkendall

productivity-mcp

by seandkendall

list_email_accounts

Lists configured email accounts, including account labels, provider types, and all email addresses and aliases.

Instructions

List configured email accounts.

Each entry includes:

  • name: the account LABEL used as the account argument in other tools

  • kind: provider class (ImapEmailProvider / GmailProvider)

  • addresses: every email address this mailbox receives mail at — the primary login address PLUS any configured aliases. Use these when answering 'who emailed me at X?' questions; the name is NOT the user's email address.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The actual tool handler function for list_email_accounts. It returns a list of dicts with name, kind, and addresses from _email_providers.
    def list_email_accounts() -> list[dict[str, Any]]:
        """List configured email accounts.
    
        Each entry includes:
          - name: the account LABEL used as the `account` argument in other tools
          - kind: provider class (ImapEmailProvider / GmailProvider)
          - addresses: every email address this mailbox receives mail at — the
            primary login address PLUS any configured aliases. Use these when
            answering 'who emailed me at X?' questions; the `name` is NOT the
            user's email address.
        """
        return [
            {"name": name, "kind": p.__class__.__name__, "addresses": list(getattr(p, "addresses", []) or [])}
            for name, p in _email_providers.items()
        ]
  • The tool is registered via the @mcp.tool() decorator on line 94 and the @_logged decorator on line 95, which wraps the function for logging and rate-limiting.
    @mcp.tool()
    @_logged
    def list_email_accounts() -> list[dict[str, Any]]:
  • The _email_providers dict that stores the configured email providers, which list_email_accounts reads from.
    _email_providers: dict[str, EmailProvider] = {}
    _calendar_providers: dict[str, CalendarProvider] = {}
  • The return type is list[dict[str, Any]] and the function takes no arguments, as defined in the handler signature.
    def list_email_accounts() -> list[dict[str, Any]]:
        """List configured email accounts.
    
        Each entry includes:
          - name: the account LABEL used as the `account` argument in other tools
          - kind: provider class (ImapEmailProvider / GmailProvider)
          - addresses: every email address this mailbox receives mail at — the
            primary login address PLUS any configured aliases. Use these when
            answering 'who emailed me at X?' questions; the `name` is NOT the
            user's email address.
        """
        return [
            {"name": name, "kind": p.__class__.__name__, "addresses": list(getattr(p, "addresses", []) or [])}
            for name, p in _email_providers.items()
        ]
  • The _load() function populates _email_providers, which list_email_accounts depends on.
    def _load() -> None:
        cfg = load_config()
        for acct in cfg.email_accounts:
            _email_providers[acct.name] = build_email_provider(acct)
        for acct in cfg.calendar_accounts:
            _calendar_providers[acct.name] = build_calendar_provider(acct)
Behavior3/5

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

The description is straightforward and discloses the output structure, but with no annotations, it lacks explicit statements about safety or side effects. For a read-only list tool, this is adequate but not rich; the description could explicitly state that the operation is non-destructive.

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: a one-sentence summary followed by a clear bullet list. Every sentence adds value, and the structure is front-loaded. No unnecessary words or redundancy.

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?

Given the tool's simplicity (no parameters, output schema present), the description is complete. It explains the purpose and the meaning of each output field, which is essential for agents using account names and addresses in subsequent calls. No missing information for this use case.

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 input schema has zero parameters and 100% coverage, so the baseline is 3. The description adds no parameter information but does detail the output fields, which indirectly aids understanding. No parameter semantics are needed.

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 starts with a clear verb+resource statement 'List configured email accounts' and elaborates on the output fields (name, kind, addresses), differentiating it from other tools. The explanation that 'name' is the account label used in other tools adds clarity and distinguishes it from sibling listing tools.

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 that the tool provides account labels for use in other tools (e.g., send_email), but it does not explicitly state when to use this tool versus alternatives like list_calendar_accounts. No when-not-to-use or alternative guidance is given.

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/seandkendall/productivity-mcp'

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