Skip to main content
Glama

assert_element_exists

Verify UI element presence on Android screens for test assertions and conditional logic. Returns true/false without throwing errors when elements are found or missing.

Instructions

Check whether a UI element exists on the current screen. Returns true/false without throwing an error. Useful for test assertions and conditional logic.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
selectorYesElement selector to check
device_idNoDevice serial number

Implementation Reference

  • The implementation of the assertElementExists function, which attempts to find an element using findElement and returns its existence status.
    export async function assertElementExists(
      selector: ElementSelector,
      deviceId?: string
    ): Promise<{ exists: boolean; element?: FoundElement }> {
      try {
        const element = await findElement(selector, deviceId);
        return { exists: true, element };
      } catch {
        return { exists: false };
      }
    }
  • The ElementSelector interface defining the valid parameters for identifying UI elements.
    export interface ElementSelector {
      text?: string;
      textContains?: string;
      resourceId?: string;
      className?: string;
      contentDesc?: string;
      contentDescContains?: string;
      clickable?: boolean;
      enabled?: boolean;
      packageName?: string;
    }
  • The registration/handler call site within the MCP tools controller where the 'assert_element_exists' tool is invoked.
    'assert_element_exists',
    {
      description: 'Check whether a UI element exists on the current screen. Returns true/false without throwing an error. Useful for test assertions and conditional logic.',
      inputSchema: {
        selector: selectorSchema.describe('Element selector to check'),
        device_id: z.string().optional().describe('Device serial number'),
      },
    },
    async ({ selector, device_id }) => {
      return await metrics.measure('assert_element_exists', device_id || 'default', async () => {
        const result = await assertElementExists(selector as ElementSelector, device_id);
        return {
          content: [{
            type: 'text' as const,
            text: JSON.stringify({
              success: true,
              exists: result.exists,
              element: result.element || null,
            }, null, 2),
          }],
Behavior4/5

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

No annotations provided, so description carries full burden. It successfully discloses critical behavioral traits: boolean return values ('true/false') and error safety ('without throwing an error'). Lacks details on timeout behavior or performance characteristics, but covers the essential safety profile for an assertion tool.

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?

Three sentences, each earning its place: purpose declaration, return behavior, and use case guidance. Front-loaded with the core action, zero redundancy, and no tautology. Efficiently avoids repeating the 10 selector sub-properties already defined in the schema.

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 complex nested selector schema with 10 properties, the description appropriately focuses on behavioral semantics rather than parameter enumeration. It compensates for the missing output schema by specifying the boolean return type. Could mention timeout behavior or device_id default handling, but otherwise 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 description coverage is 100%, with all selector options and device_id fully documented in the schema. The description references 'selector' and 'current screen' but does not add semantic meaning beyond the structured schema, which is appropriate given the comprehensive schema coverage establishes the 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 states the specific action ('Check'), resource ('UI element'), and scope ('on the current screen'). It effectively distinguishes from siblings like 'find_element' by emphasizing 'Returns true/false without throwing an error,' signaling this is a safe boolean check rather than a retrieval operation that might error on missing elements.

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?

Provides clear context with 'Useful for test assertions and conditional logic,' indicating appropriate use cases. Implicitly differentiates from 'find_element' via the 'without throwing an error' clause, though it could explicitly name alternatives like 'use find_element if you need element details.'

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/divineDev-dotcom/android_mcp'

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