Skip to main content
Glama
enesjakozh
AgentsWorkingTogether

mcp-sleep

by AgentsWorkingTogether
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Sleep MCP 서버

대장간 배지

이 MCP 서버는 에이전트 흐름을 제어하기 위해 지정된 시간 동안 실행을 일시 중지합니다. 시간 지연을 도입하여 작업이 원하는 순서대로 실행되도록 자동화를 강화하세요. 작업 간 대기 시간이 필요한 워크플로 관리에 이상적입니다.

설정

설치

MCP 패키지 관리자 사용

대장간

Smithery를 통해 Claude Desktop용 Sleep MCP를 자동으로 설치하려면:

지엑스피1

mcp-get

mcp-get을 사용하여 Sleep MCP 서버를 설치할 수 있습니다.

npx @michaellatman/mcp-get@latest install mcp-sleep

필수 조건

MCP는 아직 매우 새롭고 계속 발전하고 있으므로 MCP 기본 사항을 익히고 실행하려면 MCP 설명서를 따르는 것이 좋습니다.

필요한 것:

구성

1. Claude Desktop 구성

OS에 따라 다음 파일을 만듭니다.

MacOS의 경우: ~/Library/Application\ Support/Claude/claude_desktop_config.json

Windows의 경우: %APPDATA%/Claude/claude_desktop_config.json

이 템플릿을 파일에 붙여넣으세요

{
    "mcpServers": {
        "mcp-sleep": {
            "command": "uvx",
            "args": [
                "mcp-sleep"
            ],
        }
    }
}

선택적으로 <MCP_SLEEP_TIMEOUT> 원하는 시간 제한(대기할 수 있는 최대 시간, 기본값 60초)으로 바꾸세요.

{
    "mcpServers": {
        "mcp-sleep": {
            "command": "uvx",
            "args": [
                "mcp-sleep"
            ],
            "env": {
                "MCP_SLEEP_TIMEOUT": "<MCP_SLEEP_TIMEOUT>"
            }
        }
    }
}

2. Claude Desktop을 다시 시작하세요

SSE 모드

또는 다음 명령을 실행하여 SSE 모드에서 MCP 서버를 실행할 수 있습니다.

uvx mcp-sleep --transport sse

이 모드는 SSE를 지원하는 MCP 클라이언트(웹 앱 등)와 통합하는 데 유용합니다.

Related MCP server: Treehole MCP Server

도구

  1. sleep

    • 에이전트의 흐름을 제어하기 위해 지정된 기간 동안 실행을 일시 중지합니다.

    • 입력:

      • seconds (숫자, 최대 시간 초과 구성 값): 계속 진행하라는 메시지를 표시하는 데 걸리는 시간(초)

    • 반환: {seconds} 후에 "{seconds}초 동안 기다린 후 작업을 계속할 수 있습니다."라는 문장이 표시됩니다. 최대 대기 시간보다 큰 대기 시간을 입력하면 "구성상 {ctx.sleep.config.timeout}초 이상 대기할 수 없습니다."라는 결과가 표시됩니다.

Claude Desktop과 함께 사용

Claude Desktop과 함께 사용하려면 claude_desktop_config.json 에 다음을 추가하세요.

도커

{
  "mcpServers": {
    "mcp-sleep": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "MCP_SLEEP_TIMEOUT",
        "mcp/sleep"
      ],
      "env": {
        "MCP_SLEEP_TIMEOUT": "<MCP_SLEEP_TIMEOUT>"
      }
    }
  }
}

개발

구성

로컬로 작업하는 경우 저장소 루트에 있는 .env 파일에 두 개의 환경 변수를 추가합니다.

MCP_SLEEP_TIMEOUT=

로컬 개발을 위해 Claude Desktop 구성을 업데이트하세요.

{
  "mcpServers": {
      "mcp-sleep_local": {
          "command": "uv",
          "args": [
              "run",
              "--directory",
              "/path/to/your/mcp-sleep",
              "run",
              "mcp-sleep"
          ]
      }
  }
}
"mcpServers": {
  "mcp-sleep": {
    "command": "uvx",
    "args": [
      "mcp-sleep"
    ]
  }
}

건축 및 출판

배포를 위해 패키지를 준비하려면:

  1. 종속성 동기화 및 잠금 파일 업데이트:

uv sync

  1. 패키지 배포 빌드:

uv build

