fleetalert-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FLEETALERT_MCP_TIER | No | Highest tier of tool to register: read_only, proposes_action, executes_action. Tools above this tier are not registered at all and cannot be discovered by clients. | read_only |
| FLEETALERT_MCP_TOKENS | No | HTTP mode bearer tokens: client_id:tier:secret[,...], secrets 16+ chars. Required in HTTP mode unless anonymous access is allowed on loopback. | |
| FLEETALERT_MCP_PUBLIC_URL | No | Public URL of this server in HTTP mode (used for the protected-resource metadata). | http://host:port |
| FLEETALERT_MCP_API_BASE_URL | No | FleetAlert API base URL. | the live demo |
| FLEETALERT_MCP_ACTIONS_PER_HOUR | No | Rate limit per principal for tools above read_only. | 6 |
| FLEETALERT_MCP_CALLS_PER_MINUTE | No | Rate limit per principal, applied to every tool. | 30 |
| FLEETALERT_MCP_ALLOW_ANONYMOUS_HTTP | No | Run HTTP mode without tokens, loopback only. | false |
| FLEETALERT_MCP_UPSTREAM_TIMEOUT_SECONDS | No | Timeout in seconds for upstream FleetAlert API calls. | 10 |
| FLEETALERT_MCP_UPSTREAM_CALLS_PER_MINUTE | No | Rate limit across all principals for upstream API calls. | 120 |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_alertsA | List every demo alert with its machine, severity and current status. |
| get_alertA | One alert's current status and, once investigated, the proposed fix, the agent's confidence and its root-cause summary. For email- or detector-raised alerts, the inbound email or detection rule too. |
| get_traceA | The investigation history of an alert, one entry per round: entry point, outcome, proposed fix, model calls, tokens, cost, and the ordered steps (model calls, capability calls, guardrail decisions, human actions). Use get_raw_spans for full inputs and outputs. |
| get_raw_spansA | Raw trace spans for an alert, newest last, with full input and output. Large; prefer get_trace unless you need the detail. |
| get_usageA | Today's investigations and model spend against the demo's daily cost cap. When exhausted, action tools will be refused upstream. |
| get_activityB | Recent cross-alert activity: end states, guardrail decisions, human confirm/reject actions and proposals, newest first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| triage_alert | Review one alert's proposal and traces and advise the human. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| alerts_resource |
TDQS
Scored across 6 tools
The tools mostly target distinct needs: usage, alert listing, single alert summary, trace history, raw spans, and cross-alert activity. The main potential overlap is between get_trace and get_raw_spans, but the descriptions explicitly distinguish them by detail level and recommend get_trace by default.
All tools follow a clear verb_noun convention using get_ or list_ prefixes. The naming is predictable and readable throughout.
Six tools is well-scoped for an alert inspection/observability server. Each tool covers a distinct layer of information without excessive surface area.
Read-only inspection is well covered: alerts, investigation traces, raw spans, activity, and usage. However, the alert lifecycle includes statuses and human actions such as confirm/reject/resolve, but there are no action tools to mutate or progress an alert, which is a notable gap for the stated domain.