Inspiration
Imagine searching for a remote job. You look up React Native roles, open a few listings, and find three worth considering. Then come the simple questions: Which pays the most? Which am I actually eligible for from India? Which needs the least experience? How do their tech stacks differ? Which company has better benefits? What was that seventh listing again, and how does it compare to the first? None of this is hard. It's just tedious. Multiple tabs, scattered details, manual comparison, and it only gets worse as the number of listings grows into the hundreds or thousands.
The Problem
There's a mismatch between how much useful information exists and how much a person can realistically explore. Comparing job listings by hand, salary, eligibility, experience, tech stack, benefits, is annoying even with three jobs and basically impossible at scale.
Why AI Agents Alone Don't Fix It
Agents seem like the obvious answer. You should be able to just say "compare the top three" or "which pays more but needs less experience?" and get an answer. But most websites are built for humans, not agents. That means an agent has to reverse-engineer meaning from a visual interface, cards, buttons, clicks, rather than working with clean, structured data.
The Fix: WebMCP
Instead of forcing agents to scrape and interpret the interface, WebMCP lets a website expose its data and actions directly as structured tools: search_jobs, get_job_details, compare_jobs, save_job, unsave_job, get_saved_jobs, and get_filter_options. The agent can just ask the site directly. No guessing required.
What We Built: TrueRemoteJobs
TrueRemoteJobs is a job board prototype with 200 fictional listings. It works normally for humans browsing the site, and it exposes WebMCP tools for agents working alongside them. A typical flow looks like this: "Find React Native jobs open to India, paying $60K+" returns nine results. Then: "show me the first," "compare the first and seventh," "save the first and third."
Interfaces Can't Anticipate Every Question You simply can't build a button for every possible query, like comparing jobs one, seven, and twelve on compensation, location, React Native experience, and benefits alone. With structured data, the agent can combine and filter information however the user actually wants, without anyone needing to pre-design every possible screen.
A Real Bug That Proved the Point
During testing, the agent misidentified "the first result" because it was inferring meaning from whatever happened to be on screen rather than from real structure. The fix was straightforward: every result now carries a stable jobId and an explicit resultNumber, so references like "the seventh one" are unambiguous. The lesson stuck with us: giving an agent access to a webpage is not the same as giving it access to the actual information.
Humans and Agents Coexist
This isn't about replacing the website. It's the same underlying data and the same actions, just two ways of reaching them. Browse visually when you want to. Delegate deep comparison and research to an agent when you don't. And the two stay in sync, if the agent saves a job, it's saved in the real app too.
Takeaway
Websites already hold rich information, and agents already have the reasoning ability to make sense of it. WebMCP is the structured bridge between the two, letting anyone, human or agent, dig as deep into a site's data as they want, rather than only as deep as the UI happened to be designed for.
Built With
- ai
- css
- html
- javascript
- localstorage
- react
- tailwind
- typescript
- vercel
- vite
- vitest
- webmcp
Log in or sign up for Devpost to join the conversation.