Skip to main content
Glama

element_exists

Read-only

Check if a page element exists using CSS, text, or testid selectors. Returns a simple exists or not found status to confirm presence before interaction.

Instructions

Quick check if an element exists on the page. Ultra-lightweight alternative to query_selector_all when you only need existence confirmation. Returns simple exists/not found status. Most common check before attempting interaction. Supports testid shortcuts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
selectorYesCSS selector, text selector, or testid shorthand (e.g., 'testid:submit-button', '#main')

Implementation Reference

  • The execute() method of ElementExistsTool class - the core logic. Uses createScopedLocator to find elements, counts matches, and returns formatted existence status (✓ exists or ✗ not found). For found elements, it extracts tag/id/class info for a concise summary.
    async execute(args: ElementExistsArgs, context: ToolContext): Promise<ToolResponse> {
      return this.safeExecute(context, async (page) => {
        const locator = await this.createScopedLocator(page, args.selector);
        const count = await locator.count();
    
        if (count === 0) {
          return {
            content: [
              {
                type: 'text',
                text: `✗ not found: ${args.selector}`
              }
            ],
            isError: false
          };
        }
    
        // Get element info for better output
        const element = locator.first();
        const elementInfo = await element.evaluate((el) => {
          const tag = el.tagName.toLowerCase();
          const parts: string[] = [tag];
    
          if (el.id) parts.push(`#${el.id}`);
    
          if (el.className && typeof el.className === 'string') {
            const classes = el.className.split(' ').filter(c => c).slice(0, 2);
            if (classes.length) {
              classes.forEach(c => parts.push(`.${c}`));
            }
          }
    
          return parts.join('');
        }).catch(() => args.selector);
    
        if (count === 1) {
          return {
            content: [
              {
                type: 'text',
                text: `✓ exists: <${elementInfo}>`
              }
            ],
            isError: false
          };
        }
    
        // Multiple matches
        return {
          content: [
            {
              type: 'text',
              text: `✓ exists: <${elementInfo}> (${count} matches)`
              }
            ],
          isError: false
          };
      });
    }
  • Input schema for element_exists tool: requires a 'selector' string (CSS selector, text selector, or testid shorthand).
      inputSchema: {
        type: "object",
        properties: {
          selector: {
            type: "string",
            description: "CSS selector, text selector, or testid shorthand (e.g., 'testid:submit-button', '#main')"
          }
        },
        required: ["selector"],
      },
    };
  • Registration of ElementExistsTool in the browser tools registry (line 86), alongside other inspection tools.
    ElementExistsTool,
  • TypeScript interface ElementExistsArgs defining the 'selector' string argument.
    export interface ElementExistsArgs {
      selector: string;
    }
  • Evaluation helper that suggests using element_exists when the user writes querySelector !== null checks.
    if (scriptLower.match(/\!=\s*null|\!==\s*null/) && scriptLower.match(/queryselector/)) {
      suggestions.push({ key: 'exists', line: '✓ element_exists — boolean + summary (vs querySelector !== null)' });
    }
Behavior4/5

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

Annotations already declare readOnlyHint=true. Description adds context: 'ultra-lightweight', 'returns simple exists/not found status', and 'supports testid shortcuts', which are beyond the annotations. No contradictions.

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?

Four concise sentences, all earning their place. Front-loaded with core purpose. No fluff.

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?

For a simple tool with one parameter and no output schema, description covers purpose, alternatives, return format, and common use case. Highly 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 coverage is 100% with detailed description. Description repeats the same info but adds examples like 'testid:submit-button'. Baseline 3 is appropriate as description adds marginal value.

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?

Clearly states verb 'check' and resource 'element existence'. Distinguishes from sibling 'query_selector_all' by labeling itself 'ultra-lightweight'. Mentions testid shortcuts, adding specificity.

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?

Explicitly says it's an alternative to query_selector_all when only existence confirmation is needed, and that it's a common check before interaction. Provides clear when-to-use guidance.

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/antonzherdev/mcp-web-inspector'

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