Skip to main content
Glama
Xxx00xxX33

Browserbase MCP Server

by Xxx00xxX33

browserbase_stagehand_observe

Identifies interactive elements like buttons, links, and form fields on web pages to prepare for automated actions. Use specific instructions to locate elements before performing clicks, typing, or form submissions.

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 is the core handler for the 'browserbase_stagehand_observe' tool. It retrieves the stagehand instance from context, calls stagehand.page.observe with the instruction and optional returnAction, formats the observations as JSON text, and returns it as ToolResult.
    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,
      };
    }
  • The Zod schema definitions for the tool input (ObserveInputSchema) and the overall tool schema (observeSchema), including the tool name 'browserbase_stagehand_observe', detailed description, and input validation for 'instruction' and optional 'returnAction'.
    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,
    };
  • The observeTool object that combines the schema and handler, exported as default for use in tool registration.
    const observeTool: Tool<typeof ObserveInputSchema> = {
      capability: "core",
      schema: observeSchema,
      handle: handleObserve,
    };
  • The TOOLS array in tools/index.ts includes the observeTool, making it available for registration in the MCP server.
    export const TOOLS = [
      ...multiSessionTools,
      ...sessionTools,
      navigateTool,
      actTool,
      extractTool,
      observeTool,
      screenshotTool,
    ];
  • src/index.ts:191-218 (registration)
    The registration loop in src/index.ts that iterates over all TOOLS (including observeTool) and calls server.tool() with the tool's schema.name ('browserbase_stagehand_observe'), description, input schema, and a wrapper handler that invokes context.run(tool, params).
    tools.forEach((tool) => {
      if (tool.schema.inputSchema instanceof z.ZodObject) {
        server.tool(
          tool.schema.name,
          tool.schema.description,
          tool.schema.inputSchema.shape,
          async (params: z.infer<typeof tool.schema.inputSchema>) => {
            try {
              const result = await context.run(tool, params);
              return result;
            } catch (error) {
              const errorMessage =
                error instanceof Error ? error.message : String(error);
              process.stderr.write(
                `[Smithery Error] ${new Date().toISOString()} Error running tool ${tool.schema.name}: ${errorMessage}\n`,
              );
              throw new Error(
                `Failed to run tool '${tool.schema.name}': ${errorMessage}`,
              );
            }
          },
        );
      } else {
        console.warn(
          `Tool "${tool.schema.name}" has an input schema that is not a ZodObject. Schema type: ${tool.schema.inputSchema.constructor.name}`,
        );
      }
    });
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 of behavioral disclosure. It effectively describes the tool's behavior: it returns detailed information about identified elements (properties, location, interaction capabilities), explains that results are used to craft precise actions, and notes that specificity improves accuracy. However, it doesn't mention potential limitations like timeouts, error conditions, or what happens if no elements are found.

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 add value, though some repetition occurs (e.g., emphasizing specificity multiple times). It could be slightly more concise by combining related points about element identification and usage.

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 (identifying interactive elements), no annotations, and no output schema, the description does a good job explaining what the tool does, when to use it, and what it returns. It covers the essential context for an agent to understand the tool's role in a workflow. However, without an output schema, more detail about the return format would be helpful.

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 emphasizing the importance of specific instructions and linking to the 'act' tool, but doesn't provide additional semantic meaning 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 explicitly distinguishes it from sibling tools like 'extract' for text content and 'act' for performing actions. It provides a comprehensive list of target elements (buttons, links, form fields, etc.) that goes beyond a generic statement.

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 explicitly states when to use this tool ('when you need to locate elements before performing actions with the act tool') and when not to use it ('DO NOT use this tool for extracting text content or data - use the extract tool instead'). It clearly differentiates from alternatives like 'extract' and 'act', providing strong guidance on tool selection.

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