Skip to main content
Glama

Assert a transition or page state

browser_assert
Read-only

Assert web page changes and verify exact transitions using stored diff evidence or live page checks, including element changes, existence, and visibility.

Instructions

Assert the EXACT transition already read from browser_verify by passing its diffId: immutable, full diff evidence; no new observation and no baseline or id-epoch advance. Stored results return diffId, beforeObservationId, afterObservationId, observationId (the historical after observation), baselineAdvanced: false and evidenceSource: stored. Historical evidence survives later navigation; its element ids are historical, not actionable — find again before acting. Stored diffs support ONLY changed, mustInclude, mustNotInclude, only, maxChanges, becameVisible and becameCovered. Mixing diffId with exists, notCovered, url/urlIncludes, ignore, settleMs, retry or keepBaseline (even false) is pass:false; use a separate live assertion for current page predicates. Unknown, expired, evicted, foreign-session or privacy-invalidated ids return pass:false with error {code: DIFF_UNAVAILABLE, message}, never a live fallback. Without diffId, the existing LIVE assertion mode checks the diff since the last observation and consumes its baseline at the END unless keepBaseline:true; calling it after verify therefore checks a NEW interval. Checks any combination of: url (substring of the current URL), changed (expect the diff since the last observation to be true/false — the faithful negative makes "my action did nothing" ASSERTABLE), mustInclude ([{kind, role, name}] entries that must appear in the diff; kind ∈ added/removed/content/state/style/moved/resized — a framework re-render that REPLACES a node reports kind possible-replacement, and added/removed matchers accept it with STRICT side reading: an added matcher matches the after-side name/role, a removed matcher matches ONLY the before-side name/role (never the after side; selector specs never match through the alias), and the check result says "found (via possible-replacement — identity ambiguous)" instead of a plain green), exists (text findable anywhere on the page), notCovered (text whose best match must not be occluded). FAIL-LOUD CONTRACT: unknown spec keys, empty specs and missing baselines are hard pass:false with a reason — confusion never looks green. Returns structured {pass, hasBaseline, attempts, checks[], changes[]}; the diff evidence (with state from/to) travels with every result. Also: mustNotInclude (assert side-effect ABSENCE), maxChanges, becameVisible/becameCovered (actionability deltas), mustInclude entries accept selector and to:{state:value} (directional state — assert the menu IS open), settleMs and retry:{budgetMs} re-walk against the SAME baseline until pass or budget (CSS transitions land mid-flight). exists searches accessible names AND page text. SPA soft navs: results with a baseline include navigated:true + baselineUrl when the URL moved since the baseline was taken — that diff spans two pages of one document; re-observe on settled content (non-zero, stable actionables) before trusting change-based checks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNolive mode only: substring the current URL must contain
onlyNochange scoping: EVERY change must match one of these matchers; this does not establish causality
retryNolive mode only: re-walk against the SAME baseline until pass or budget
diffIdNoopaque evidence id from browser_verify: assert that stored full transition without observing; accepts only diff predicates, never live page checks or retry/ignore/baseline options
existsNolive mode only: text that must be findable on the current page
ignoreNolive mode only: CSS selectors whose subtree changes are excluded (e.g. the agent toolbar)
changedNoexpected changed value for the stored diffId, or for the diff since the last observation in live mode
settleMsNolive mode only: wait before the first walk
sessionIdNooptional: the session this call belongs to (from browser_session_open). Omitted uses the shared default session.
maxChangesNofull diff must contain at most N changes (after ignore in live mode)
notCoveredNolive mode only: text whose best match must not be occluded on the current page
mustIncludeNochanges that must appear in the diff (selector = exact; to = expected state after, e.g. {expanded:true})
keepBaselineNolive mode only: do not consume the diff baseline (peek mode — safe to retry); incompatible with diffId even when false
becameCoveredNoan actionable matching this text must have become covered
becameVisibleNoan actionable matching this text must have become visible
mustNotIncludeNochanges that must NOT appear (assert absence of side-effects)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint, the description discloses that live mode consumes its baseline at the end unless keepBaseline:true, making repeated calls non-idempotent. It also details error handling: unknown/expired IDs return DIFF_UNAVAILABLE, never a live fallback. This goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph with many repeated caveats and parentheticals (e.g., 'immutable, full diff evidence' and 'Historical evidence survives...'). While complex, it is not concise and would benefit from structured bullets. It is over 1000 words where a few hundred would suffice.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (two modes, many parameters, error cases, SPA navigation), the description is thorough, covering fail-loud contract, return structure {pass, hasBaseline, attempts, checks[], changes[]}, and SPA navigated flag. No output schema exists, but the description compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description elaborates each parameter beyond the schema, e.g., explaining mustInclude's possible-replacement handling, directional state with to:{state:value}, that exists searches accessible names and page text, and the fail-loud contract for empty specs. Schema descriptions are minimal ('live mode only: substring...'), so the description adds crucial context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool asserts a stored transition via diffId or a live diff since the last observation, distinguishing it from browser_verify which reads the transition. The title 'Assert a transition or page state' matches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly explains when to use live mode vs stored diffId mode, and explicitly warns against mixing diffId with live-only options (e.g., 'Mixing diffId with exists, notCovered, url... is pass:false; use a separate live assertion'). It also notes that calling without diffId after verify checks a new interval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zumerlab/snapsurf'

If you have feedback or need assistance with the MCP directory API, please join our Discord server