Skip to main content
Glama

tauri_webview_find_element

Read-only

Locate DOM elements in Tauri app webviews for UI automation and debugging. Specify selectors to identify elements during testing sessions.

Instructions

[Tauri Apps Only] Find DOM elements in a running Tauri app's webview. Requires active tauri_driver_session. Targets the only connected app, or the default app if multiple are connected. Specify appIdentifier (port or bundle ID) to target a specific app. For browser pages or documentation sites, use Chrome DevTools MCP instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
windowIdNoWindow label to target (defaults to "main")
appIdentifierNoApp port or bundle ID to target. Defaults to the only connected app or the default app if multiple are connected.
selectorYes
strategyNocss

Implementation Reference

  • Core handler function 'findElement' that constructs the script parameters and executes the find-element script in the target Tauri webview window.
    export interface FindElementOptions {
       selector: string;
       strategy: string;
       windowId?: string;
       appIdentifier?: string | number;
    }
    
    /**
     * Find an element using various selector strategies.
     */
    export async function findElement(options: FindElementOptions): Promise<string> {
       const { selector, strategy, windowId, appIdentifier } = options;
    
       const script = buildScript(SCRIPTS.findElement, { selector, strategy });
    
       try {
          return await executeInWebview(script, windowId, appIdentifier);
       } catch(error: unknown) {
          const message = error instanceof Error ? error.message : String(error);
    
          throw new Error(`Find element failed: ${message}`);
       }
    }
  • Zod input schema validation for the tool parameters: selector (string) and strategy (css|xpath|text, default css), extending shared WindowTargetSchema.
    export const FindElementSchema = WindowTargetSchema.extend({
       selector: z.string(),
       strategy: z.enum([ 'css', 'xpath', 'text' ]).default('css'),
    });
  • Tool registration in the central TOOLS array, defining name, description, category, schema reference, annotations, and thin wrapper handler that parses input and delegates to findElement implementation.
    {
       name: 'tauri_webview_find_element',
       description:
          '[Tauri Apps Only] Find DOM elements in a running Tauri app\'s webview. ' +
          'Requires active tauri_driver_session. ' +
          MULTI_APP_DESC + ' ' +
          'For browser pages or documentation sites, use Chrome DevTools MCP instead.',
       category: TOOL_CATEGORIES.UI_AUTOMATION,
       schema: FindElementSchema,
       annotations: {
          title: 'Find Element in Tauri Webview',
          readOnlyHint: true,
          openWorldHint: false,
       },
       handler: async (args) => {
          const parsed = FindElementSchema.parse(args);
    
          return await findElement({
             selector: parsed.selector,
             strategy: parsed.strategy,
             windowId: parsed.windowId,
             appIdentifier: parsed.appIdentifier,
          });
       },
    },
  • Injected JavaScript IIFE that implements the element search logic: CSS querySelector, XPath via document.evaluate, or text-based XPath. Returns truncated outerHTML on success or 'not found'.
    /**
     * Find an element using various selector strategies
     *
     * @param {Object} params
     * @param {string} params.selector - Element selector
     * @param {string} params.strategy - Selector strategy: 'css', 'xpath', or 'text'
     */
    (function(params) {
       const { selector, strategy } = params;
       let element;
    
       if (strategy === 'text') {
          // Find element containing text
          const xpath = "//*[contains(text(), '" + selector + "')]";
          const result = document.evaluate(
             xpath,
             document,
             null,
             XPathResult.FIRST_ORDERED_NODE_TYPE,
             null
          );
          element = result.singleNodeValue;
       } else if (strategy === 'xpath') {
          // XPath selector
          const result = document.evaluate(
             selector,
             document,
             null,
             XPathResult.FIRST_ORDERED_NODE_TYPE,
             null
          );
          element = result.singleNodeValue;
       } else {
          // CSS selector (default)
          element = document.querySelector(selector);
       }
    
       if (element) {
          const outerHTML = element.outerHTML;
          // Truncate very long HTML to avoid overwhelming output
          const truncated = outerHTML.length > 5000
             ? outerHTML.substring(0, 5000) + '...'
             : outerHTML;
          return 'Found element: ' + truncated;
       }
    
       return 'Element not found';
    })
Behavior4/5

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

Annotations provide readOnlyHint=true and openWorldHint=false, but the description adds valuable behavioral context beyond this. It explains the prerequisite of an active tauri_driver_session, clarifies targeting behavior (defaults to only connected app or default app), and mentions the need to specify appIdentifier for specific targeting. This provides operational context that annotations alone don't cover, though it doesn't describe return format or error behavior.

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 efficiently structured with four sentences that each serve a distinct purpose: scope limitation, prerequisite, targeting behavior, and alternative tool. There's no wasted language, and the most critical information (Tauri-only scope and prerequisite) comes first. The structure is logical and appropriately sized for the tool's complexity.

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 (4 parameters, no output schema, annotations present), the description provides good contextual coverage. It explains the tool's scope, prerequisites, targeting behavior, and alternatives. The main gap is lack of information about return values or error cases, but with annotations covering the safety profile and the description covering operational context, it's reasonably complete for agent use.

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?

With 50% schema description coverage (2 of 4 parameters have descriptions), the description adds some value by explaining the appIdentifier parameter's purpose and default behavior. However, it doesn't provide additional context for the selector parameter (which is required but undocumented in schema) or the strategy parameter beyond what the enum provides. The description compensates partially but not fully for the schema coverage gap.

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 specific action ('Find DOM elements') on a specific resource ('running Tauri app's webview'). It distinguishes from sibling tools by specifying this is for Tauri apps only and mentions an alternative for browser pages (Chrome DevTools MCP). The verb+resource combination is precise and unambiguous.

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 provides explicit usage guidelines: it specifies when to use this tool ('Tauri Apps Only'), when not to use it ('For browser pages or documentation sites, use Chrome DevTools MCP instead'), and prerequisites ('Requires active tauri_driver_session'). It also explains targeting behavior for single vs. multiple connected apps, giving clear context for when this tool is appropriate.

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/hypothesi/mcp-server-tauri'

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