Skip to main content
Glama
199-mcp

MCP Wait Timer Server

by 199-mcp

wait

Introduces a timed pause into workflows by waiting for a specified number of seconds, ensuring asynchronous operations complete before proceeding to the next step.

Instructions

Waits for a specified duration in seconds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
duration_secondsYes

Implementation Reference

  • The handler function that executes the 'wait' tool logic: logs start, waits using setTimeout for the specified duration in seconds, logs finish, and returns success content. Handles errors similarly.
    async function waitHandler(args: z.infer<typeof waitInputSchema>): Promise<CallToolResult> {
      const { duration_seconds } = args;
      try {
        console.error(`[mcp-wait-timer] Waiting for ${duration_seconds} seconds...`);
        await new Promise(resolve => setTimeout(resolve, duration_seconds * 1000));
        console.error(`[mcp-wait-timer] Wait finished.`);
        return {
          isError: false,
          content: [{ type: 'text', text: `Successfully waited for ${duration_seconds} seconds.` }],
        };
      } catch (error: any) {
        console.error(`[mcp-wait-timer] Error during wait: ${error.message}`);
        // Ensure error responses also conform to CallToolResult
        return {
          isError: true,
          content: [{ type: 'text', text: `Error waiting: ${error.message}` }],
        };
      }
    }
  • Zod schema definition for input validation of the 'wait' tool, defining duration_seconds as a positive number.
    const waitInputSchemaShape = {
      duration_seconds: z.coerce.number().positive().describe('The number of seconds to wait'), // Use coerce.number()
    };
    const waitInputSchema = z.object(waitInputSchemaShape);
  • src/index.ts:43-51 (registration)
    Tool registration object defining the 'wait' tool with name, description, and input schema shape.
    const WAIT_TOOL: Tool = {
      name: 'wait',
      description: 'Waits for a specified duration in seconds.',
      inputSchema: {
        type: 'object',
        properties: waitInputSchemaShape,
        required: ['duration_seconds'],
      },
    };
  • src/index.ts:63-65 (registration)
    Registers the 'wait' tool (WAIT_TOOL) in the MCP server's list tools response handler.
    server.setRequestHandler(ListToolsRequestSchema, async () => ({
      tools: [WAIT_TOOL],
    }));
  • src/index.ts:67-79 (registration)
    Registers the call tool handler that dispatches to waitHandler if tool name is 'wait', including input validation.
    server.setRequestHandler(CallToolRequestSchema, async (request) => {
      if (request.params.name === WAIT_TOOL.name) {
        const parseResult = waitInputSchema.safeParse(request.params.arguments);
        if (!parseResult.success) {
          throw new McpError(
            ErrorCode.InvalidParams,
            `Invalid arguments for tool ${WAIT_TOOL.name}: ${parseResult.error.message}`
          );
        }
        return waitHandler(parseResult.data);
      }
      throw new McpError(ErrorCode.MethodNotFound, `Unknown tool: ${request.params.name}`);
    });
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('waits') but does not explain how the wait is implemented (e.g., blocking vs. non-blocking), potential side effects, or error handling. This leaves gaps in understanding the tool's behavior beyond the basic action.

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 a single, clear sentence that efficiently conveys the tool's function without unnecessary details. It is front-loaded and wastes no words, making it easy to understand at a glance.

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 tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but lacks depth. It covers the basic action but does not address behavioral aspects like implementation details or error scenarios, which could be important for a wait function in some contexts.

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 description adds meaning by specifying that the parameter is for 'duration in seconds,' which clarifies the unit and purpose beyond the schema's description ('The number of seconds to wait'). With 0% schema description coverage, the description compensates well by providing essential context, though it could note the minimum value constraint from the schema.

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 a specific verb ('waits') and resource ('duration in seconds'), making it immediately understandable. It distinguishes itself by focusing solely on time-based waiting functionality, which is straightforward given there are no sibling tools to differentiate from.

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

Usage Guidelines3/5

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

The description implies usage for delaying execution by a specified time, but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. With no sibling tools, the context is limited, but it lacks details on scenarios where waiting is appropriate or any constraints.

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

Related 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/199-mcp/mcp-wait-timer'

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