Skip to main content
Glama

set_attribute

Change an HTML attribute on a live DOM element to update form fields, hidden inputs, ARIA states, or data attributes. Returns confirmation plus a change report.

Instructions

Set an HTML attribute value on an element. Returns confirmation. When to use: to modify element attributes for form manipulation, changing hidden field values, toggling ARIA states, or setting data attributes. Related: get_attribute (read attribute value first), get_dom_snapshot (find element selectors). Multi-agent: agent-scoped tabs; cross-agent reject with TAB_NOT_OWNED; cap configurable (default 8, 1-64). Pass tab_id only when this agent owns multiple tabs; auto-resolves otherwise. RETURNS change_report: when this tool runs, the response includes a change_report field with a compact diff of what the action mutated (URL, dialogs_opened, nodes_added, nodes_removed, attrs_changed, inputs_changed, focus_shift). Use this to learn the consequence without calling read_page next. If the report exceeds the size cap, change_report.truncated:true and change_report_hint are set; call read_page for the full state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesValue to set the attribute to
clientYesAllowlisted client label. Validated against the shared v0.9.36 server/extension allowlist (see mcp/src/tools/visual-session.ts -- MCP_VISUAL_CLIENT_LABELS). Required.
tab_idNoOptional. Tab id this action targets. Omit when the calling agent owns exactly one tab; pass to disambiguate when the agent owns multiple. Single-tab agents and legacy popup/sidepanel/autopilot do not need to pass this.
is_finalNoWhen true, the visual session clears immediately after this tool resolves. Optional (default false).
selectorYesCSS selector or element ref for the target element
attributeYesHTML attribute name to set
visual_reasonYesShort human-readable reason shown in the overlay (for example, "Logging in to GitHub"). Required.

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?

No annotations, so the description carries the full burden, and it delivers unusual depth: cross-agent rejection with TAB_NOT_OWNED, a configurable action cap with default and range, and a declared change_report payload naming the exact mutated fields (URL, dialogs_opened, nodes_added/removed, attrs_changed, inputs_changed, focus_shift) plus truncation behavior and fallback. It stops short of stating permission/auth requirements or whether the attribute is created when absent.

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?

Front-loads purpose, then when-to-use, related tools, multi-agent caveats, and returns in a logical order. The RETURNS paragraph is long but justified because there is no output schema; a sentence or two of it could still be tightened.

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 7-param mutation tool with no annotations and no output schema, the description supplies the return shape, the error path (TAB_NOT_OWNED), the cap, and tab ownership rules. Remaining gaps are minor: no statement of failure behavior for a non-matching selector or whether a missing attribute is created.

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 all seven parameters are already documented, including tab_id auto-resolution and the client allowlist. The description's tab_id sentence largely restates the schema, adding no syntax or format detail beyond it; 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?

Opens with a specific verb+resource ("Set an HTML attribute value on an element") and immediately names the complementary siblings get_attribute and get_dom_snapshot, so an agent can place it against the many DOM/input siblings without reading schemas.

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?

Explicit when-to-use list (form manipulation, hidden field values, ARIA state toggling, data attributes) plus named alternatives with their conditions: get_attribute to read first, get_dom_snapshot to find selectors. Also gives the tab_id selection rule explicitly (pass only when owning multiple tabs).

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