Key Takeaways
- AI agents can already read your job board. They work out what the page means from its code and layout, the same way they read any website, which is slow and easy to get wrong.
- Aquent built two ways for agents to skip that guesswork. A hosted MCP server queries our live job database, and WebMCP markup is built into the job board itself.
- Neither one can apply for a job. There is no write capability in the stack, because our application funnel needs a human answering the questions.
- We added WebMCP before the standard was finished and before any agent asked for it. When we checked, no other staffing firm had done it.
- The agents are already here. Close to half the visits to the Aquent blog now come from AI chatbots, and the MCP server announcement drew thousands of AI visits in its first week. What those agents do after they land is harder to count.
About six weeks ago, we turned on WebMCP support across the Aquent job board. Nobody requested it. No client asked. No candidate complained. No AI agent showed up at our door demanding structured tools.
I built it because I was reading the tea leaves.
WebMCP is an emerging web standard, pushed largely by Google, that lets a web application tell AI agents what it can do in a format they read directly. Today it sits behind a feature flag in Chrome (chrome://flags/#enable-webmcp-testing). The standard is not finished. No other browser supports it yet without a plugin. At the time, we had no way of knowing whether a single agent would ever use it.
I would do it again tomorrow.
If you are trying to hire AI-fluent talent, that decision probably tells you more about whether we can help you than any case study I could write.
Agents can already use your job board—they just have to guess
You will hear a version of this argument: If your job board doesn’t speak MCP, AI agents cannot see your roles at all. That overstates it.
Agents can use a normal web application. They read the page code, walk the DOM and accessibility tree, take screenshots, and work out meaning from class names, ARIA labels, and layout. Given enough attempts, an agent will find your search box.
The cost is the problem.
- The agent has to parse the entire page before it can act on any of it, which takes time.
- A CSS change that looks identical to a person can break the agent's understanding of the page.
- Every element the agent reads, related to the application or not, eats space in the context window it could have spent on the actual task.
- An agent guessing its way through untrusted page content is the exact situation prompt injection attacks are built to exploit.
So agents do find your jobs. They find them slowly, they get them wrong often enough to matter, and the cost climbs high enough that many agents give up and go back to the big aggregators.
Layer one: An MCP server for the job database
We publish an XML feed of every open Aquent role, refreshed every fifteen minutes. We link it to an llms.txt file, and an agent could read the whole thing in theory. In practice, the file is far too large. Most agents run out of memory holding it, and that can severely truncate results.
An MCP server flips that around. Instead of handing the agent a giant document and hoping, the agent asks a narrow question and gets a narrow answer.
“Art Director roles in Houston” becomes a query against our live database. Our server exposes a small set of tools:
- jobs_search_postings searches active roles by keyword, market, location, industry, or practice.
- jobs_get_details pulls the full record for one posting.
- jobs_list_markets, jobs_list_locations, jobs_list_industries, and jobs_list_practices return the valid filter values, so the agent isn't guessing at our vocabulary.
No authentication. Every role is vetted by a human before it gets there. In real time against the live database.
When an agent connects to an MCP server, the first thing that happens is a handshake. The agent asks what the server can do, and the server hands back that list of tools. From then on, when a user asks about jobs, the agent knows there is an authoritative source sitting right there, and it will usually reach for its own tools before going out to a search engine.
One detail worth understanding: a human has to install an MCP server. You go into Claude, ChatGPT, or Cursor and add the connector yourself. That is a safety design. You do not want your agent wandering the internet, finding a server that promises it something interesting, and handing over access to your email and your bank accounts on your behalf.
The speed and security of a traditional MCP server are still a valuable investment to produce for your applications. The server only covers one way agents interact with data on the web, however. Integration and usage of MCP servers also tends to sit outside the more curated experiences that lay users deal with day to day. That’s where WebMCP comes in.
Layer two: WebMCP inside the job board itself
The MCP server only helps agents that someone told to install it. WebMCP helps any agent that lands on our job board, whether or not they knew we existed five seconds earlier.
Our job board is a React application. The same application runs on aquent.com and on skill.com with different styling, so anything we build into it works in both places at once. WebMCP is built into it natively using the Declarative API, which simply adds attributes to the existing HTML, and it took a fraction of the time to implement compared to building out a traditional MCP server. When a WebMCP-aware agent loads the page, the page tells it: here are the tools, here is what each one takes, here is what it gives back. The agent gets a contract instead of a puzzle. It has a map instead of trying to blaze a trail through the brush.
I mentioned that a dedicated MCP server is still faster, and that’s true. Where WebMCP shows its value is by helping agents avoid the laborious task of parsing raw markup, speeding up the intermediate experience while simplifying the interaction. Sarah Drasner built a side-by-side demo that runs the same agent task both ways if you want to watch it happen.
Behind the job board sits Elastic, which handles the indexing, scoring, and filtering. WebMCP is the layer that lets an agent talk to it without translating through pixels first. We are looking at doing the same thing with our contact form and other features, so an agent could send an inquiry to Aquent for a user. That is about ten minutes of work to future-proof our experiences and take advantage of nearly free extra value.
This is just ARIA again
If you have been building for the web for a while, you have seen this movie.
When ARIA arrived, the pitch was simple. You are already in the templates. You are already writing the markup. Add a few attributes and a screen reader can move through your site intelligently instead of guessing at it. The screen reader could “know” things about different parts of the page. There was a learning curve, then it became normal, and now it is part of building a competent web application.
WebMCP has the same shape. A screen reader scans a page, pulls out the information, and guides a user through it. An AI agent does the same job. We are already building the app, so we might as well make it work across interfaces.
Once you have learned it, the enhancement is free. The day every agent can land on a page and immediately understand how to use it, that is high-intent traffic arriving at your door for nothing. “Hey Gemini, check Aquent for new, remote Front-End Designer jobs.” No extra installation—just understanding and results.
What we deliberately left out
Neither the MCP server nor our WebMCP markup can apply for a job. There is no write capability anywhere in the stack.
That was a choice. Our application funnel asks candidates specific profiling questions, and those answers matter to the Recruiters and hiring managers reading them. If an agent starts generating answers and filling those in, we have additional tools that take notice, and the candidate can be ruled out. We want AI to be able to do the tasks AI is good at, and transfer the responsibility over to the human when it really matters.
I will go further. Automated job applications are not a real use case. Most application platforms require file uploads, account creation, and specific human answers. Building an agent to shotgun applications at all of them is more work than it is worth, and it does not produce interviews. What an agent does well in a job search is find roles, filter them, and score them against a resume. That is what we built for.
The agents are already reading, but we cannot yet see them press the buttons
Our analytics can tell us who loads pages on aquent.com, and that picture has changed fast. Close to half the traffic to the Aquent blog now comes from AI chatbots instead of people typing into a search box. When we announced the MCP server, that page drew thousands of AI visits inside the first week, roughly a hundred times what a launch like that normally pulls. Across the site, AI traffic is now one of the largest sources of visits we have.
What analytics cannot tell us is what happens next. Calls to the MCP endpoint and tool invocations through WebMCP sit outside Google Analytics and rely on filtering raw log data to other platforms—messy and time-consuming—and plenty of agents do not send a user agent string we could attribute anyway. So I can say with confidence that agents are reading our pages in volume. I cannot yet say how many of them are calling the tools we put there for them.
That gap is about measurement. The audience arrived before our ability to count it did. In a short amount of time, that will be a very closable gap, lead by our future-first approach to the tools.
What this means if you are hiring AI talent
Two things.
The first is reach. Very few candidates build custom agents to run their job search. The ones who do tend to be the people you want. In our The Builder's Mindset research and report, that instinct, seeing something that does not exist yet and building it anyway, is the trait that separates extraordinary AI talent from competent AI users. An Art Director who wired up an agent to watch job boards is telling you something real about how they work. Agent-ready infrastructure keeps you visible to that person.
The second matters more. When you hire a staffing partner to find AI talent, you are trusting them to evaluate skills you may not be able to assess yourself. That is hard to verify from the outside. One of the few honest signals available to you is what the partner has built for itself.
We are a marketing, design, and creative company. Every single thing a potential client touches should be the pinnacle of that craft. If our own tools are behind, why would you trust our read on somebody else's? We are always trying and testing new things, learning valuable information every step of the way that informs our future roadmaps and goals. We experiment. We take risks. We pursue the opportunities to excel fearlessly.
We added WebMCP before the standard was ratified, before any agent asked for it, on a bet about where the web is going. When we went looking, no other staffing firm had done it. If you need people who can build for AI, that is the kind of partner you want in the room. You can’t explore the possibilities of the frontier while seated behind work that is always just “safe.”
Building for a reader you cannot see
The web is being rebuilt for a second kind of reader. It does not scroll, it does not look at your hero image, and it does not care how the page is styled. It wants to know what your site can do and how to ask. Ten minutes of markup is the difference between being legible to that reader and being a wall of code it has to decode.
The same logic applies to the people you hire. The ones worth hiring right now are building for a world that has not fully arrived. We would rather be one of them.
If you are trying to hire that kind of talent, we would love to help.
About the author
I am a career web developer who's been building sites since the dark ages of the 1990s, but eventually chose to major in theatre in college. What I did know then was that having some hard skills to fall back on would be really important, since I like doing things like… eating. I've worked on small sites, big sites; I was Director of Web Marketing for Pittsburg State University, and now I work with my team at Aquent building sites that help other people find jobs, and companies find employees. I place a hard emphasis on human-centered design, accessibility, and user experience. That's all a pretty cool, I think. I've written a book, spoken at events from the US to Europe, and generally like helping out other web folks be better web folks. Sometimes I succeed, but I try to have fun the whole time.
Latest.
Systems thinking is the AI skill nobody is talking about.
Career Advice, Leadership & Management, Engineering & Technology, Innovation & Emerging Tech
Smarter workflows start with automation before adding AI.
Leadership & Management, Engineering & Technology, Innovation & Emerging Tech
Who to hire for Agentic AI orchestration.
Career Advice, Consulting & Operations
