Skip to main content
Glama
Sign In
agent-bridge

agent-bridge

by avas-app
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

screen.findText

screen_findText

Finds text on a React Native/Expo app screen by substring or exact match, reports whether matches are visible or hidden, and returns near misses for failed searches.

Instructions

Find text on screen (substring, or exact with {exact:true}) and whether each match is on screen. Searches the same joined text screen.snapshot shows (nested Text concatenated) and accessibility labels; {labels:false} searches text only. Each match says which field matched; a miss lists near misses. Ignores screens the user can't reach (unfocused tabs and stack screens, under a modal); hidden counts matches there.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "screen_findText"
  }
}

Input Schema

NameRequiredDescriptionDefault
argsNoThe tool's arguments, in order (each any JSON value). Leave out for none.
fullNoReturn a result over 32 KB whole instead of a summary of its size and shape.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it discloses default inclusion of accessibility labels, nested Text concatenation, that each match reports which field matched, that a miss returns near misses, and that unreachable screens (unfocused tabs, stack screens under a modal) are ignored unless `hidden` is used.

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?

Front-loaded with purpose and then layered with scoping and edge-case behavior; nearly every clause adds information. The brace-notation and semicolon-heavy packing make it dense to parse, but there is little outright waste.

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?

For a two-parameter, no-annotation, no-output-schema tool, the description covers what is searched, what is excluded, what a hit and a miss look like, and how large results are truncated. The exact return shape (field names, whether positions/coordinates are included) is left implicit, which is the main remaining gap.

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?

The schema documents only a generic `args` array and `full`, so the meaningful option semantics ({exact:true}, {labels:false}, `hidden`, and the 32 KB `full` override) exist only in the description — a substantial addition. It stops short of stating argument order/position explicitly, leaving some ambiguity about how the named options map into the positional array.

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 and resource ('Find text on screen') plus the return semantics ('whether each match is on screen'). It also anchors itself against a sibling by saying it searches the same joined text 'screen.snapshot shows', so an agent can distinguish it from screen_snapshot without opening either schema.

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?

Gives clear context for use: it searches the snapshot's joined text plus accessibility labels, and {labels:false} narrows to text only. It does not explicitly route to alternatives (e.g., screen_waitFor for waiting), but the relationship to screen_snapshot is 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