MCP-Pushover Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NODE_ENV | No | Node environment setting | production |
| LOG_LEVEL | No | Logging level for the server | info |
| RETRY_MAX_ATTEMPTS | No | Maximum number of retry attempts | 3 |
| RETRY_INITIAL_DELAY | No | Initial delay in milliseconds before retrying | 1000 |
| PUSHOVER_DEFAULT_USER | No | Your Pushover user key | |
| PUSHOVER_DEFAULT_TOKEN | No | Your Pushover application API token |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pushover_send_messageC | Send a notification via Pushover |
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 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools, as there are no other tools to confuse it with. The single tool's purpose is clearly defined and distinct by default.
The single tool name 'pushover_send_message' follows a consistent verb_noun pattern, and with only one tool, there is no inconsistency to evaluate. The naming is clear and predictable.
A single tool is too few for a server named 'MCP-Pushover Bridge', which implies a bridge to the Pushover service. While sending messages is a core function, typical notification services might include additional operations like checking message status or managing user settings, making this feel thin and under-scoped.
The tool surface is severely incomplete for a Pushover bridge. It only covers sending messages, missing obvious operations such as checking message delivery status, retrieving user information, or handling priority settings, which are common in notification APIs and could lead to agent failures in broader workflows.