MCP: EmbeddedResource attachments, export_attachment tool, DuckDB type fixes, MIME date fix

[wesm]

Summary

MCP get_attachment improvement:

• Return attachment content as a native MCP EmbeddedResource with BlobResourceContents instead of embedding base64 in a custom JSON text payload. MCP clients (e.g. Claude Desktop) handle embedded resources natively without manual JSON parsing and base64 decoding.
• Use json.Marshal for metadata JSON instead of fmt.Sprintf with %q to ensure valid JSON for all filename byte sequences.
• URL-encode filenames in embedded resource URIs to handle spaces and non-ASCII characters.

New export_attachment MCP tool:

• Claude Desktop can only display image attachments (JPEG, PNG, GIF, WebP) inline — PDFs and documents are retrieved but can't be presented. The new export_attachment tool saves an attachment to the local filesystem (defaults to ~/Downloads) and returns the file path.
• Filename sanitization strips dangerous characters; collision avoidance appends _1, _2, etc.
• Atomic file creation with O_CREATE|O_EXCL to prevent TOCTOU races.
• Handles EISDIR (directory occupying target name) by falling through to suffixed names.

DuckDB type mismatch fixes:

• Cast all Parquet table columns to their expected types at the CTE level using DuckDB's SELECT * REPLACE (CAST(...)) syntax. This fixes two classes of type mismatch errors caused by Parquet schema inference from SQLite storing numeric columns as VARCHAR:
  1. Cannot mix values of VARCHAR and INTEGER_LITERAL in COALESCE operator — in SearchFast, ListMessages, Aggregate, and GetTotalStats queries.
  2. Cannot compare values of type BIGINT and VARCHAR in IN/ANY/ALL clause — in ListMessages when sender/recipient filters trigger the filtered_msgs CTE with JOIN conditions across differently-typed columns.
• Use TRY_CAST for has_attachments and attachment size columns for resilient type conversion.

MIME date parsing fix:

• Fix platform-dependent named timezone parsing. Go's time.Parse resolves named timezone abbreviations (EST, MST, PST) against the local system timezone, producing different results on different machines.
• Use time.ParseInLocation(..., time.UTC) which forces named timezones to offset 0, making parsing deterministic. This builds on the hasNumericOffset/toUTC helpers from PR Bug mime date parse #50 which correctly separate numeric-offset and named-timezone conversion logic.

Housekeeping:

• Track the post-commit hook in .githooks/ so it works across worktrees.
• Use $HOME instead of hardcoded path for portability.

Test plan

• MCP attachment tests pass (12 cases including empty MIME, unicode filenames, path traversal, oversized)
• Export attachment tests pass (custom destination, file collision, directory collision, default ~/Downloads, edge filenames, error cases)
• DuckDB regression test: VARCHAR integer columns with ListMessages (unfiltered + sender/recipient filters), SearchFast, SearchFastCount, Aggregate, GetTotalStats
• MIME date parsing tests pass on all system timezones (contributor's TestHasNumericOffset, TestToUTC, and expanded TestParseDate cases all passing)
• Full test suite passes (go test ./...)
• Manual: verify export_attachment in Claude Desktop saves PDF to ~/Downloads

🤖 Generated with Claude Code

[hughdbrown]

@wesm So you merged my fixes for date parsing in #50, but you are returning to it in b23936c. if the test plan item is:

MIME date parsing tests pass on all system timezones

then were there test cases that #50 failed on?

[hughdbrown]

Hmmm, I see. Golang has time.ParseInLocation already that is a solution to this problem and the code was just calling the wrong API function.

google

Key Differences from time.Parse

The main distinction from the standard time.Parse is how a lack of explicit timezone information in the input string is handled.

• time.Parse interprets a time string without timezone information as UTC.
• time.ParseInLocation interprets a time string without timezone information as being in the specific loc provided as the third argument.

When the input string does contain timezone information (like a numeric offset or abbreviation), ParseInLocation uses the provided loc to resolve and match that information, whereas time.Parse tries to match it against the system's Local location.

[wesm]

I'm still actively working on this branch — there was a test failing after the previous PR was merged so bear with me

[wesm]

I'm reverting b23936c and will get this cleaned up