Live lookups at draft time (MCP): InboxMinder docs

Your docs tell drafts what your product does. Your billing, CRM or order system knows what this customer's account looks like. Connect any Model Context Protocol server and the draft model can look that up while writing, with the sender's address as the join key.

Lookups are ephemeral: results live in one draft's prompt and are never indexed or stored. The feature is config-file only, under [mcp].

Configure

[mcp.servers.billing]
transport = "stdio"
command = "npx"
args = ["-y", "@acme/billing-mcp"]
envSecrets = { BILLING_API_KEY = "mcp-billing" }
readOnlyAnnotationsOnly = true
allowTools = ["get_customer", "list_invoices"]

[mcp.servers.crm]
transport = "http"
url = "https://mcp.example.com"
headerSecrets = { Authorization = "mcp-crm" }
allowTools = ["lookup_contact"]

envSecrets and headerSecrets map an environment variable or header name to a Keychain entry name; store each with

inboxminder set-key mcp-billing

Secret values never touch the TOML file. Restart the agent after changes.

Read-only, three ways

Restricted credentials. Give the server a read-only key where the system offers one.
Tool policy. With readOnlyAnnotationsOnly = true (default), only tools the server annotates as read-only are offered to the model, and if allowTools is set, only those names among them. A server whose tools carry no annotations exposes nothing until you write an allowlist. Safe by default.
Prompt fencing. Tool results enter the prompt as data, like email content, so a record cannot instruct the model.

Every call has a 30-second timeout and fails soft: a slow or broken server costs the draft its lookup, never the draft.

Privacy

Tool arguments and results are customer data, handled like email bodies: the log records tool names, durations and outcomes, never payloads. The connected system's own terms govern what it does with the request.