Skip to main content
Glama

browserbase_stagehand_observe

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

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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

  • The handleObserve function implements the core logic of the browserbase_stagehand_observe tool by retrieving the stagehand from context and calling stagehand.page.observe() with the input parameters, returning the observations as JSON-formatted text.
    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,
      };
    }
  • Zod schema definition for the tool's input (ObserveInputSchema) and the complete tool schema (observeSchema) including the tool name 'browserbase_stagehand_observe', detailed description, and input validation.
    const ObserveInputSchema = z.object({
      instruction: z
        .string()
        .describe(
          "Detailed 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.",
        ),
      returnAction: z
        .boolean()
        .optional()
        .describe(
          "Whether 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.",
        ),
    });
    
    type ObserveInput = z.infer<typeof ObserveInputSchema>;
    
    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,
    };
  • Registers the tool components (capability, schema, and handler) into the observeTool object, which is exported as default.
    const observeTool: Tool<typeof ObserveInputSchema> = {
      capability: "core",
      schema: observeSchema,
      handle: handleObserve,
    };
  • The observeTool is included in the main TOOLS export array from tools/index.ts, which collects all tools for registration in 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 the full burden and does well by explaining behavioral traits: it describes what the tool returns ('detailed information about identified elements including properties, location, and interaction capabilities'), how to use the output ('can then be used to craft precise actions'), and performance tips ('the more specific your observation instruction, the more accurate the element identification will be'). It doesn't mention error handling or limitations, keeping it from a perfect score.

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 key information (purpose and usage guidelines in the first sentences). Some sentences could be more concise (e.g., 'Think of this as your 'eyes' on the page' is somewhat redundant), but overall it's well-structured with minimal waste.

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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, usage, behavioral traits, and output usage. It lacks details on error cases or specific return formats, but for a tool with no output schema, it provides sufficient context for effective use.

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 both parameters thoroughly. The description adds some context by mentioning 'observation instruction' and implying specificity, but doesn't provide additional semantic details beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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 with specific verbs ('observes and identifies') and resources ('interactive elements on the current web page'), and distinguishes it from siblings by specifying it's for actionable elements only, not for extraction (contrasting with 'extract tool').

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?

It provides explicit guidance on when to use ('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'), clearly differentiating from alternatives like 'act' and 'extract' 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/vaibhavAtlys/mcp-server-browserbase'

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