Skip to main content
Glama
Xxx00xxX33

Browserbase MCP Server

by Xxx00xxX33

multi_browserbase_stagehand_observe_session

Identifies interactive web page elements like buttons, links, and form fields for subsequent automation actions using specific visual or functional instructions.

Instructions

Observes and identifies specific interactive elements on the current web page that can be used for subsequent actions. This tool is specifically designed for finding actionable (interactable) elements such as buttons, links, form fields, dropdowns, checkboxes, and other UI components that you can interact with. Use this tool when you need to locate elements before performing actions with the act tool. DO NOT use this tool for extracting text content or data - use the extract tool instead for that purpose. The observe tool returns detailed information about the identified elements including their properties, location, and interaction capabilities. This information can then be used to craft precise actions. The more specific your observation instruction, the more accurate the element identification will be. Think of this as your 'eyes' on the page to find exactly what you need to interact with. (for a specific session)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sessionIdYesThe session ID to use
instructionYesDetailed instruction for what specific elements or components to observe on the web page. This instruction must be extremely specific and descriptive. For example: 'Find the red login button in the top right corner', 'Locate the search input field with placeholder text', or 'Identify all clickable product cards on the page'. The more specific and detailed your instruction, the better the observation results will be. Avoid generic instructions like 'find buttons' or 'see elements'. Instead, describe the visual characteristics, location, text content, or functionality of the elements you want to observe. This tool is designed to help you identify interactive elements that you can later use with the act tool for performing actions like clicking, typing, or form submission.
returnActionNoWhether to return the action to perform on the element. If true, the action will be returned as a string. If false, the action will not be returned.

Implementation Reference

  • Registers the 'multi_browserbase_stagehand_observe_session' tool by creating a session-aware wrapper around the base observeTool using the createMultiSessionAwareTool factory. The name is constructed as 'multi_' + 'browserbase_stagehand_observe' + '_session'.
    export const observeWithSessionTool = createMultiSessionAwareTool(observeTool, {
      namePrefix: "multi_",
      nameSuffix: "_session",
    });
  • Handler implementation for all multi-session tools, including 'multi_browserbase_stagehand_observe_session'. Retrieves the specified session from the store, creates a session-specific context, and delegates execution to the original tool's handler.
    handle: async (
      context: Context,
      params: z.infer<typeof newInputSchema>,
    ): Promise<ToolResult> => {
      const { sessionId, ...originalParams } = params;
    
      // Get the session
      const session = stagehandStore.get(sessionId);
      if (!session) {
        throw new Error(`Session ${sessionId} not found`);
      }
    
      // Create a temporary context that points to the specific session
      const sessionContext = Object.create(context);
      sessionContext.currentSessionId =
        session.metadata?.bbSessionId || sessionId;
      sessionContext.getStagehand = async () => session.stagehand;
      sessionContext.getActivePage = async () => session.page;
      sessionContext.getActiveBrowser = async () => session.browser;
    
      // Call the original tool's handler with the session-specific context
      return originalTool.handle(sessionContext, originalParams);
    },
  • Dynamic schema generation for the multi-session tool, including construction of the exact name 'multi_browserbase_stagehand_observe_session' and input schema that adds 'sessionId' to the original schema.
    schema: {
      name: `${namePrefix}${originalTool.schema.name}${nameSuffix}`,
      description: `${originalTool.schema.description} (for a specific session)`,
      inputSchema: newInputSchema,
    },
  • Core handler logic for the base 'browserbase_stagehand_observe' tool, which is delegated to by the multi-session wrapper. Performs the actual page observation using Stagehand's observe method.
    async function handleObserve(
      context: Context,
      params: ObserveInput,
    ): Promise<ToolResult> {
      const action = async (): Promise<ToolActionResult> => {
        try {
          const stagehand = await context.getStagehand();
    
          const observations = await stagehand.page.observe({
            instruction: params.instruction,
            returnAction: params.returnAction,
          });
    
          return {
            content: [
              {
                type: "text",
                text: `Observations: ${JSON.stringify(observations)}`,
              },
            ],
          };
        } catch (error) {
          const errorMsg = error instanceof Error ? error.message : String(error);
          throw new Error(`Failed to observe: ${errorMsg}`);
        }
      };
    
      return {
        action,
        waitForNetwork: false,
      };
    }
  • Includes the 'multi_browserbase_stagehand_observe_session' tool (as observeWithSessionTool) in the multiSessionTools array, which is part of the central TOOLS export used for MCP tool registration.
    observeWithSessionTool,
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool returns 'detailed information about the identified elements including their properties, location, and interaction capabilities,' explains that 'the more specific your observation instruction, the more accurate the element identification will be,' and clarifies this is for 'a specific session.' However, it doesn't mention potential limitations like timeouts, error conditions, or performance characteristics.

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?

The description is appropriately sized and front-loaded with core purpose. Most sentences earn their place by providing usage guidance, behavioral context, or practical advice. However, some phrasing could be more concise (e.g., 'Think of this as your 'eyes' on the page' is somewhat redundant with earlier explanation).

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 3 parameters, no annotations, and no output schema, the description does well to explain the tool's purpose, usage context, and behavioral characteristics. It covers what the tool does, when to use it, and what information it returns. The main gap is lack of output format details (though mentioned generally), but for a tool with good parameter documentation and clear purpose, this is reasonably complete.

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 three parameters thoroughly. The description adds some context about the 'instruction' parameter ('The more specific your observation instruction, the more accurate the element identification will be'), but doesn't provide additional meaning beyond what's in the schema descriptions. Baseline 3 is appropriate when 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?

The description clearly states the tool's purpose: 'Observes and identifies specific interactive elements on the current web page that can be used for subsequent actions.' It specifies the verb (observe/identify), resource (interactive elements), and scope (current web page). It distinguishes from siblings by explicitly contrasting with 'extract' for text content and positioning as preparatory for 'act' tool usage.

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 provides explicit usage guidance: 'Use this tool when you need to locate elements before performing actions with the act tool. DO NOT use this tool for extracting text content or data - use the extract tool instead for that purpose.' It names specific alternatives (act, extract) and provides clear when-to-use and when-not-to-use criteria.

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/Xxx00xxX33/mcp-server-browserbase'

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