Skip to main content
Glama
t3ratech

T3rnel Browser — Session Bridge

Official
by t3ratech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

session_fill

Idempotent

Fill a form field in one step, including rich-text editors, using a CSS selector or snapshot ref. Writes via native setter and fires input/change events that React and Vue listen for.

Instructions

Set a form field's value in one step — input, textarea, or a rich-text editor such as ProseMirror, Lexical or Slate. Writes through the native value setter and then fires input and change, which is what React and Vue listen for. Returns {filled} naming the field. Use session_type instead when a field only reacts to real keystrokes, and session_select for a dropdown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoA ref from session_snapshot, such as @e12, used instead of selector
tabIdNoTab to act on; uses the active tab when omitted
valueYesText to place in the field, replacing whatever is there
selectorYesCSS selector for the field to fill

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.2.0
    • addedInput schema / properties / ref / examples
      Added value: +[
+  "@e12"
+]
    • addedInput schema / properties / ref / pattern
      Added value: +"^@?e\\d+$"
    • addedInput schema / properties / selector / description
      Added value: +"CSS selector for the field to fill"
    • addedInput schema / properties / tabId / description
      Added value: +"Tab to act on; uses the active tab when omitted"
    • addedInput schema / properties / value / description
      Added value: +"Text to place in the field, replacing whatever is there"
  2. First observedv1.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, the description discloses that it writes through the native value setter, fires input and change events, and returns {filled} naming the field. It also clarifies support for rich-text editors. This is meaningful behavioral context not present in the annotations or schema.

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

Conciseness5/5

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

Three dense sentences: the action and target, the mechanism and why it works, and the return value plus alternative routing. No filler, and the most important information is front-loaded.

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?

The tool has no output schema, but the description explicitly names the return value, {filled}. It covers the behavioral mechanism, supported field types, exclusions, and alternatives, making it complete for an agent deciding whether and how to call this tool.

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 selector, value, ref, and tabId. The description does not add per-parameter detail beyond what the schema provides, so the baseline 3 is appropriate.

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 starts with a specific verb and resource: 'Set a form field's value', and expands the target to input, textarea, and rich-text editors. It also names sibling tools (session_type, session_select) and explains what this tool is not, making it easy to distinguish.

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 gives explicit routing guidance: use session_type when a field only reacts to real keystrokes, and session_select for a dropdown. It also explains why session_fill works for React/Vue fields by firing input and change, giving the agent a clear decision rule.

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