mcp-progress
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| notifyB | Display a notification to the user |
| start_progressB | Start tracking progress for a long-running operation |
| update_progressC | Update progress for an ongoing operation |
| complete_progressB | Mark a progress operation as complete |
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 4 tools
Each tool has a clearly distinct role: notify sends a user notification, while start/update/complete handle the lifecycle of a progress operation. There is no overlap or ambiguity between them.
Three tools follow the verb_noun pattern (start_progress, update_progress, complete_progress), but notify is a bare verb without an object. This is a minor deviation from an otherwise consistent naming scheme.
Four tools is well-scoped for a progress-tracking server. Each tool serves a distinct purpose in the workflow, and the count feels neither too thin nor overloaded.
The progress lifecycle (start, update, complete) is covered, with an additional notify capability. A possible gap is the lack of an explicit cancel/abort operation, but the core workflow is complete enough for most use cases.