Skip to main content
Glama

observe

Monitor DOM element changes: collect text or attribute modifications over time, or wait for a condition to trigger an action. Use instead of MutationObserver or polling.

Instructions

Watch an element for changes over time — use this INSTEAD of writing MutationObserver/setInterval/setTimeout code in evaluate. Two modes: (1) collect — watch for 'duration' ms, return all text/attribute changes (e.g. collect 3 values that appear one after another). (2) until — wait for a condition, then optionally click immediately (e.g. click Capture when counter hits 8). Use click_first to trigger the action that causes changes (observer is set up BEFORE the click, so nothing is missed).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
selectorYesCSS selector or element ref (e.g. 'e5') of the element to observe
durationNoCollect all changes for this many ms, then return them. Mutually exclusive with 'until'. Default: 5000
untilNoJS expression evaluated on each change — stops when it returns true. Variable 'el' is the observed element. Example: el.textContent === '8'
then_clickNoCSS selector or element ref (e.g. 'e5') to click immediately when 'until' condition is met (for timing-critical actions). Only used with 'until'.
click_firstNoCSS selector or element ref (e.g. 'e5') to click AFTER the observer is set up but BEFORE collection starts. Use to trigger the changes you want to observe (e.g. 'Start Mutations' button).
collectNoWhat to collect: 'text' for textContent changes, 'attributes' for attribute changes, 'all' for both (default: 'text')text
intervalNoPolling interval in ms for change detection fallback (default: 100)
timeoutNoMaximum observation time in ms (default: 10000, max: 25000)
Behavior4/5

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

With no annotations, the description fully discloses key behaviors: observer is set up before click_first, duration and until are mutually exclusive, polling interval fallback, and timeout limit. It does not mention any destructive side effects, but that's expected for a read-only watch tool.

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

Conciseness4/5

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

At ~100 words, the description is efficient and front-loaded with purpose. It could be slightly more structured with bullet points, but it avoids fluff and each sentence adds value.

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

Completeness4/5

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

Given the complexity (8 parameters, important timing/interactions, no output schema), the description covers the major points: modes, mutual exclusions, click_first timing, then_click usage. It lacks explicit return type description but mentions 'return all text/attribute changes'. Overall, it is sufficient for correct usage.

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

Parameters4/5

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

Schema coverage is 100% with good descriptions, but the tool description adds significant context: explains the two modes (collect/until), provides examples of use cases, and clarifies parameter interactions (e.g., then_click only works with until). This adds value beyond the schema alone.

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 clearly states the tool watches an element for changes, explicitly distinguishing it from writing custom MutationObserver/setInterval code in evaluate. It defines two modes and uses specific verbs like 'watch', 'collect', and 'wait for'. This differentiates it from sibling tools like evaluate and wait_for.

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

Usage Guidelines4/5

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

The description tells when to use this tool (instead of writing observe logic in evaluate) and explains the two modes. However, it does not explicitly mention when not to use it or compare to other observation tools like wait_for, leaving some ambiguity.

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

Install Server

Other Tools

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/Silbercue/public-browser'

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