Skip to main content
Glama

browser_frame

Navigate into or out of browser frames: enter a frame by ref, move up with parent=true, or return to the top level when both are omitted.

Instructions

Enter a frame, go up one level with parent=true, or return to top level when both omitted.

Input Schema

NameRequiredDescriptionDefault
refNo
parentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It discloses that the call mutates the browsing context (changing which document subsequent actions target), which is useful, but says nothing about whether ref must come from a prior snapshot, whether nested frames are supported, or what happens when ref is invalid or already at top level.

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?

A single compact sentence with no filler that front-loads the primary action before the two alternatives. Its terseness works in its favor, though the unnamed 'ref' makes the first clause slightly less precise than the other two.

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

Completeness3/5

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

For a 2-parameter, no-output-schema, no-annotation tool, the description covers the mode-selection logic but omits the ref format, error behavior, and any note about how frame context affects subsequent calls. Adequate to invoke in the happy path, incomplete for edge cases.

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 0%, so the description must compensate for both parameters. It explains parent=true and the both-omitted case well, but 'ref' is never mentioned by name and its expected format (snapshot ref vs selector vs index) is left entirely undefined.

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

Purpose4/5

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

The description states a specific action (enter a frame / move up / return to top) for a browser frame-context tool, which no sibling covers. It is clear what the tool manipulates, though it never explicitly names the 'ref' parameter as the thing that selects the frame being entered.

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?

It enumerates the three invocation modes and the exact condition that selects each: ref to enter, parent=true to go up one level, both omitted to return to top level. It gives no guidance on when in a workflow to call it (e.g., after a snapshot to target an iframe) or what happens on a non-frame element.

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