이렇게 하면 dist/ 디렉토리에 소스와 휠 배포판이 생성됩니다.

  1. PyPI에 게시:

uv publish

참고: 환경 변수나 명령 플래그를 통해 PyPI 자격 증명을 설정해야 합니다.

  • 토큰: --token 또는 UV_PUBLISH_TOKEN

  • 또는 사용자 이름/비밀번호: --username / UV_PUBLISH_USERNAME 및 --password / UV_PUBLISH_PASSWORD

Docker 빌드:

docker build -t mcp/sleep -f Dockerfile .

디버깅

MCP 서버는 stdio를 통해 실행되므로 디버깅이 어려울 수 있습니다. 최상의 디버깅 환경을 위해서는 MCP Inspector 사용을 강력히 권장합니다.

다음 명령을 사용하여 npm 통해 MCP Inspector를 시작할 수 있습니다.

npx @modelcontextprotocol/inspector uv --directory /path/to/your/mcp-sleep run mcp-sleep

Inspector를 실행하면 브라우저에서 접근하여 디버깅을 시작할 수 있는 URL이 표시됩니다.

Available Tools

1 tool
sleepC

If you need to wait for a few seconds to continue with the task you are performing .

ParametersJSON Schema
NameRequiredDescriptionDefault
secondsYesseconds it will take me to tell you to continue.

TDQS

C2.9/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 full burden. It mentions waiting behavior but omits key details: whether it blocks execution, if it's synchronous/asynchronous, error handling, or side effects. The phrase 'tell you to continue' hints at notification but is ambiguous. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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

Conciseness4/5

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

The description is a single, efficient sentence that directly states the tool's function. It's appropriately sized for a simple tool, with no redundant or verbose phrasing. However, it could be more front-loaded by starting with the core action (e.g., 'Pauses execution for a specified duration').

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. It covers the basic purpose but lacks details on behavior, return values, or error cases. With no output schema, it should ideally hint at what happens after waiting (e.g., resumes task). It's complete enough for a simple tool but has room for improvement.

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

Parameters3/5

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

Schema description coverage is 100%, with the parameter 'seconds' well-documented in the schema (type, range, purpose). The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.

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

Purpose3/5

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

The description states the tool's purpose as waiting/pausing execution ('wait for a few seconds'), which is clear but somewhat vague. It doesn't specify what resource or system it operates on, and with no sibling tools, differentiation isn't needed. The description avoids tautology by explaining function rather than just restating the name.

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 provides implied usage context ('to continue with the task you are performing'), suggesting it's for pacing or timing in workflows. However, it lacks explicit guidance on when to use vs. alternatives (though none exist), prerequisites, or specific scenarios. The guidance is functional but minimal.

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 observedsleep
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored across 1 tool

Disambiguation5/5

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

Naming Consistency5/5

There is only one tool name, so it inherently follows a consistent pattern. The name 'sleep' is a simple verb that clearly describes the tool's function without any naming conflicts or inconsistencies.

Tool Count2/5

A single tool is too few for most practical server purposes, as it severely limits functionality and scope. While the tool 'sleep' might be useful in specific contexts, a server with only one tool typically feels incomplete and under-scoped for agent workflows.

Completeness1/5

The server's purpose appears to be time-based operations, but with only a 'sleep' tool, it is severely incomplete. There are obvious gaps, such as tools for scheduling, timing, or other time-related functions, making the surface inadequate for any meaningful domain coverage.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Wait Timer Server

    199-mcp
    A
    license
    A
    quality
    D
    maintenance
    Provides a simple 'wait' tool that introduces deliberate pauses into workflows executed by MCP clients, allowing time for asynchronous operations to complete before proceeding to the next step.
    1
    32 npm
    1
    MIT

  • Treehole MCP Server

    jeffkit
    A
    license
    B
    quality
    C
    maintenance
    Provides tools for AI agents to take timed rest breaks and vent their thoughts to receive emotional support during complex tasks. It enables developers to implement structured delays while offering a psychological sanctuary for simulated silicon-based life.
    2
    18 npm
    4
    MIT

  • LoopIn MCP Server

    nicholasemccormick
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to pause execution at critical decision points and request human review before proceeding. Provides tools for creating interrupts, polling for decisions, and managing approvals through a simple REST API interface.
    9 npm
    MIT

  • mcp-wait

    AaLexUser
    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.
    11 npm
    MIT