The Lumar Agentic Readiness Scanner
Stay curious. You are not behind.
The agentic web is taking shape in public. This is what we score, what we refuse to score, and why.
Where we are
The agentic web is taking shape in public
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
Missing is not the same as broken
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.
You do not publish it
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.
You publish it, and it does not work
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
Not every protocol is equally important
We track the evidence behind each technology:
- Is it an established standard?
- Is it implemented by major platforms?
- Are independent websites adopting it?
- Do real agents appear to use it?
- Is adoption rising?
- Is it still experimental?
- Does it apply to this kind of website?
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 score should inform, not frighten
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
We show our work
Every check should answer four questions:
What did we observe?
Why does it matter?
Who says it is required or recommended?
What would correct implementation look like?
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.
Fifth principle
Understanding should lead to action
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
An independent, evidence-led view of the agentic web as it develops
We want website owners, developers and agents to be able to:
- Understand the available technologies.
- See which ones are grounded, rising or experimental.
- Decide what genuinely applies to their website.
- Verify that published implementations work.
- Build useful support without needless complexity.
- Revisit those decisions as the web changes.
You do not need to adopt everything.
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.