EmailBooster

Inspiration

Every working day starts the same way. Open the inbox. Scroll to find the thread you need. Re-read it to remember where it stood. Think about how to answer. Type it out. Re-read it. Send. Repeat X times.

None of those steps is hard. Together they eat an hour or two every single day, and most of it isn't thinking, it's finding and typing. EmailBooster exists to give that hour back. You say one sentence, "reply to Milan and tell him to look for cheaper alternatives", and the finding, the context, and the typing are done for you, in your own words, in your own compose window, waiting for your approval.

What it does

EmailBooster is a mail client with no AI inside. Instead, it teaches your browser agent, via WebMCP, to do the repetitive part of email for you:

• Finding the thread: search_emails and resolve_contact turn "Milan's email about S3" into the right conversation in one call. No scrolling, no search box, no guessing the subject line.
• Reloading the context: read_thread gives the agent the whole conversation so you don't have to re-read it to remember what was said.
• Writing the reply in your voice: get_writing_style hands the agent a voice profile built from your sent mail. The draft sounds like you, so you edit two words instead of rewriting three paragraphs.
• Keeping you in control: the draft lands in the compose window, visible and editable. send_email requires your explicit approval in the UI. Every tool call is logged live in the sidebar.

The daily flow becomes: read the inbox, say what you want to reply, glance at the draft, approve. Minutes instead of an hour.

Why WebMCP is a strong fit

Email is the most repeated task of the working day and the worst one for DOM-scraping agents: search, threading and tone all live behind the UI. WebMCP lets the mail client expose exactly the three things an agent needs to save you time, structured search, full thread context, and your writing style, as tools. No API key, no LLM inside the app, no copy-pasting your private mail into a chatbot. Mail never leaves the tab, and the agent you already have does the work.

What people and agents can now do together

Before, delegating email meant either doing it all yourself or handing your inbox to a bot that writes like a press release. Now the split is clean and the same every day: the human decides what to say and to whom in one sentence; the agent finds the thread, recovers the context, and writes it in the human's voice; the human edits and approves. Multiply that by every reply you send in a day, and it's the difference between an inbox that owns your morning and one you clear before coffee.

How I built it

• Nine tools registered with document.modelContext.registerTool() (fallback to navigator.modelContext), each with a JSON inputSchema, a description written for an agent, and an execute handler.
• Read-only tools (search_emails, read_thread, get_open_email, resolve_contact, get_writing_style) carry annotations: { readOnlyHint: true }.
• Write tools (draft_reply, archive_email) update app state and the DOM in one place, so whatever the agent does, you see it happen.
• Two tools are dynamic: update_draft and send_email are registered when the compose window opens and removed with unregisterTool() when it closes. The agent cannot send mail when there is nothing on screen to send.
• Static HTML/CSS/JavaScript, no build step, no server. The mailbox is seed data in localStorage. Hosted on GitHub Pages.
  • Static HTML/CSS/JavaScript, no build step, no server. The mailbox is seed data in localStorage. Hosted on GitHub Pages.

Challenges

• The API moved under my feet. The spec migrated from navigator.modelContext to document.modelContext during the build; the app detects whichever exists.
• Tool descriptions are the product. The agent only saves you time if it picks the right tool first time. Most of the iteration went into the wording of descriptions, not into code.
• Speed without losing control. Dynamic registration of the write tools plus an on-screen approval step for send_email turned out simpler and safer than any permission system I sketched, and it adds zero friction to the daily flow.

What I learned

The biggest time saving doesn't come from the agent doing things, it comes from the agent knowing things: where the thread is, what was said, how you write. A get_writing_style tool is worth more than ten CRUD tools, because it's what turns "a draft" into "my draft".

What's next

Connecting a real mailbox through a standard IMAP bridge, per-recipient tone (you don't write to your boss like you write to your friend), and letting the agent flag threads that have gone quiet so follow-ups don't slip through the cracks.

Built With

• css3
• github
• html5
• javascript
• localstorage
• webmcp