Nightshift
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| recall_incident_memoryA | Read what previous nights concluded about this dataset. Call this FIRST, before walking any lineage. If a previous incident already explains today's symptom, you can skip the investigation entirely. |
| recall_across_lineageA | Read Nightshift memory for several assets at once, e.g. a lineage path. |
| find_datasets_with_failure_modeA | Find every asset in the graph that already suffered a given failure mode. Failure modes are slugs such as |
| open_incidentB | Open an incident on an asset in DataHub, so the break is visible to humans. |
| resolve_incidentB | Resolve an incident with a message explaining what was actually done. |
| guard_columnA | Leave an assertion watching a column, so this break cannot recur silently. Call this after a fix. It is what turns one repaired incident into a permanent guarantee for everyone downstream. |
| remember_incidentA | Write tonight's conclusion into the graph, for humans and for the next agent. This is the last thing you do on any incident, and it is not optional. Write a conclusion, never a status: the next night reads this instead of starting from nothing. |
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 unique role in the incident lifecycle: recall memory, search failures, open/resolve incidents, guard columns, and write conclusions. No overlap in purpose or action.
All tool names follow a consistent snake_case verb_noun pattern (e.g., recall_incident_memory, open_incident, guard_column). No mixed conventions or vague verbs.
Seven tools is ideal for an incident response server: enough to cover the full workflow without redundancy or bloat.
The surface covers the full incident lifecycle from recall to prevention to memory. Minor gaps like updating an incident or listing open incidents exist, but the core flow is complete.