Skip to main content
Glama
fullselfbrowsing

FSB (Full Self-Browsing)

Official
by fullselfbrowsing
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

trigger

Arm a reactive DOM watcher on one selector to detect changes, thresholds, value matches, or text. Persists across service-worker eviction.

Instructions

Arm a reactive DOM trigger on one selector. Use this when the user wants to watch an element until it changes, crosses a threshold, equals or matches a value, or contains text. The watch is owned by the background trigger runtime and persisted across service-worker eviction. Pass one selector and one condition object; runtime validation checks the nested condition details before arming. Use stop_trigger to cancel, get_trigger_status to inspect one watcher, and list_triggers to enumerate watchers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
watchNoOptional watch mechanism. live-observe uses in-page mutation observation; refresh-poll periodically reloads the trigger-owned tab and reads the selector.
localeNoOptional locale hint for numeric parsing, such as en-US or de-DE.
tab_idNoOptional. Tab id to arm the trigger against. Alias of target_tab_id for callers that use ordinary tool tab targeting.
extractNoOptional value extraction mode. Defaults are selected by the trigger runtime from the condition.
attrNameNoOptional alias for attribute when content-side trigger readers use attrName.
detachedNoWhen true, arm and return trigger_id immediately instead of blocking.
selectorYesCSS selector or stable element selector to watch.
attributeNoOptional attribute name when extract is attribute.
conditionNoTrigger condition object validated by the trigger manager. Supported kinds include changed, threshold, delta_percent, equals, contains, regex, and compound AND/OR conditions.
timeout_msNoBlocking wait timeout in ms. Default 120000. Timeout returns timed_out.
trigger_idNoOptional caller-supplied trigger correlation id. MCP callers may omit it; the server generates one before arming.
rearm_on_fireNoWhen true, keep watching after a fire and expose fire_count/last_event through status.
target_tab_idNoOptional. Explicit target tab id for the watched page.
poll_interval_msNoOptional refresh-poll interval in milliseconds. The background runtime enforces its minimum floor.
decimal_separatorNoOptional decimal separator override for numeric parsing.
safety_ceiling_msNoMaximum blocking wait before auto-detach. Default/max 240000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and delivers real value: it discloses that the watch is owned by a background runtime and persisted across service-worker eviction, and that nested condition details are runtime-validated before arming. It does not state the default blocking behavior (implied only by the detached parameter) or the lifecycle of fired events, which is a meaningful omission for a 16-parameter stateful 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?

Five sentences, all front-loaded with the purpose first, then usage, then behavioral context, then routing. Every sentence carries information, though the runtime-validation sentence is somewhat redundant with the schema's condition description.

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?

For a 16-parameter, stateful, annotation-free tool with no output schema, the description covers ownership, persistence, validation and sibling routing well. It stops short of explaining default blocking vs. detached return semantics and what a fire delivers to the caller, which an agent arming a long-lived watcher would benefit from.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 16 parameters including enums, aliases, defaults and the condition kinds. The description only echoes 'one selector and one condition object', which understates the parameter surface but adds nothing beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (arm) and resource (a reactive DOM trigger on one selector), and immediately scopes it to a single element. An agent can distinguish it from stop_trigger, get_trigger_status and list_triggers purely from the opening sentence.

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?

Explicitly names the trigger conditions that should select this tool (change, threshold, equals/match, contains) and routes the agent to the three sibling tools for cancel, inspect and enumerate. When-to-use and alternatives are both stated outright.

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

Deploy Server

Other Tools