await-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| await_commandA | Block agent execution until a shell command exits with code 0 (success). The command is polled at regular intervals. The agent is stuck on this call until done. Exit code convention:
Use this to wait for long-running operations: cloud builds, CI/CD, deployments, etc. Example: await_command(command="curl -sf https://ci.example.com/build/123/status | grep -q done", interval_seconds=30) |
| await_urlA | Block agent execution until a URL returns the expected HTTP status code. Optionally check that the response body contains a specific string. The agent is stuck on this call until the condition is met or timeout. Example: await_url(url="http://localhost:3000/health", expected_status=200) |
| await_fileA | Block agent execution until a file exists and optionally contains a specific string. Useful for file-based signaling between processes (e.g., build status files). Example: await_file(path="/tmp/build-status", contains="SUCCESS") |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool targets a distinct condition type: shell command, URL, or file. The purpose of each is clear, and there is no meaningful overlap in their intended use cases. An agent can easily select the right tool based on the resource it needs to wait on.
All tools follow the consistent verb_noun pattern of 'await_' followed by the target resource (command, url, file). This makes the tool names predictable and easy to remember. The naming convention is uniform throughout the set.
With three tools, the server is well-scoped for its purpose of providing wait-for-condition primitives. Each tool covers a distinct and common category of waiting (shell, HTTP, file), so the count feels neither thin nor excessive for the domain.
The three tools cover the primary methods for blocking on external signals: command exit status, URL availability/response, and file presence/content. This set provides a solid foundation for waiting on common CI/CD, deployment, and build scenarios. While a generic 'sleep' tool is absent, the command-based approach can handle arbitrary delays, making the surface reasonably complete.