The Lumar Agentic Readiness Scanner
What we score, what we refuse to score, and why.
26 technologies scored, 6 watched. Everything you are about to move through is that registry: where each one sits, how far it has actually been taken up, and whether we check it at all.
Where we are
New protocols appear quickly. Some are grounded in established standards and already used across the web. Some are gaining real adoption. Others remain promising experiments. Nobody yet knows which ones will become lasting infrastructure.
That uncertainty should invite curiosity, not anxiety.
This project exists to help people understand what is changing, decide what matters for their website, and implement useful technologies correctly. It is not here to make every website owner feel deficient because they have not published every new file or adopted every unfinished proposal.
First principle
We keep adoption and correctness separate.
If your website does not publish an emerging protocol, that is usually an observation, not a defect. The protocol may not apply to your site. Its adoption may still be negligible. Real agents may not use it. Waiting may be the sensible decision.
If you do publish something, we check whether it works.
A discovery document should be discoverable. An advertised endpoint should speak the protocol it declares. Required fields should be present. Authentication instructions should lead somewhere real. We report defects when there is evidence of a defect, not simply because another technology could be added.
Nothing is reported. The protocol may not apply to your site, adoption may be negligible, and waiting may be the sensible decision. We do not score an absence.
A card advertises an endpoint that answers nothing. A discovery document is not discoverable. A required field is missing. That is evidence of a defect, and we report it.
Second principle
We track the evidence behind each technology:
A new proposal does not become mandatory because it has a website, a GitHub repository or an enthusiastic announcement.
We will update our view as the evidence changes. Technologies can rise, mature, stall or disappear. The aim is not to predict the winner. It is to describe the present honestly.
Third principle
A low score can manufacture urgency without explaining whether the missing items matter. A high score can hide real defects by allowing unrelated features to compensate for broken ones.
We avoid that model.
The scanner shows what your site has adopted and whether each adopted technology is correct. Experimental omissions do not become failures. One valid feature does not cancel out a broken one. When something cannot be fully tested, we say that it was only partly assessed.
Readiness is not the number of experimental files on your domain.
Fourth principle
Every check should answer four questions:
Standards requirements are identified as standards requirements. Lumar recommendations are identified as Lumar recommendations. We do not borrow a specification's authority for our own preferences.
The documentation includes the reasoning, adoption evidence, correct examples, broken examples and exact checks behind every result.
Our own judgments need testing too. Comparing results on real websites exposed mistakes in our scanner: error pages were being judged as content, a parser bug hid server-rendered text, and our browser capture missed tools that a site had registered. We corrected those mistakes and added regression tests. A disagreement is a reason to inspect the evidence, including our own implementation.
Those comparisons also exposed a gap in what we checked. We now request Markdown from the home page and check whether a response labelled as Markdown actually contains an HTML document, and whether the Markdown response tells caches that the format depends on the request. Correct and deliberately broken examples exercise both checks.
Passing those tests supports these specific checks. It does not prove that every site is fully assessed, or that an agent can complete every task. When access is refused or rendering fails, we explain the limit. When a result is only informational, we keep it separate from defects.
Fifth principle
When a technology is useful for your site, the project helps you implement it.
The builders can generate validated artifacts or provide tutorials tailored to common platforms. The same capabilities are available to people, MCP clients and browser agents. Generated output is checked against the same rules used by the scanner.
The goal is not to create a longer list of work. It is to make worthwhile work easier and safer.
Our mission
We want website owners, developers and agents to be able to:
In closing
You do not need to panic because a gauge turned red.
Remain curious. Learn what is changing. Implement what creates real value. Leave the rest until the evidence gives you a reason.