Project background
Turning guideline text into something an agent can query directly.
This project explores whether the W3C Web Sustainability Guidelines can be exposed as structured, task-oriented tools through WebMCP.
The goal is not to replace the guidelines, human review, or professional judgement. The goal is to test whether web standards can provide machine-readable interfaces that help people find, apply, test, and document sustainability guidance more effectively.
What WebMCP adds
The page already works as a normal JavaScript demo. A person can load the data, search it, and read the results. WebMCP adds a second interface for compatible browsers and agents: the page can register named tools, describe their inputs, and let another system invoke them directly.
That does not make the page smarter on its own. It makes the page easier to treat as a task surface instead of only a document viewer.
What this project uses
Categories, guidelines, criteria, benefits, tags, and resources.
Testing and reporting techniques that link back to WSG guidance.
These files are copied into the project through a scheduled GitHub Action so the demo can be served from GitHub Pages without requiring a server.
Why WSG and STAR are useful together
WSG explains what the guidance is about. STAR gives a practical way to test, review, and report on that guidance. Used together, they support a better workflow than search alone.
Guidance
↓
Checklist
↓
Testing method
↓
Evidence
↓
Review or reporting
That makes it easier to move from reading a standard to using it in design reviews, procurement, audits, reporting, and education.
From lookup tools to task-layer tools
The current project started as lookup and search tooling. That is still useful, but it does not answer common work questions directly. A person often needs a starting point, a draft checklist, a draft review, or a contract question set.
The new task-layer tools are a way to test that next step. They turn the dataset into draft outputs that are closer to real work, while still keeping the process explicit and inspectable.
How task-layer tools help
- Design reviews: surface likely concerns before work moves too far.
- Procurement: suggest contract language and review points for suppliers.
- Audits: turn criteria into draft questions and evidence prompts.
- Reporting: help structure review notes and draft claims for human editing.
- Education: show how guidance connects to examples, tests, and checklists.
Why outputs are drafts only
The tools use deterministic matching and curated source data. They can help assemble a first pass, but they do not understand context the way a human reviewer does.
Draft output is safer than pretending the tool has final authority. It also makes it easier to inspect what was matched and why.
Why human review is required
The page can suggest guidance, but it cannot verify the project, the contract, or the evidence behind a claim. Human review is still needed for interpretation, exceptions, and final decisions.
Current limitations
- It is an experimental prototype, not an official W3C deliverable.
- It does not certify conformance, sustainability, accessibility, procurement, or legal compliance.
- Human review is required before relying on any generated output.
- WebMCP support is experimental and browser support is limited.
- The browser cannot directly expose all internal state to a web page.
What WebMCP adds beyond a normal browser demo
A normal browser demo lets people click buttons and read the results. WebMCP adds a machine-facing interface that can describe tools in a structured way so compatible systems can discover and call them.
Normal browser interface:
A person clicks buttons and reads results.
WebMCP interface:
An agent discovers tools, reads input schemas, and calls the page's functions directly.
How the policy files fit in
This prototype is not an official W3C deliverable, but it is useful as a demonstration of how repository policy can point agents toward WebMCP when sustainability matters. In this repo, [SUSTAINABILITY.md](./SUSTAINABILITY.md) explains the human policy layer, and [AGENTS.md](./AGENTS.md) tells the agent when to consult the WSG tools.
That means an LLM does not need to guess whether sustainability guidance matters. The instruction is explicit: if the change touches accessibility, page weight, request count, hosting, or infrastructure, check the WSG WebMCP tools before drafting code.
How this could apply to other web standards
The same pattern could apply to accessibility guidance, ARIA roles, design tokens, privacy guidance, security guidance, or digital public goods criteria. The point is not to automate judgement away. The point is to make the standard easier to use as a task surface.
Standard
↓
Structured data
↓
Accessible tool
↓
Human review
↓
Safer decisions