mcp-banshee
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 |
|---|---|
| dispatch_alertB | Notify the household by dispatching a mythical creature. Severity picks the courier; stack summons more of them. |
| list_couriersC | Return the current roster of mythical dispatchers. |
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 2 tools
The two tools have clearly distinct purposes: dispatch_alert performs an action (notify) while list_couriers is a read-only lookup. There is no plausible way to confuse them, and the descriptions reinforce the boundary.
Both names follow a clean verb_noun pattern (dispatch_alert, list_couriers). The convention is predictable and unambiguous.
Two tools is thin for a functional server; the surface is essentially a single action plus a supporting lookup. It is not egregiously wrong for a whimsical notification utility, but it borders on under-scoped.
Core dispatch is covered, but there is no way to manage the courier roster (add/remove/configure), no delivery status or history, and no visibility into what severity values exist. Agents can perform the primary action but hit dead ends for lifecycle management.