Skip to main content
Glama

wait

Pauses execution for a specified duration to allow web pages to finish loading or rendering dynamic content, ensuring complete page elements appear in screenshots.

Instructions

Use this tool when a page appears to be loading or not fully rendered. Common scenarios include: when elements are missing from a screenshot that should be there, when a page looks incomplete or broken, when dynamic content is still loading, or when a previous action (like clicking a button) hasn't fully processed yet. Waits for a specified number of seconds (up to 10) to allow the page to finish loading or rendering.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
secondsYesNumber of seconds to wait (max 10). Start with a smaller value (2-3 seconds) and increase if needed.

Implementation Reference

  • The handler function for the "wait" tool. Validates the seconds parameter (0-10), sleeps for the specified duration using the sleep utility, and returns a success message.
    async function handleWait(_page: Page, args: any): Promise<CallToolResult> {
      const { seconds } = args;
      if (typeof seconds !== "number" || seconds < 0 || seconds > 10) {
        return {
          isError: true,
          content: [
            {
              type: "text",
              text: "Wait time must be a number between 0 and 10 seconds",
            },
          ],
        };
      }
    
      await sleep(seconds * 1000); // Reusing your sleep utility
      return {
        isError: false,
        content: [{ type: "text", text: `Waited ${seconds} second(s).` }],
      };
    }
  • The schema definition for the "wait" tool in the TOOLS array, defining the input schema with a required 'seconds' number parameter (0-10).
      name: "wait",
      description:
        "Use this tool when a page appears to be loading or not fully rendered. Common scenarios include: when elements are missing from a screenshot that should be there, when a page looks incomplete or broken, when dynamic content is still loading, or when a previous action (like clicking a button) hasn't fully processed yet. Waits for a specified number of seconds (up to 10) to allow the page to finish loading or rendering.",
      inputSchema: {
        type: "object",
        properties: {
          seconds: {
            type: "number",
            description:
              "Number of seconds to wait (max 10). Start with a smaller value (2-3 seconds) and increase if needed.",
            minimum: 0,
            maximum: 10,
          },
        },
        required: ["seconds"],
      },
    },
  • Helper utility function 'sleep' that pauses execution for a given number of milliseconds using setTimeout. Used by the wait handler.
    function sleep(ms: number): Promise<void> {
      return new Promise(resolve => setTimeout(resolve, ms));
    }
  • src/index.ts:937-939 (registration)
    Registration of the 'wait' tool handler in the main tool dispatcher switch statement within handleToolCall.
    case "wait":
      result = await handleWait(page, args);
      break;
  • src/index.ts:1068-1070 (registration)
    Server handler for ListToolsRequestSchema that returns the TOOLS array, which includes the 'wait' tool definition.
    server.setRequestHandler(ListToolsRequestSchema, async () => ({
      tools: TOOLS,
    }));
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: waiting for a specified duration (up to 10 seconds) to address loading issues. It adds context like common scenarios and a recommendation to start with smaller wait times, though it doesn't cover potential side effects like timeouts or performance impacts.

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 appropriately sized and front-loaded, starting with the primary use case followed by scenarios and parameter details. Every sentence earns its place by providing actionable information without redundancy, making it efficient and easy to parse.

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 low complexity (one parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and parameter semantics well. However, it could slightly improve by mentioning potential limitations or errors, but this is minor given the straightforward nature of a wait tool.

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 input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the parameter's purpose ('to allow the page to finish loading or rendering') and providing usage advice ('Start with a smaller value (2-3 seconds) and increase if needed'), which enhances understanding beyond the schema's technical details.

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 tool's purpose with specific verbs ('waits for a specified number of seconds') and resource ('to allow the page to finish loading or rendering'). It distinguishes from siblings by focusing on waiting rather than navigation, interaction, or content capture, making its role explicit and unique.

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 guidance on when to use this tool ('when a page appears to be loading or not fully rendered') with detailed scenarios (e.g., missing elements, incomplete pages, dynamic content loading). It implicitly suggests alternatives by listing sibling tools like click or navigate for other actions, though it doesn't explicitly name them as alternatives.

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/steel-dev/steel-mcp-server'

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