Skip to main content
Glama

charlotte_find

Search for page elements using filters like text, role, type, proximity, or CSS selector, and receive stable element IDs for automating interactions.

Instructions

Search for elements matching criteria. Filters interactive elements by text, role, type, or spatial proximity. Use the selector parameter to find DOM elements by CSS selector — this reaches elements not in the accessibility tree (custom widgets, non-semantic divs). Selector results return Charlotte element IDs usable with click, hover, drag, etc.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nearNoElement ID — find elements spatially near this one (within ~200px)
roleNoARIA role filter
textNoText content to search for (case-insensitive substring match)
typeNoInteractive element type filter (button, link, text_input, select, checkbox, etc.)
withinNoElement ID — find elements geometrically contained within this one's bounds
selectorNoCSS selector to query the DOM directly. Returns elements that may not be in the accessibility tree. Results include durable Charlotte element IDs (dom-…) that remain valid across subsequent renders and interactions, and work with fill_form; they are re-resolved against the live DOM by re-running the selector.
output_fileNoWrite the full match results to this file path instead of returning them inline. Relative paths resolve against output_dir (see charlotte_configure). Returns only a confirmation with the file path and size. Use for broad selectors (e.g. 'div', '*') that match many elements.
Behavior4/5

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

With no annotations, the description carries full burden and discloses important behaviors: selector reaches non-accessibility-tree elements, results return durable Charlotte element IDs re-resolved against the live DOM, and output_file writes to a file with a confirmation. It omits details on behavior when no filters are provided or whether hidden elements are included, leaving minor gaps.

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 well-structured: lead purpose statement, filter list, selector explanation, then output_file behavior. Every clause adds functional detail without redundancy or fluff.

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?

The description covers the main search use case, the unique selector capability, and output_file output, but does not specify the return format for inline results or behavior when no criteria are supplied. This is a minor gap given the tool's simplicity.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema for selector (durable IDs, re-resolution, works with fill_form) and output_file (confirmation with path and size, use for broad selectors), justifying a score above baseline.

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 'Search for elements matching criteria' with specific filters (text, role, type, spatial proximity) and highlights the selector parameter for DOM access. This distinguishes it from sibling action tools like click, type, and navigate by focusing on search/find.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly recommends using the selector parameter to find elements not in the accessibility tree, providing clear contextual guidance. However, it does not explicitly state when not to use the tool or compare it to alternatives, so it stops short of full exclusionary usage advice.

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/TickTockBent/charlotte'

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