NitroWatch
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port when transport is 'http' or 'dual' | 3000 |
| NITRO_LOG_LEVEL | No | Log verbosity | info |
| MCP_TRANSPORT_TYPE | No | Transport type: 'stdio', 'http', or 'dual'. Default is 'stdio' in dev and 'dual' in production. | stdio |
| NITROSTACK_APP_MODE | No | NitroStack app mode | universal |
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 |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": true,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| register_serverB | Register an MCP server with NitroWatch so it can be watched |
| discover_capabilitiesB | Connect to a registered server's real MCP endpoint and list its tools/resources/prompts |
| get_burn_rateB | Project time-to-exhaustion on the team's 5M AI token budget |
| generate_glueB | Generate a stub connector function that calls a tool on one registered server and pipes its result into a tool on another |
| classify_toolsA | Assign a risk tier (read / reversible / irreversible) to every tool on a registered server. Run this after discover_capabilities. Tries the LLM classifier first and falls back to the deterministic one. |
| set_tierA | Manually override a tool's risk tier when the classifier gets it wrong. Recorded as a human decision in the audit trail. |
| request_actionA | Ask NitroWatch to run a tool on a governed server. Read tools and promoted tools run immediately; everything else is queued for human approval and returns an approvalId. |
| list_pending_approvalsA | Show every action currently blocked and waiting on a human decision, newest first. Renders the interactive approval console. |
| approve_actionA | Human approves a pending action. Executes it, records the approval, and reports whether the tool has now earned promotion. |
| deny_actionA | Human denies a pending action. Nothing executes, and the denial is recorded permanently against that tool. |
| promote_toolB | Grant a reversible tool standing permission to run unattended. Requires a clean approval record. Irreversible tools are refused. |
| revoke_toolA | Withdraw a tool's autonomy immediately. It returns to requiring approval on every call. |
| get_trust_statusA | Show the approval record and autonomy state for every governed tool — the evidence behind each promotion decision. |
| get_audit_logB | Return the full decision history: what was classified, allowed, blocked, approved, denied, promoted, and by whom. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| approval_briefing | Turn a pending action into a plain-language brief a human can decide on quickly. |
| security_posture_review | Summarise the current governance posture: what runs unattended, what is still gated, and what looks risky. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Registered servers | All MCP servers currently registered with NitroWatch |
| Server logs | Recent log entries for a given registered server |
| Tool policies | Risk tier and autonomy state for every governed tool |
| Pending approvals | Actions currently blocked and waiting on a human decision |
| Audit trail | Every governance decision recorded, newest last |
| Health Checks | Current health status of all registered health checks |
| Approval Console | UI component for Approval Console |
| Widget Examples | Provides metadata and examples for all registered UI widgets |
TDQS
Scored across 14 tools
Every tool targets a distinct function: registration, discovery, classification, override, request, approval listing, approve, deny, promote, revoke, trust status, audit log, budget, and glue generation. No two tools overlap in purpose.
All tool names follow a consistent verb_noun pattern (e.g., register_server, classify_tools, approve_action). No mixed casing or inconsistent verb styles.
14 tools is well within the ideal 3-15 range and each tool covers a distinct step in the governance workflow. The count feels justified by the breadth of the domain.
The core lifecycle is well covered: register, discover, classify, request, approve, promote, revoke, audit. Missing server removal or listing (e.g., unregister_server) is a minor gap, but agents can work around it.