Skip to main content
Glama
199-mcp

MCP Wait Timer Server

by 199-mcp

MCP 等待计时器服务器

提供简单wait工具的 MCP(模型上下文协议)服务器。

观看演示视频: https://www.youtube.com/watch?v= TaF_j9wrWVw

概述

该服务器公开了一个工具, wait ,旨在在 MCP 客户端(例如,Cline、Claude Desktop、Cursor)执行的工作流中引入刻意的暂停。

Related MCP server: mcp-sleep

问题解决了

MCP 客户端及其驱动的 AI 模型通常按顺序运行。执行命令或操作(例如 Web 请求、文件操作或 API 调用)后,模型可能会立即执行下一步。然而,某些操作需要更多时间才能完全完成其效果(例如,后台进程完成、JavaScript 执行后网页完全渲染、文件系统传播)。

由于模型无法始终可靠地检测这些异步效应何时完成,因此它可能会过早进行,从而导致后续步骤中出现错误或不正确的假设。

解决方案: wait工具

该服务器提供了一个wait工具,允许用户或 AI 提示明确指示客户端暂停指定的时长后再继续执行。这确保了与时间相关的操作有足够的时间完成。

工具: wait

  • **描述:**暂停执行指定的秒数。

  • 输入参数:

    • duration_seconds (数字,必需):等待的时长,以秒为单位。必须为正数。

用例

  • **Web 自动化:**确保动态内容加载或脚本在页面导航或元素交互后完成执行。

    Example Prompt: "Navigate to example.com, fill the login form, click submit, then wait for 5 seconds and capture a screenshot."
  • **命令行操作:**为后台任务、文件写入或由 shell 命令启动的服务启动留出时间。

    Example Prompt: "Run 'npm run build', wait for 15 seconds, then check if the 'dist/app.js' file exists."
  • **API 交互:**在 API 调用之间添加延迟以处理速率限制或等待异步作业完成。

  • **工作流调试:**在复杂任务期间插入暂停以观察特定点的系统状态。

安装和设置

此服务器需要 Node.js(版本 16 或更高版本)。

步骤 1:配置您的 MCP 客户端

在客户端配置文件的"mcpServers": {}对象中添加以下 JSON 块。请选择与您的客户端和操作系统对应的文件:

配置块:

    "wait-timer": {
      "command": "npx",
      "args": ["mcp-wait-timer"],
      "env": {},
      "disabled": false,
      "autoApprove": []
    }

客户端配置文件位置:

  • 克劳德桌面:

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

    • Linux: ~/.config/Claude/claude_desktop_config.json(路径可能略有不同)

  • VS Code 扩展(Cline /“Claude Code”):

    • macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

    • Windows: %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json

    • Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

  • 光标:

    • 全局: ~/.cursor/mcp.json

    • 项目特定:在项目文件夹中创建一个文件.cursor/mcp.json 。

  • 风帆冲浪:

    • ~/.codeium/windsurf/mcp_config.json

  • 其他客户:

    • 请参阅特定客户端的文档,了解其 MCP 配置文件的位置。上面“配置块”中显示的 JSON 结构通常可以正常工作。

第 2 步:重启客户端

添加配置块并保存文件后,请完全重启MCP 客户端应用程序以使更改生效。客户端首次启动服务器时,如果mcp-wait-timer包尚未缓存, npx将自动下载。

使用示例

安装并启用后,您可以指示您的 MCP 客户端:

"Please wait for 10 seconds before proceeding."

客户端的 AI 模型应该识别意图并使用duration_seconds: 10调用wait工具。

开发者

该工具是199 Longevity计划的一部分,该组织致力于拓展人类健康和长寿的前沿。

欲了解我们在生物技术领域的工作详情,请访问199.bio 。

项目贡献者:Boris Djordjevic

执照

该项目根据 MIT 许可证获得许可 - 有关详细信息,请参阅LICENSE文件。

Available Tools

1 tool
waitA

Waits for a specified duration in seconds.

ParametersJSON Schema
NameRequiredDescriptionDefault
duration_secondsYes

TDQS

A3.7/5.0
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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedwait

TDQS

A3.6/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility for ambiguity or overlap between tools. The tool 'wait' has a single, clear purpose that cannot be confused with any other tool in this set.

Naming Consistency5/5

The naming is trivially consistent as there is only one tool. The tool name 'wait' follows a simple verb pattern, and there are no other tools to create inconsistency or mixed conventions.

Tool Count2/5

A single tool is too few for most server purposes, making the server feel thin and limited in scope. While a timer server might logically have few tools, one tool is borderline minimal and may not cover all expected timer-related operations, such as cancelling or listing waits.

Completeness2/5

The tool set is severely incomplete for a timer server. It only provides a wait function, missing obvious operations like cancelling an active wait, checking wait status, or managing multiple timers, which are common in timer-related domains.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol (MCP) server that provides a simple sleep/wait tool, useful for adding delays between operations such as waiting between API calls or testing eventually consistent systems.
    1
    6 npm
    23
    ISC
  • A
    license
    B
    quality
    D
    maintenance
    A simple MCP server that provides waiting functionality to pause until other tasks finish, with progress reporting and support for CLI or HTTP server with SSE.
    1
    23 npm
    5
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides a wait tool for AI agents to pause execution until a time duration elapses or a process terminates, useful for polling and waiting for builds/deployments.
    10 npm
    MIT