foreman
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NVIDIA_API_KEY | Yes | API key from https://build.nvidia.com |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_processed_videosA | List videos that have been processed and are available to query. |
| list_alertsA | List verified safety alerts for a processed video. Args: video_id: which processed video; omit if only one has been processed. hazard_type: optional filter, one of the taxonomy keys. min_severity: low, medium or high. Defaults to low, meaning everything. Returns confirmed alerts only. Rejected detections are available via
|
| list_rejected_detectionsA | List detections the verifier rejected, with the evidence it found missing. Useful for auditing whether the system is suppressing real hazards. A rejection that looks wrong here is the fastest signal that the taxonomy's evidence bar for that class is set incorrectly. |
| search_timelineA | Search the footage in natural language. Searches every analysed window, not just the ones that produced an alert, so it answers questions the hazard taxonomy does not cover: "someone carrying a long load past the racking", "the aisle by the loading door", "anyone on a phone". Args: query: what to look for, in plain language. video_id: which processed video; omit if only one has been processed. k: how many windows to return. |
| explain_alertA | Return the full evidence chain behind one alert. Gives the proposing model's claim, its confidence, the verifier's reasoning and the standard cited, so a supervisor can judge the alert rather than take it on trust. |
| shift_summaryB | Summarise a processed shift: volumes, alert mix, and what was filtered out. |
| hazard_taxonomyA | The hazard classes this system detects, with evidence bars and known failure modes. Read this before interpreting alerts: each class has a specific evidence standard, and knowing it is the difference between reading an alert and trusting it. |
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 7 tools
Each tool has a clear, non-overlapping purpose: listing videos, listing alerts, summarizing shifts, listing rejected detections, semantic search, explaining alert evidence, and exposing the taxonomy. There is no ambiguity about which tool to use for a given task.
Most tools follow a verb_noun pattern (list_processed_videos, list_alerts, list_rejected_detections, search_timeline, explain_alert), but shift_summary and hazard_taxonomy break the pattern by leading with a noun. The deviation is minor and the naming remains readable.
Seven tools is well-scoped for a video safety analysis and auditing system. Each tool covers a distinct query or audit function without redundancy, and the count is neither too thin nor too heavy.
The surface covers the core workflows: enumerating videos, querying alerts, auditing rejections, searching footage, and understanding alerts. A minor gap is the lack of a dedicated get_video detail tool, but list_processed_videos provides sufficient access for most use cases.