agent-bridge

Overview Schema Source Related Servers Discussions Admin

screen.press

screen_press

Presses a button or element in a running React Native/Expo app, then waits for the render. Use it to simulate taps and see how the app responds.

Instructions

Press a button, then wait for the render. target is a string (testID, label, placeholder or text) or an object that must match every key it sets: {testID, label, placeholder, text, at:[x,y], index}. Unknown keys are errors. {at:[x,y]} hits the smallest element covering that point, for icon-only buttons with no label. Several matches: add an index, either in the target or as a trailing {index:n} argument. Text with no handler of its own presses the nearest ancestor that has one, and the reply says via:"ancestor". Disabled elements are refused; {force:true} presses anyway, to see what the app does on tap. {scroll:true} scrolls an off-screen target into view first. With no onPress it sends the "activate" accessibility action, as a screen reader's double tap does (swipe-to-confirm buttons, sliders), and the reply says via:"accessibilityAction:activate". {action:"increment"} (or any name in the element's snapshot actions) sends that action instead. A Switch (native switch host or role switch, with onValueChange) is toggled with onValueChange(!value), not the row around it; reply via:"onValueChange". {long:true} long presses: onPressIn, onLongPress, onPressOut (never onPress); an error when there is no onLongPress, on the element or an ancestor. {scroll:true} also pages the largest vertical FlatList/SectionList/FlashList for a row it has not rendered yet (and scrolls back if it finds none; onEndReached may fire). A tap inside a react-native-gesture-handler GestureDetector cannot be pressed from here (its callbacks run on the UI thread): the error says so.

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_press"
  }
}

Input Schema

Name	Required	Description	Default
`args`	No	The tool's arguments, in order (each any JSON value). Leave out for none.
`full`	No	Return a result over 32 KB whole instead of a summary of its size and shape.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.2Nov 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: disabled elements are refused, force bypasses that, {scroll:true} may trigger onEndReached and scrolls back when nothing is found, long press never fires onPress, and a GestureDetector tap fails with an explanatory error. It also discloses the reply markers (via:"ancestor", via:"onValueChange", via:"accessibilityAction:activate") so the agent can verify what actually happened.

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

Conciseness3/5

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

Front-loaded correctly with the action first, and nearly every sentence carries distinct behavioral information. But it is a single dense run-on paragraph of roughly a dozen clauses with no separators, which makes the modifier flags (force, scroll, action, long) hard to scan; a short enumerated structure would have preserved the content at half the cognitive cost.

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 tool whose real complexity is dispatch resolution rather than its two schema parameters, the definition covers match resolution, ambiguity, ancestor fallback, accessibility-action fallback, switch handling, long press, virtualization paging, and failure modes. Since no output schema exists, it also names the reply markers, so an agent knows how to read the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is a generic args array plus a full flag and conveys essentially nothing about call shape; the description supplies the entire contract — target as string or object, the closed key set (testID, label, placeholder, text, at, index) with unknown keys erroring, the trailing {index:n} form, and each modifier flag's meaning. This is a case where the prose is the only real parameter documentation.

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?

Opens with a specific verb and resource plus the completion semantics: 'Press a button, then wait for the render.' It immediately distinguishes itself from siblings like screen_fill, screen_setValue and screen_scroll by being the tap-dispatch tool, and it goes on to define the selector model that makes the action addressable.

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 rich conditional guidance: use {at:[x,y]} for icon-only buttons with no label, add an index for ambiguous matches, {force:true} to probe disabled elements, {long:true} for long press, {action:...} for custom accessibility actions. It never names a sibling tool as the alternative (e.g. screen_scroll for plain scrolling, screen_fill for text entry), so routing between tools is left to inference.

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