Skip to main content
Glama
RonsDad
by RonsDad

multi_browserbase_stagehand_observe_session

Identifies interactive elements like buttons and form fields on web pages for subsequent automation actions using specific visual or functional descriptions.

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

  • Core handler function that performs the observation using Stagehand's page.observe() method. This is the primary execution logic for observing elements on the page.
    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,
      };
    }
  • Registers the specific tool named "multi_browserbase_stagehand_observe_session" by creating a multi-session aware wrapper around the base observeTool.
    export const observeWithSessionTool = createMultiSessionAwareTool(observeTool, {
      namePrefix: "multi_",
      nameSuffix: "_session",
    });
  • Helper factory function that generates session-aware tools by extending the input schema with sessionId and wrapping the original handler to use a session-specific context.
    function createMultiSessionAwareTool<TInput extends InputType>(
      originalTool: Tool<TInput>,
      options: {
        namePrefix?: string;
        nameSuffix?: string;
      } = {},
    ): Tool<InputType> {
      const { namePrefix = "", nameSuffix = "_session" } = options;
    
      // Create new input schema that includes sessionId
      const originalSchema = originalTool.schema.inputSchema;
      let newInputSchema: z.ZodSchema;
    
      if (originalSchema instanceof z.ZodObject) {
        // If it's a ZodObject, we can spread its shape
        newInputSchema = z.object({
          sessionId: z.string().describe("The session ID to use"),
          ...originalSchema.shape,
        });
      } else {
        // For other schema types, create an intersection
        newInputSchema = z.intersection(
          z.object({ sessionId: z.string().describe("The session ID to use") }),
          originalSchema,
        );
      }
    
      return defineTool({
        capability: originalTool.capability,
        schema: {
          name: `${namePrefix}${originalTool.schema.name}${nameSuffix}`,
          description: `${originalTool.schema.description} (for a specific session)`,
          inputSchema: newInputSchema,
        },
        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);
        },
      });
    }
  • Input schema definition for the base observe tool, which is extended by adding sessionId for the multi-session variant.
    const observeSchema: ToolSchema<typeof ObserveInputSchema> = {
      name: "browserbase_stagehand_observe",
      description:
        "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.",
      inputSchema: ObserveInputSchema,
    };
  • Main tools array that includes all multi-session tools (via multiSessionTools), making this tool available to the MCP server.
    export const TOOLS = [
      ...multiSessionTools,
      ...sessionTools,
      navigateTool,
      actTool,
      extractTool,
      observeTool,
      screenshotTool,
      getUrlTool,
    ];
Behavior4/5

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

With no annotations provided, the description carries full burden and does well. It explains what the tool returns ('detailed information about the identified elements including their properties, location, and interaction capabilities'), how results are used ('can then be used to craft precise actions'), and provides behavioral guidance ('The more specific your observation instruction, the more accurate the element identification will be'). It doesn't mention performance characteristics like rate limits or error conditions, but provides substantial operational context.

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 the core purpose in the first sentence. Most sentences earn their place by providing important guidance, though the analogy 'Think of this as your 'eyes' on the page' could be considered slightly redundant given the 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?

For a tool with 3 parameters, 100% schema coverage, but no annotations or output schema, the description provides good context. It explains the tool's role in a workflow (observe → act), distinguishes it from alternatives, and describes what information is returned. The main gap is the lack of output format details, but given the tool's purpose is element identification rather than complex data processing, the description 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 significant additional meaning beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is high.

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 on web page), and distinguishes from siblings by mentioning 'DO NOT use this tool for extracting text content or data - use the extract tool instead.'

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 guidance on when to use ('Use this tool when you need to locate elements before performing actions with the act tool') and when not to use ('DO NOT use this tool for extracting text content or data - use the extract tool instead'). It clearly distinguishes this tool from the 'extract' and 'act' sibling tools.

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

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