Manifest turns any webpage into a structured JSON map of what an AI agent can click, fill, and submit. One API call, no fragile selectors. Every action comes with resolved CSS/role locators, plus a requires field that encodes dependencies between elements (e.g. "select a plan before this button is clickable"). That's context aria snapshots don't give you. Python SDK, LangChain support, and an MCP server included. Built for anyone shipping browser agents.
No reviews yetBe the first to leave a review for Manifest
Finally a tool that captures the "why" behind clickable elements, not just the selectors. The requires dependency mapping is genuinely useful and saved me a ton of trial and error on a flaky login flow.
Thanks, Utku — that "why, not just the selector" framing is exactly what I was going for, since a bare selector tells you an element exists but not what has to happen before it's actually usable. Glad requires cut down the trial and error on a flaky login flow — that's a classic case where the ordering isn't obvious until something silently fails.
Report
the requires field is such a smart touch, encoding dependencies directly into the map saves so much back-and-forth between agent and page. clean SDK and MCP server setup too.
Thanks, Ferhat — that back-and-forth is exactly what I wanted to cut out. Without the dependency info baked in, the agent's stuck poking at the page to figure out what's actually available, which burns cycles it shouldn't need to. Glad the SDK and MCP setup are landing clean too — appreciate you calling that out specifically.
Report
the requires field for element dependencies is genuinely useful, something I've hacked together badly on past projects. excited to try it with an MCP server setup
Thanks, Hanım — "hacked together badly" is a pretty universal experience with this problem, which is exactly why I wanted it baked into the response instead of something everyone has to rebuild themselves. Hope the MCP server setup makes it an easy first try — let me know how it goes.
Report
The requires field encoding dependencies between elements is the interesting part — "select a plan before this button is clickable" is exactly the context accessibility trees drop, and it's where most browser agents burn their retries. Question: how do you handle drift? If the site ships a redesign, does the manifest regenerate per-call (so it's always fresh but you pay latency), or is there caching with some invalidation heuristic? That trade-off decides whether I'd trust it in a scheduled job.
Report
Action manifests are a useful primitive for agent workflows. The part I would want to see emphasized is preconditions and permissions: what the page action is allowed to do, what success means, and what evidence gets handed back after the run.
@krekeltronics
That’s a good framing, and honestly it’s not something the manifest covers today. Right now it’s descriptive — here’s what’s clickable/fillable, here’s the dependency order — not prescriptive about permissions or outcomes.
The “what evidence gets handed back” part is the one that resonates most. An agent following a requires chain still has no structured way to confirm the submit actually succeeded vs. failed silently, short of re-snapshotting and diffing state. That’s a real gap.
Preconditions/permissions is a bigger scope question — feels closer to policy layer than page-structure layer, but I could see a case for a lightweight version (e.g. flagging destructive actions) living in the manifest itself.
Would be curious what “success” evidence would actually need to look like for your use case — DOM diff, a specific element appearing, a network response, something else?
Report
The dependency graph between elements is genuinely useful for agent builders, something I've been piecing together by hand for months. One thing that would save a ton of debugging time: let me simulate an action through the same API and tell me whether the requires chain actually cleared or if something is silently blocking it. Right now I can see the map, but I can't trust it until I try it.
@glzaral3n
That’s a really clear way to put it — “I can see the map but can’t trust it until I try it” is exactly the gap. Right now the manifest is read-only: it tells you what should work, not whether it does. Validating a requires chain means actually driving the browser, which is a different layer than what exists today.
That’s genuinely useful signal, though — a dry-run/simulate endpoint that executes against the live page and reports back which dependencies cleared vs. what blocked would turn the manifest from a map into something checkable. Filing that away as a real ask rather than a nice-to-have.
Out of curiosity — when you’ve hit silent blocks piecing this together by hand, was it usually a timing issue (element not ready), a hidden precondition (auth/state), or something else?
Report
The requires field for encoding element dependencies is genuinely clever. It's the kind of context that usually takes teams weeks of brittle DOM mapping to figure out, baked right into the response.
@uurk6oe Thanks, Uğur — that's exactly the gap I was aiming at. Teams end up hand-mapping that dependency logic per site, and it's brittle the moment the DOM shifts, so baking it into the response instead of leaving it as tribal knowledge in someone's scraper script was the whole point. Appreciate you naming why it matters, not just that it exists.
Finally a tool that captures the "why" behind clickable elements, not just the selectors. The requires dependency mapping is genuinely useful and saved me a ton of trial and error on a flaky login flow.
Manifest
@utkufqkz
Thanks, Utku — that "why, not just the selector" framing is exactly what I was going for, since a bare selector tells you an element exists but not what has to happen before it's actually usable. Glad requires cut down the trial and error on a flaky login flow — that's a classic case where the ordering isn't obvious until something silently fails.
the requires field is such a smart touch, encoding dependencies directly into the map saves so much back-and-forth between agent and page. clean SDK and MCP server setup too.
Manifest
@ferhattkge
Thanks, Ferhat — that back-and-forth is exactly what I wanted to cut out. Without the dependency info baked in, the agent's stuck poking at the page to figure out what's actually available, which burns cycles it shouldn't need to. Glad the SDK and MCP setup are landing clean too — appreciate you calling that out specifically.
the requires field for element dependencies is genuinely useful, something I've hacked together badly on past projects. excited to try it with an MCP server setup
Manifest
@hanmtanrkanwyt
Thanks, Hanım — "hacked together badly" is a pretty universal experience with this problem, which is exactly why I wanted it baked into the response instead of something everyone has to rebuild themselves. Hope the MCP server setup makes it an easy first try — let me know how it goes.
The requires field encoding dependencies between elements is the interesting part — "select a plan before this button is clickable" is exactly the context accessibility trees drop, and it's where most browser agents burn their retries. Question: how do you handle drift? If the site ships a redesign, does the manifest regenerate per-call (so it's always fresh but you pay latency), or is there caching with some invalidation heuristic? That trade-off decides whether I'd trust it in a scheduled job.
Action manifests are a useful primitive for agent workflows. The part I would want to see emphasized is preconditions and permissions: what the page action is allowed to do, what success means, and what evidence gets handed back after the run.
Manifest
The dependency graph between elements is genuinely useful for agent builders, something I've been piecing together by hand for months. One thing that would save a ton of debugging time: let me simulate an action through the same API and tell me whether the requires chain actually cleared or if something is silently blocking it. Right now I can see the map, but I can't trust it until I try it.
Manifest
The requires field for encoding element dependencies is genuinely clever. It's the kind of context that usually takes teams weeks of brittle DOM mapping to figure out, baked right into the response.
Manifest
@uurk6oe
Thanks, Uğur — that's exactly the gap I was aiming at. Teams end up hand-mapping that dependency logic per site, and it's brittle the moment the DOM shifts, so baking it into the response instead of leaving it as tribal knowledge in someone's scraper script was the whole point. Appreciate you naming why it matters, not just that it exists.