ApplyFlow

• 

  Tracker

• 

  Profile & Docs

• 

  WebMcp

• 

  Job Board

ApplyFlow: a job-search workspace for people + agents

I built ApplyFlow for The WebMCP Challenge because I kept hitting the same wall: applying to jobs is half product, half chore, and no tool today lets an AI assistant genuinely help without fighting the UI. Chat agents can write a cover letter in a chat box, but they can't see your board, work your pipeline, or edit the same document you're editing. Raw MCP servers operate on data, not on the page you're looking at. WebMCP is the missing bridge — agents finally run inside the app you use.

The idea. ApplyFlow is one workspace where a person and an AI agent work the same live page in the same session. The human browses roles, filters, and writes like always. The agent calls the exact same app: it searches and scores jobs against a résumé, drafts tailored cover letters, advances applications through a pipeline, and pins notes. The critical rule: every state-changing action the agent takes is staged as a pending action and must be approved by the human in a shared activity feed. The agent does the tedious work; the human keeps ownership. That's the collaboration model WebMCP is designed for, and it shows up in every one of my tool choices.

How I built it. Next.js 16 + React 19 + TypeScript + Tailwind, no backend — the whole product is a static SPA whose state lives in localStorage, so it deploys anywhere and works fully offline. WebMCP was brand new, so the WebMCP layer was built from the Chrome/W3C specs and iterated on:

Imperative tools — 9 registered via document.modelContext.registerTool: list_jobs, get_job_details, score_cv_match, get_application_overview (read-only, readOnlyHint: true); create_application, update_application_status, draft_cover_letter, tailor_cv_highlights, add_note (write tools that stage a pending action the human approves or dismisses). Declarative API — the application form uses toolname, tooldescription, and toolparamdescription attributes so the agent can pre-fill it, and deliberately omits toolautosubmit so only the human submits. Security hints the WebMCP spec cares about: readOnlyHint and untrustedContentHint on the tools that deserve them. Shared documents — the cover letter and CV-highlights playground live in one editor both parties mutate, so a draft from the agent is immediately visible to the person. Challenges. WebMCP is simultaneously public and moving fast. The spec changed between the docs I first read and the API surface, which taught me to build a thin adapter and keep tool behavior decoupled from registration. Speech-to-text and event APIs like toolactivated aren't in the standard WindowEventMap, so I had to extend types carefully. My React+TS setup needed module augmentation to expose the declarative attributes (toolname, toolparamdescription, …) as typed JSX props. And there was the usual 10-day crunch: decide the demo, cut scope, ship a build that passes, then make the human-in-the-loop experience the star rather than an afterthought.

What I learned. The biggest lesson is that the human-agent boundary is a product decision, not an API detail. Every Write tool in ApplyFlow returns "staged for approval" — the agent never mutates state unilaterally — and that one design constraint is what makes the experience feel safe and fun instead of scary. I also learned that a great WebMCP app doesn't need to be more than a static page; the agent is a full environment away. The judge's ChatGPT browser is the demo machine.

I hope ApplyFlow shows what "agent-native" means in practice: software a person can use alone, an agent can use alone, and — for the first time — both can use together.

Built With

• chrome
• context
• css
• css3
• google
• html5
• javascript
• mcp
• model
• next.js
• node.js
• openai
• protocol
• react
• tailwind
• typescript
• vercel
• webmcp