AgentInbox

Inspiration

Today, giving an AI agent access to your inbox usually means one of two things: handing over a personal API key to a third-party service, or trusting a closed chatbot with full access to your private data. Both approaches break the trust boundary that should stay with the user. WebMCP offered a different model — register tools directly on the page, inside the user's own authenticated session, and let any compliant agent discover and call them. AgentInbox is our exploration of what that looks like for one of the most personal apps people use every day: email.

What it does

AgentInbox is WebMCP powered Gmail manager. You can sign in with Google , view your inbox , read messages, mark them as read and reply. Built as normal website with FastAPI for backend, PostgreSQL for DB, and html/css/js for frontend

What makes it different is that every core action is also registered as a WebMCP tool with document.modelContext.registerTool():

list_emails — retrieve the user's messages, optionally filtered to unread only get_message_detail — fetch the full content of one message (subject, sender, date, body, read status) mark_as_read — mark a message as read reply_to_email — send a reply within the correct Gmail thread (using proper In-Reply-To/References headers)

Any WebMCP-compatible AI agent running in the user's browser can discover these tools with getTools() and call them with executeTool() — no separate integration, no API key handed to a third party, and no action taken outside the user's own real, authenticated Gmail session.

How we built it Backend: FastAPI (Python), with a layered architecture — routers → services → repositories → models Database: PostgreSQL via SQLAlchemy 2.0 Auth: Google OAuth2, JWT stored in an HttpOnly cookie Email: Gmail API (list, get, mark-read, reply — with correct thread headers) Frontend: plain HTML/CSS/JavaScript, no framework — served directly by FastAPI from the same origin as the API WebMCP: four tools registered with the imperative API (document.modelContext.registerTool()), verified end-to-end via getTools()/executeTool() — including real Gmail reads and a real reply sent inside the correct thread Deployment: live on Render (single service, backend + frontend together) Challenges we ran into WebMCP is a very new, fast-moving spec — the tooling ecosystem around it (browser extensions, inspectors) is still immature, and some third-party inspector extensions didn't reliably detect our imperative-API tools. We worked around this by verifying everything directly through the browser console (getTools() / executeTool()), which is exactly what an agent does internally. Google's sensitive Gmail scopes mean full app verification wasn't realistic within the hackathon timeline, so the app runs with a whitelisted Test Users list and demo credentials for judging (see Testing instructions). Accomplishments that we're proud of

A complete, working product — not just a proof of concept — with real OAuth, a real database, and four WebMCP tools that actually call a real Gmail account and produce real results, deployed live.

What we learned

How the WebMCP imperative API actually behaves end-to-end in a real Chrome build: tool registration, discovery via getTools(), and execution via executeTool(), including the JSON string in/out data flow.

What's next for AgentInbox Improving WebMCP tools. Making UI more better and user-friendy. Adding real AI agent.