get_email type coercion + search mailbox scope + scheduled mode failures

[mrthedoozer]

Bug Report — Three related issues in scheduled/automated mode

Environment

• Version: v0.1.8
• Running via: Claude Cowork scheduled tasks (automated, unattended)

---

Bug 1: get_email — message_id type coercion in scheduled mode

When called from a scheduled task, message_id is passed as a string instead
of an integer. The tool rejects it with a type error, making it impossible to
read email bodies in any automated context.

Workaround: None reliable. Triage falls back to metadata only
(subject/sender/date).

Expected: Tool should accept both integer and string message_id, or coerce
internally.

---

Bug 2: search — returns zero results when scoped to a mailbox

Calling search with an account or mailbox parameter returns zero results
even when matching emails exist. Global (unscoped) search also returns zero
results in scheduled mode.

Workaround: Omit mailbox scope. Results are unreliable either way in
automated mode.

---

Bug 3: get_emails — limit parameter type coercion in scheduled mode

Same issue as Bug 1 — limit is passed as a string, causing a type error.
Workaround is to omit the limit parameter entirely.

---

Impact

All three bugs make the MCP effectively read-only for email bodies in scheduled/
automated mode. The FTS5 index (the main value-add of this fork) is unreachable
in automation contexts.

Happy to provide more detail or test fixes.

[imdinu]

Thanks for the detailed report! I've investigated all three bugs:

Bug 1 & 3: Type coercion (message_id / limit as string)

I was unable to reproduce this. FastMCP uses Pydantic's TypeAdapter.validate_python() in non-strict mode, which automatically coerces "12345" → 12345. I tested with the exact parameter shapes you'd see in automated mode and strings are accepted correctly.

Could you share the exact error message you're seeing? It would help determine if this is a FastMCP version issue or something specific to the Claude Cowork transport layer.

Bug 2: Search returns zero results when scoped to mailbox ✅ FIXED

Confirmed and fixed. The mailbox filter was case-sensitive — search(mailbox="INBOX") returned zero results when the index stored the mailbox as Inbox (common with Exchange/Outlook accounts). IMAP accounts store INBOX, Exchange stores Inbox.

Fix: switched to LOWER() comparisons in the SQL filter. Now inbox, INBOX, and Inbox all match.

Available on the v0.2.0 branch (PR #69), will ship with the next release.

Summary

Bug	Status	Notes
Bug 1: message_id type coercion	Cannot reproduce	Need error message details
Bug 2: search mailbox scope	Fixed in v0.2.0	Case-insensitive LOWER() filter
Bug 3: limit type coercion	Cannot reproduce	Same as Bug 1

[mrthedoozer]

Thanks for the quick investigation — and great news on Bug 2, that's the one that was causing the most friction. Looking forward to v0.2.0.
On Bugs 1 & 3: I don't have the exact error strings to hand — these were documented from earlier runs of an automated scheduled task (via Claude Cowork's scheduled task mode), and the workarounds (omitting limit, using global search instead of get_email) were put in place before I captured the raw output. We haven't hit the errors since because we've been routing around them.
The scheduled task context may be relevant — it runs without a user present and goes through Claude Cowork's transport layer rather than an interactive session. It's possible the type coercion issue is specific to that path rather than FastMCP itself.
I'll remove the workarounds in the next scheduled run and capture the exact error output if it recurs. Will report back here.

[imdinu]

Bug 2 (mailbox case) fixed in v0.2.0. Bugs 1 & 3 not reproducible — user confirmed.