AI coding assistants have fundamentally changed the way we write software. Today it's perfectly normal to ask ChatGPT, Claude, Cursor, or Copilot to explain an API, generate a React component, review a pull request, or help debug a problem. For many developers, these tools have become part of the daily workflow.
Yet there's one area where they still struggle more than we'd like to admit: understanding the current state of the web platform.
Mozilla recently demonstrated this problem in a surprisingly direct way. While evaluating Claude Code on recently released Firefox features, the team discovered that the model confidently claimed Firefox didn't support the Web Serial API and that Mozilla had no plans to implement it. The answer sounded plausible, detailed, and authoritative.
There was just one issue.
Firefox had already shipped support for the API.
That experiment became one of the motivations behind Mozilla's new MDN MCP Server, a tool designed to give AI assistants direct access to MDN documentation and browser compatibility data. More importantly, Mozilla didn't just launch the service—they tested whether it actually improves the quality of AI-generated answers.
The results are worth paying attention to.
The Real Problem Isn't Hallucination
When discussions about AI reliability come up, the conversation usually focuses on hallucinations. But browser compatibility is a slightly different problem.
The web platform evolves continuously. Browsers ship new APIs, CSS features, HTML capabilities, and compatibility updates every few weeks. Specifications change, Baseline statuses evolve, and features that were experimental yesterday can become production-ready tomorrow.
Large language models, on the other hand, are trained on snapshots of information. Even highly capable models can only know what was available when they were trained. When they're asked about something that appeared later—or something that wasn't widely represented in their training data—they often have to rely on incomplete information.
The result isn't always a hallucination in the traditional sense. Sometimes it's simply an answer that would have been correct several months ago but is no longer accurate today.
As frontend developers, we've all developed the same habit: ask the AI first, then open MDN to verify the answer.
Mozilla's experiment explored what happens when the AI can consult MDN directly before answering.
Mozilla Decided to Test It
Rather than discussing the problem in theory, the MDN team decided to measure it.
They evaluated Claude Code Opus 4.7 using a set of recently released Firefox 151 features, including support for light-dark() images, the :buffering pseudo-class, the shadowrootslotassignment attribute, and the Web Serial API.
These aren't the kinds of features you'll find in every tutorial or blog post. They're recent additions to the platform, which makes them particularly useful for testing whether an AI model truly understands the current state of browser support or is relying on older information.
In other words, Mozilla deliberately chose questions that would expose the gap between what the model remembered and what was actually true.
The Web Serial API Example
The most striking result involved the Web Serial API.
When asked about browser support, Claude Code stated that Firefox didn't support the API. It went even further, claiming that Mozilla had no plans to support it in the future.
For someone unfamiliar with the feature, the response would have sounded completely reasonable. It contained enough context and confidence to feel trustworthy.
The problem was that Firefox 151 had already shipped Web Serial support.
What makes this example particularly interesting isn't simply that the answer was wrong. Developers expect AI systems to make mistakes occasionally. The real issue is that the answer looked credible. If you weren't already familiar with the feature, there would be little reason to question it.
This is one of the biggest challenges when using AI for frontend development. A response can be coherent, detailed, and technically sophisticated while still being disconnected from reality.
Why It Happens
Imagine asking an AI assistant a simple question:
Does Firefox support the Web Serial API?
Without access to current documentation, the model has to rely on whatever information was available during training. If support was added recently, the model may not know about it. If the feature wasn't widely discussed, it may have only partial information.
Unlike a search engine, the model isn't retrieving facts from a database. It's generating the most likely answer based on patterns it has learned.
That's why these mistakes can be so convincing. The model isn't intentionally inventing information—it is trying to produce a coherent response with incomplete knowledge.
And because language models are optimized for answering questions, they rarely respond with "I don't know."
Enter MCP
To address this problem, Mozilla launched the MDN MCP Server.
MCP, or Model Context Protocol, is an open standard that allows AI models to interact with external tools and data sources. Instead of relying entirely on training data, a model can retrieve information when it needs it.
The difference may sound subtle, but it's significant.
Without MCP, the workflow looks something like this:
Developer → AI Memory → Answer
With MCP, it becomes:
Developer → AI → MDN → Answer
Rather than answering solely from memory, the model can consult documentation, retrieve compatibility information, and verify assumptions before generating a response.
For a domain that changes as quickly as the web platform, that's a major advantage.
What Does the MDN MCP Server Provide?
The MDN MCP Server exposes MDN resources in a format specifically designed for AI systems.
This includes:
Documentation search
MDN documentation content
Browser Compatibility Data (BCD)
Instead of searching the web and parsing HTML pages, AI assistants can access structured information directly from one of the most trusted sources in web development.
The goal isn't to replace documentation. It's to make documentation part of the AI workflow.
Mozilla Ran the Tests Again
After enabling the MDN MCP Server, Mozilla repeated the same evaluation.
This time, Claude Code could retrieve information directly from MDN and Browser Compatibility Data rather than relying entirely on memory.
The improvement was substantial.
Recently released features were identified correctly. Browser compatibility information became significantly more reliable. Unsupported assumptions appeared less frequently, and responses aligned much more closely with the current state of the platform.
In practical terms, the model no longer had to guess. It could verify information before answering.
That distinction may sound small, but it's arguably the most important benefit MCP provides.
It Was Faster Too
One of the most surprising findings had nothing to do with accuracy.
Mozilla reported that responses generated with the MDN MCP Server enabled were roughly twice as fast.
At first glance, that seems counterintuitive. Querying an external service sounds like it should introduce additional overhead.
In practice, the opposite happened.
Without MCP, the assistant often needed to search the web, open multiple pages, parse HTML content, extract relevant information, and then synthesize a response. With MCP, that information was already available through structured tools designed specifically for machine consumption.
The model spent less time searching and more time answering.
The result was faster responses and better information at the same time.
Practical Examples
The value of this becomes clear almost immediately in day-to-day frontend work.
The Web Serial API example is a perfect illustration. Instead of receiving an answer based on potentially outdated knowledge, you can ask questions about browser support and get responses grounded in current MDN data.
Does Firefox support the Web Serial API?
What browsers can I safely target today?
The same becomes even more interesting when working with modern browser APIs in React.
Imagine asking an AI assistant:
Using the latest MDN documentation, create a React hook
for the View Transitions API.
Because the assistant has access to MDN, it can validate compatibility information before generating code and produce something like this:
import { useCallback } from "react";
export function useViewTransition() {
return useCallback((update: () => void) => {
if (!document.startViewTransition) {
update();
return;
}
document.startViewTransition(update);
}, []);
}
The hook itself isn't particularly complex. What's interesting is the context that accompanies it. The assistant can explain which browsers currently support the API, whether the feature has reached Baseline status, what fallback strategy should be implemented, and whether it's safe to use in production today.
That's exactly the kind of information that tends to become outdated quickly when a model relies exclusively on training data.
You can also ask questions such as:
Using MDN compatibility data, explain whether
requestIdleCallback is safe to use in production.
Instead of answering from memory, the assistant can verify its response against current documentation before making a recommendation.
Compatible Clients
Although Mozilla's examples focus on Claude Code, the MDN MCP Server isn't tied to a specific AI vendor.
Any MCP-compatible client can potentially use it, including Claude Code, Claude Desktop, Cursor, VS Code MCP integrations, Zed, Codex CLI, Antigravity CLI, and other MCP-enabled applications.
As support for MCP continues to grow, direct access to authoritative documentation may become a standard feature of developer tooling rather than a niche capability.
For example, adding the MDN MCP Server to Claude Code is as simple as running:
claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/
The Bigger Story
The most important takeaway from Mozilla's experiment isn't that they launched another developer tool.
It's that they exposed a fundamental limitation of modern AI systems.
The Web Serial API example demonstrates something every developer should keep in mind: confidence is not the same thing as correctness. An answer can be detailed, coherent, and technically sophisticated while still being wrong.
For years, conversations about AI have focused on building larger models with more knowledge. Mozilla's experiment suggests a different direction. The future may not belong to models that memorize everything. It may belong to models that know how to retrieve trustworthy information when their knowledge is incomplete.
That's a subtle distinction, but it has enormous implications for software development.
Final Thoughts
For a long time, the safest workflow looked something like this: ask the AI, open MDN, and verify everything manually.
Mozilla's MCP Server doesn't eliminate that responsibility, and it certainly doesn't make AI infallible. Developers should still think critically about the code and recommendations they receive.
What Mozilla's results suggest, however, is that giving AI systems direct access to authoritative sources can dramatically improve both accuracy and speed. The Web Serial API test showed just how easily a model can be confidently wrong when it's forced to rely solely on memory.
MCP won't solve every problem. But if the future of AI-assisted development is going to work, it will probably look less like AI replacing documentation and more like AI reading the documentation alongside us.
Top comments (0)