Skip to main content
Glama

find_elements

Locate elements matching a selector and return structured data—count, tag names, text, and optional HTML—to inspect page content or verify matches.

Instructions

Find matching elements and return structured element information.

Use this tool when you need to discover how many elements match a selector, inspect their text/tag names, or inspect the HTML of multiple matches.

This tool resolves element handles immediately into ordinary JSON-like dictionaries. It does not return live SeleniumBase element objects.

Args: selector: CSS selector, or a SeleniumBase selector that can match visible text. Examples include "button", ".login-link", or 'a:contains("Sign in")'. timeout: Maximum number of seconds to wait for matching elements to be found. (Defaults to 0.5 seconds.) include_html: If True, include each matching element's outer HTML. If False, return only tag name and text. (Defaults to False.)

Returns: A dictionary containing: - count: Number of matching elements found. - matches: A list of element dictionaries containing tag_name and text, plus html when include_html=True. If there are no matching elements, returns an empty dictionary.

Tool selection: - Need structured information about matching elements -> use find_elements. - Need the visible text/HTML of a page or a single element -> use get_content. - Need to click one of several matches -> use click with nth. - Need to know whether an element is present/visible -> use check_condition.

Note: Element handles cannot be persisted across MCP calls. If you find elements and then need to act on one, resolve it again with the appropriate interaction tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeoutNo
selectorYes
include_htmlNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv4.53.7
    • removedInput schema / properties / timeout / anyOf
      Removed value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • changedInput schema / properties / timeout / default
      Previous value: -7New value: +0.5
    • addedInput schema / properties / timeout / type
      Added value: +"number"
  2. Changed1 schema field changedv4.53.2
    • changedInput schema / properties / timeout / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "type": "integer"
      +  },
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  3. Addedv1.0.1

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden. It clearly discloses that element handles resolve immediately into JSON-like dictionaries rather than live SeleniumBase objects, that handles cannot persist across MCP calls, and that no matches yield an empty dictionary. These are non-obvious traits an agent must know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a concrete purpose, then organizes content into Args, Returns, Tool selection, and Note. Each section adds distinct value—parameter details, return shape, alternatives, and a critical persistence caveat—without filler or redundancy.

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

Completeness5/5

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

The description is fully self-contained despite missing annotations and schema descriptions. It covers purpose, when to use, full parameter semantics, return structure including the empty-dictionary edge case, behavioral caveats, and sibling routing. Nothing an agent needs to correctly select and invoke the tool is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates. It explains selector syntax with concrete examples, gives the timeout default and behavior, and describes exactly how include_html alters the output. Every parameter is meaningfully defined beyond its name and type.

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 first sentence states a specific verb (find) and resource (matching elements) with a clear outcome (structured element information). The Tool selection section explicitly distinguishes it from get_content, click, and check_condition, so an agent can immediately tell which tool to use.

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 'Tool selection' section explicitly lists when to use find_elements (counting matches, inspecting text/tag names, or HTML of multiple matches) and routes to alternatives for other needs. This leaves no ambiguity about when to prefer another sibling.

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

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/seleniumbase/SeleniumBase'

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