Skip to main content
Glama
microsoft

Playwright MCP Server

Official
by microsoft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

browser_find

Read-only

Search the current page's accessibility snapshot for text or regex to locate elements and their refs without capturing the full tree. Returns matching nodes with surrounding context and paths.

Instructions

Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoPlain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both.
regexNoRegular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both.
filenameNoSave results to a file instead of returning them in the response. Relative file names are resolved against the workspace root.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.0.83
    • addedInput schema / properties / filename
      Added value: +{
+  "description": "Save results to a file instead of returning them in the response. Relative file names are resolved against the workspace root.",
+  "type": "string"
+}
  2. Addedv0.0.78

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover readOnly/non-destructive/openWorld, so the bar is lower. The description adds valuable behavioral context the annotations don't: matching nodes are returned with surrounding context snippets under their tree path, which sets expectations about result shape and relative cost.

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

Conciseness4/5

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

A single dense sentence, front-loaded with what it searches and what it returns. It is efficient, though the third clause (cost comparison) is slightly compressed and could be its own sentence for readability.

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?

No output schema, but the description explains the return values (matching nodes, context snippets, tree paths), which is the key missing piece. For a read-only find tool with full annotation and schema coverage, this is essentially 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%, so the schema fully documents text, regex, and filename including mutual exclusivity and case sensitivity rules. The description only restates 'text or a regular expression' and adds no syntax detail beyond the schema, so baseline 3 applies.

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?

States a specific verb (search) and resource (accessibility snapshot of the current page) and even describes the return shape. It implicitly distinguishes itself from browser_snapshot by framing itself as the cheaper alternative for locating an element.

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?

Clearly indicates the use case: use this when you only need to locate an element and its ref rather than capture the whole snapshot. The alternative (full snapshot) is described by function but not named explicitly, so routing is clear but not fully spelled out.

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

Deploy Server

Other Tools