Skip to content

docs: clarify search_emails scope, point to advanced_search#58

Closed
AusDavo wants to merge 4 commits into
MadLlama25:mainfrom
AusDavo:fix/search-emails-description
Closed

docs: clarify search_emails scope, point to advanced_search#58
AusDavo wants to merge 4 commits into
MadLlama25:mainfrom
AusDavo:fix/search-emails-description

Conversation

@AusDavo

@AusDavo AusDavo commented Apr 16, 2026

Copy link
Copy Markdown

Summary

  • Updated search_emails tool description from the vague "Search emails by subject or content" to explicitly state it only does full-text body/subject search, and directs users to advanced_search for field-specific filtering (sender, recipient, date, etc.)
  • Updated the query parameter description from "Search query string" to "Text to search for in email body and subject lines"

Problem

AI clients (Claude, etc.) consistently misuse search_emails by passing structured queries like from:user@example.com or sender names, expecting it to filter by sender. The tool silently returns zero results because JMAP's text filter only matches body/subject content. The client then has to fall back to get_recent_emails and scan manually.

The advanced_search tool already supports from, to, subject, and date parameters — but nothing in search_emails tells the client it exists or that search_emails can't do field-specific filtering.

Fix

Two description changes in the tool definition (no logic changes):

  1. Tool description: "Full-text search of email body and subject. Does not filter by sender, recipient, or date — use advanced_search for field-specific filtering."
  2. Query param description: "Text to search for in email body and subject lines"

Test plan

  • npm run build passes cleanly
  • Verify AI clients select advanced_search instead of search_emails when filtering by sender/recipient

🤖 Generated with Claude Code

AusDavo and others added 4 commits March 16, 2026 11:00
Add StreamableHTTPServerTransport as an alternative to stdio, enabling
deployment as a standalone HTTP service. Includes bearer token auth,
health check endpoint, Dockerfile with multi-stage build, and
docker-compose config for Caddy integration.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The MCP SDK does not allow connecting multiple transports to a single
Server instance. Each new HTTP session was calling server.connect() on
the shared instance, causing "Already connected to a transport" crashes
after the first connection.

Wrap server creation and handler registration in a createMcpServer()
factory so each HTTP session gets its own Server+transport pair.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The search_emails tool description said "Search emails by subject or
content" which implied it could filter by sender or other fields. In
practice it only passes the query to JMAP's `text` filter (body and
subject full-text search). AI clients consistently try `from:` syntax
or sender names, get zero results, and fall back to get_recent_emails.

Updated the tool and parameter descriptions to make the scope explicit
and direct users to advanced_search for field-specific filtering.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@MadLlama25

Copy link
Copy Markdown
Owner

Thanks @AusDavo — the description clarification is a genuinely good catch and it's now on main (adapted with attribution). Closing this PR rather than merging because it had grown beyond the docs scope (Dockerfile, docker-compose, an HTTP transport rewrite) and had conflicts with main. If you'd like to propose the Docker/HTTP-transport work, a fresh focused PR for each would be very welcome.

@MadLlama25 MadLlama25 closed this Jul 6, 2026
MadLlama25 added a commit that referenced this pull request Jul 6, 2026
Adapted from PR #58 by @AusDavo — the description text is his; the PR
itself had drifted into Docker/HTTP-transport territory and conflicts,
so the docs fix is integrated standalone.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants