devtools-fleet-mcp

Overview Schema Source Related Servers Discussions Admin

wait_for

Read-only

Wait for the specified text to appear on the selected page. By default, hidden text is also matched. Set visible to true to wait until the matched text is visible.

Instructions

Wait for the specified text to appear on the selected page. By default, hidden text is also matched. Set visible to true to wait until the matched text is visible.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pageId": "<pageId>",
      "text": "<text>"
    },
    "name": "wait_for"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	Non-empty list of texts. Resolves when any value appears on the page.
`pageId`	Yes	Targets a specific page by ID.
`timeout`	No	Maximum wait time in milliseconds. If set to 0, the default timeout will be used.
`visible`	No	If true, wait until the matching text is visible. By default, hidden text also counts.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Oct 23, 2026

changedInput schema / additionalProperties
```
Previous value: -{}New value: +false
```

addedInput schema / properties / visible

Added value: +{
+  "default": false,
+  "description": "If true, wait until the matching text is visible. By default, hidden text also counts.",
+  "type": "boolean"
+}

First observedv0.1.0Oct 1, 2026

TDQS

A3.6/5.0

Behavior4/5

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

The description provides crucial behavioral context that goes beyond the basic annotation (readOnlyHint). It specifically highlights the default matching behavior (hidden text is matched) and explains how to override this using the 'visible' parameter, which is key to correct tool invocation.

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 exceptionally concise, uses a logical two-sentence structure, and places the most important behavioral detail (default matching) immediately in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity (4 parameters, timeout handling, visibility logic), the description is sufficient to use the tool, but it lacks high-level contextual guidance on expected latency or failure modes typical of browser polling tools.

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?

Although the schema is 100% covered, the description adds semantic value by summarizing the behavior of the 'visible' flag and explaining the logic of the 'text' array (resolves when any value appears), thus helping the agent understand the parameters' effects.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: waiting for specific text to appear on a page. While clear, it is a standard polling/wait action, lacking specific context of *why* this is distinct from other actions like 'type_text' or 'click'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There are no explicit usage guidelines or context provided regarding when an agent should choose this wait action over other sibling tools. It describes what the tool does, not why the agent should use it.

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