Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NitroWatch what pending actions need my approval?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Your AI agent just got a permission system.
Connect an AI agent to an MCP server today and it is all-or-nothing: either the agent can call every tool, or a human hand-approves every single call, forever. There is no policy layer, no notion of which tools are dangerous, no audit trail, and no way for trust to grow over time.
NitroWatch is the missing governance layer. It sits in front of any MCP server, classifies every tool by risk, enforces what the agent may do, lets safe tools earn autonomy through a proven track record, and records every decision permanently.
Built with the NitroStack TypeScript SDK for the NitroStack × SRM Hackathon 2026.
The problem MCP has today, the three risk tiers, how autonomy is earned, and the six bugs we found while building this (two of them in NitroStack's own framework, reported upstream).
Imagine a company's MCP server exposing three tools:
Tool | Consequence |
| Harmless. Reads data. |
| Costs money, but can be voided. |
| Irreversible. Gone is gone. |
MCP treats all three identically. There is no way to express "let the agent read freely, ask me before it spends money, and never let it delete anything."
Every team adopting MCP hits this wall immediately, and both usual answers are bad:
Approve everything manually → the human becomes the bottleneck and starts rubber-stamping.
Trust the agent fully → one hallucinated tool call destroys production data.
NitroWatch is the middle path nobody has built.
Related MCP server: gov-mcp
AI AGENT
│ request_action(serverId, toolName, args)
▼
┌───────────────────────────────────────────────┐
│ NITROWATCH │
│ │
│ 1. classify every tool → a risk tier │
│ 2. enforce tier decides what happens │
│ 3. earn clean record → autonomy │
│ 4. audit every decision recorded │
└───────────────────────────────────────────────┘
│ │ │
read│ reversible│ irreversible│
▼ ▼ ▼
RUNS NOW approval, until ALWAYS
promoted APPROVAL
(never promotes)
│
▼
DOWNSTREAM MCP SERVERTier | Meaning | Behaviour |
| No side effects | Runs immediately, always |
| Real effects, can be undone | Gated — can earn autonomy |
| Cannot be undone | Gated permanently |
The hard rule: an irreversible tool can never be promoted to run unattended, regardless of how good its track record is. Trust is earned per tool, but the ceiling is set by consequence, not history. That single constraint is what makes NitroWatch safe to put in front of a production system.
A reversible tool that accumulates 3 clean approvals with zero denials becomes eligible for promotion. NitroWatch then offers — it never promotes itself. A human confirms with promote_tool, and can withdraw it instantly with revoke_tool.
A single denial permanently disqualifies a tool from autonomy. If a human ever said "no", the pattern isn't clean enough to stop asking.
Before approving, the human sees what the action would actually touch:
scoped to accountId="acc_991"
UNBOUNDED — "force" is set, so this may affect every record this tool can reach"Approve this?" and "approve this, knowing it hits every record" are very different questions.
We pointed the classifier at a domain it had never been tuned for, and it immediately made a dangerous mistake. This is the most important thing we learned building NitroWatch, so it gets its own section rather than a footnote.
The classifier was written and tested against a billing vocabulary. To check whether it generalised, we ran it over an infrastructure server — cluster operations, databases, backups. One result stopped us:
❌ read scale_deployment matched read-only verb "count"scale_deployment was classified read.
In NitroWatch, read means autonomous from birth — it runs immediately, forever, with no approval. A tool that resizes production deployments would have run completely unsupervised.
The classifier read the tool name and its description as one bag of words. The description said:
"Change the replica count of a deployment."
count is in the read-verb list. One noun in a sentence of prose was enough to grant a mutating tool permanent unattended execution.
The same flaw hit rotate_credentials, which matched set in "invalidate the previous set" — again a noun, not a verb.
1. The tool name is authoritative. A name is written to state what a tool does. A description is prose. They are no longer read as one bag of words — the name decides the tier, and the description is consulted separately.
2. The description may only escalate risk — never reduce it.
Prose can legitimately reveal that a tool is more dangerous than its name suggests — a cleanup tool that "permanently deletes archived records" really is irreversible, and we want that caught. But a description can never argue a tool down to read.
And an unrecognised name with a read-looking description now defaults to reversible, not read. No evidence from the name is not enough to grant unattended execution.
If a description could lower a tool's tier, then the description becomes an attack surface. Anyone who controls the text of a tool — the author of a third-party MCP server you connected — could write prose designed to talk NitroWatch into treating delete_everything as read-only.
Under the current rules that is impossible. The worst a hostile description can do is make a tool look more dangerous than it is, which fails safe. The same principle governs the LLM classifier: on disagreement, the more dangerous verdict always wins.
One test run against an unfamiliar vocabulary. It is now locked in by a regression test asserting scale_deployment can never be classified read, plus a generalisation test over the whole infrastructure vocabulary.
We would rather ship a governance tool that has been caught failing and fixed than one that has never been tested outside the domain it was written for.
src/
├── index.ts McpApplicationFactory bootstrap
├── app.module.ts @McpApp root module
├── health/system.health.ts health checks
└── modules/nitrowatch/
├── nitrowatch.module.ts registers all controllers
├── nitrowatch.store.ts state: servers, policies, trust, audit
├── nitrowatch.policy.ts risk classifier + blast radius
├── nitrowatch.tools.ts register / discover / burn rate / glue
├── nitrowatch.governance.tools.ts classify / request / approve / promote
├── nitrowatch.resources.ts policies, pending, audit, logs
└── nitrowatch.prompts.ts approval briefing, posture reviewDesign notes
nitrowatch.store.ts is the only stateful module. Everything else reads through its helpers, so swapping in a database touches exactly one file.
All execution funnels through one function (executeOnServer), so nothing can run without passing an audit point.
The classifier is deterministic and biased toward caution. Anything it cannot confidently read as read-only is treated as at least reversible — an over-cautious classifier costs a click, an under-cautious one costs a database.
NitroWatch is an MCP server that is also an MCP client. It speaks the protocol in both directions, which is what lets it govern arbitrary servers.
Tool | Purpose |
| Register an MCP server to be governed |
| Connect to it and enumerate tools/resources/prompts |
| Assign every tool a risk tier |
| Agent asks to call a tool — allowed, or queued for approval |
| Human approves → executes, trust +1 |
| Human denies → blocked, autonomy disqualified |
| Grant standing autonomy after a clean record |
| Withdraw autonomy immediately |
| Track record and autonomy state per tool |
| Full decision history |
| Token budget projection |
| Stub connector between two registered servers |
URI | Contents |
| All registered servers |
| Per-server log entries |
| Risk tier + autonomy for every governed tool |
| Actions awaiting a human decision |
| Complete audit trail |
Prompt | Purpose |
| Plain-language brief for a pending action |
| What runs unattended, what is gated, what looks risky |
nitrowatch-billing-demo is an intentionally ungoverned MCP server built to be governed by this one. It exposes five tools that land on all three risk tiers — including a delete_account that will permanently destroy an account and its invoices for anyone who asks, with no confirmation.
git clone https://github.com/Mohith535/nitrowatch-billing-demo.git
cd nitrowatch-billing-demo && npm install && npm run build
npx nitrostack-cli start --port 3100Then, from NitroWatch:
register_server({ name: "Billing API", endpoint: "http://localhost:3100/sse" })
discover_capabilities({ serverId: "billing-api" })
classify_tools({ serverId: "billing-api" })
request_action({ serverId: "billing-api", toolName: "delete_account",
args: { accountId: "acc_991" } }) // → blocked⚠️ Use
--port— thePORTenvironment variable is silently ignored and the server would otherwise bind 3000, colliding with NitroWatch.If you run NitroWatch from NitroCloud rather than locally, it cannot reach
localhoston your machine. Run both locally, or deploy the billing server too and register its public URL.
Requirements: Node.js 20.x (18+ minimum), npm 9+
git clone https://github.com/Mohith535/nitrowatch.git
cd nitrowatch
npm install
npm run devThen open the project in NitroStudio → Studio App Canvas → Tools.
npm run build # → dist/
npm run start:prodCopy .env.example to .env. No secrets are required to run locally.
Variable | Default | Purpose |
|
| Log verbosity |
|
| NitroStack app mode |
|
|
|
|
| HTTP port when transport is |
| unset | Enables LLM classification. Unset is a valid state — the deterministic classifier runs instead. |
|
| Any OpenAI-compatible endpoint (Groq, OpenRouter, Cerebras, local) |
|
| Model name for the above |
API keys for governed servers are supplied per-server via
register_serverand are never committed.
npm test18 tests over the security-critical logic — tier assignment, verb precedence, tokenization, the fail-safe default, blast-radius detection, description-escalation rules, cross-domain generalisation, and the promotion rules.
They earn their keep. They have caught three real bugs so far — the third is significant enough to have its own section above:
Conjugated verbs didn't match. A description reading "permanently deletes archived records" classified as reversible, because the verb list held delete and the text said deletes. Fixed with suffix stripping — deliberately not prefix matching, which would make settings match the verb set and misclassify get_settings.
camelCase argument keys were invisible to blast-radius detection. { accountId: "acc_991" } reported "scope inferred from: accountId" instead of the actual value, because the regex anchored on _ or start-of-string. Keys are now tokenized the same way tool names are.
⚠️ A mutating tool was classified read-only because a noun in its description matched a read verb — scale_deployment would have run unattended. See the section above. This is the one that mattered.
All three were in code that looked obviously correct.
classify_tools tries the LLM classifier first and falls back to the deterministic one. Three rules govern the interaction:
Any failure falls back — no key, quota exhausted, timeout, malformed reply. Governance must never fail open.
On disagreement, the more dangerous tier wins. Disagreement is a signal to be careful, not a coin flip.
Rule 2 is also a prompt-injection defence. A hostile tool description cannot talk the system down from a tier the verb heuristic already flagged — the worst it can do is talk it up.
This mirrors the deterministic classifier's own rule that a description may only escalate risk — see the bug we found. Both layers fail in the same safe direction, deliberately.
The LLM call is capped at 8 seconds so a slow classifier can't stall the governance path.
Stated plainly, because a governance tool that hides its gaps is worth less than one that names them.
Governance decisions are unauthenticated. Anyone who can reach the server can call approve_action or promote_tool. Production would gate these behind operator identity — NitroStack's @UseGuards is the natural mechanism. This is the most significant gap.
State is in-memory. A serverless cold start clears policies, approvals, and the audit trail. nitrowatch.store.ts is the only file that would change.
estimateBlastRadius reads arguments, not the target system. It cannot know that { status: "inactive" } matches 40,000 rows. It flags shape, not true magnitude.
get_burn_rate takes usage as an input rather than measuring it, so it projects rather than tracks.
generate_glue emits a stub and does not solve schema mapping between the two tools.
A full governance cycle:
// 1. Put a server under governance
register_server({ name: "Billing API", endpoint: "https://billing.example.com/sse" })
discover_capabilities({ serverId: "billing-api" })
classify_tools({ serverId: "billing-api" })
// → get_invoice read runs freely
// → send_invoice reversible gated, can earn autonomy
// → delete_account irreversible gated forever
// 2. A read passes straight through
request_action({ serverId: "billing-api", toolName: "get_invoice", args: { id: "inv_1" } })
// → { decision: "allowed", tier: "read" }
// 3. Something dangerous is stopped
request_action({ serverId: "billing-api", toolName: "delete_account", args: { accountId: "acc_991" } })
// → { decision: "blocked", approvalId: "act_1", tier: "irreversible",
// blastRadius: 'scoped to accountId="acc_991"' }
// 4. Human decides, with context
approval_briefing({ approvalId: "act_1" })
deny_action({ approvalId: "act_1", reason: "not authorised for bulk deletion" })
// 5. A reversible tool earns its way up
request_action(...) → approve_action(...) // ×3
// → promotionOffer: { eligible: true, ... }
promote_tool({ serverId: "billing-api", toolName: "send_invoice" })
// → now runs unattended
// 6. But the irreversible one never can
promote_tool({ serverId: "billing-api", toolName: "delete_account" })
// → Error: Refused — irreversible tools can never be promoted.LLM classification — classifyWithLlm() in nitrowatch.policy.ts is the seam. Contract: LLM first, deterministic fallback on any failure, and on disagreement take the more dangerous tier.
Approval console widget — a React widget over nitrowatch://pending.
Durable state — swap the in-memory Maps in nitrowatch.store.ts for a database so policies survive a serverless cold start.
Apache-2.0
Human approves a pending action. Executes it, records the approval, and reports whether the tool has now earned promotion.
| Name | Required | Description | Default |
|---|---|---|---|
| approvalId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: execution of the pending action, recording the approval, and reporting promotion outcome. This is significant transparency, though it doesn't mention error handling or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose and lists the consequential outcomes. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the main flow: approve → execute → record → report promotion. It doesn't explain prerequisite steps (e.g., how approvalId is obtained), but the siblings imply a workflow. Overall adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The single parameter approvalId is not explained in the description; the agent is left to infer that it identifies the pending action. The description doesn't compensate by specifying how to obtain the ID or any constraints. Baseline low due to lack of schema coverage and no param elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it approves a pending action, executes it, records the approval, and reports on promotion status. This specific verb-resource pairing distinguishes it from siblings like deny_action and request_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: it's for human approval of pending actions. However, it doesn't explicitly state when to use this over alternatives like deny_action or list_pending_approvals, nor any prerequisites such as having a pending approvalId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | Yes | ID of a server already registered with NitroWatch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a notable behavioral trait: trying the LLM classifier first with deterministic fallback. However, with no annotations, it does not mention side effects (e.g., overwriting existing tiers, permission needs) or whether the operation is reversible, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences concisely cover purpose, usage, and algorithm without redundancy. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers what, when, and how. It doesn't explicitly state return values or confirm it modifies existing tiers, but 'assign' implies the effect, making it adequate for the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with serverId described as 'ID of a server already registered with NitroWatch.' The description only reinforces 'registered server' without adding new semantic details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it assigns risk tiers (read/reversible/irreversible) to every tool on a registered server, using a specific verb and resource. It distinguishes from siblings like set_tier by indicating a bulk, automated classification, and references a distinct workflow step after discover_capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to run after discover_capabilities, providing clear workflow context. It implies a prerequisite (registered server) consistent with the schema, but doesn't explicitly state exclusions or alternatives beyond the implied ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Human denies a pending action. Nothing executes, and the denial is recorded permanently against that tool.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Why it was denied — stored in the audit trail | |
| approvalId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses two key behaviors: 'Nothing executes' and 'denial is recorded permanently,' which is valuable context. However, it does not state what happens to the pending action after denial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action, and no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers the core behavior and primary side effect (permanent recording). It lacks mention of return values and the fate of the pending action, but these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (reason has a description, approvalId does not). The description adds context that approvalId refers to the pending action, but not explicitly. It partially compensates for the gap but could be clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Human denies a pending action.' This clearly distinguishes it from siblings like approve_action and list_pending_approvals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (deny a pending action) but there is no explicit mention of when to use this versus approve_action or any exclusions. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to a registered server's real MCP endpoint and list its tools/resources/prompts
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions 'real MCP endpoint,' indicating a network call, but does not disclose potential side effects, required permissions, failure modes, or response format. It lacks critical behavioral context like timeouts or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys both the action and the result. It is front-loaded with the core purpose and contains no filler or redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description covers the main purpose and param meaning adequately. It even mentions the output scope (tools/resources/prompts). It lacks usage guidelines and failure caveats, but these are less critical for such a simple discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single serverId string with 0% description coverage. The description adds meaning by identifying serverId as the registered server to connect to, but it does not explain how to obtain it or any format constraints. It adds basic context but not full semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: connect to a server's real MCP endpoint and list its tools/resources/prompts. It distinguishes itself from siblings like register_server (which registers servers) and classify_tools (which categorizes tools) by focusing on live endpoint discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (only for registered servers) but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or context. No mention of which other tools are preferred for local vs real endpoint capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a stub connector function that calls a tool on one registered server and pipes its result into a tool on another
| Name | Required | Description | Default |
|---|---|---|---|
| sourceTool | Yes | ||
| targetTool | Yes | ||
| sourceServerId | Yes | ||
| targetServerId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the high-level purpose. It does not mention whether the operation has side effects, what the output format is, or whether the servers must already be registered. This leaves the agent without essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively front-loads the main verb and object. Every word contributes to conveying the tool's core function, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four required parameters, no annotations, and no output schema, the description is too sparse. It does not specify what the generated 'stub connector function' looks like, how it is returned, or any behavioral implications. The tool's complexity demands more context than this brief description provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the roles of 'source' and 'target' (calling a tool on one server and piping the result to another), which adds meaning beyond the property names. However, it does not elaborate on parameter formats or the exact relationship between server IDs and tool names, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (generate a stub connector function) and the resources involved (tools on two servers). It distinguishes itself from sibling tools like register_server or approve_action, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to connect a tool on one server to a tool on another, but it does not explicitly state when to use this vs alternatives, nor mention prerequisites such as servers needing to be registered first. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full decision history: what was classified, allowed, blocked, approved, denied, promoted, and by whom.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| serverId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the content of the log (what was decided and by whom) and implies a read-only operation ('Return'). However, it does not mention pagination behaviors (limit), authentication requirements, or whether the log is filterable by server, which are relevant for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and provides a useful enumeration of included decision types. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should compensate for that. While it clearly states the tool's purpose, it omits key behavioral details (e.g., pagination via limit, server scoping, return format). The lack of parameter explanation and result format leaves the description incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'limit' or 'serverId' parameters. An agent cannot determine what these parameters do or how they affect the returned history, leaving the schema as the only (minimal) guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Return') and identifies a specific resource ('full decision history'), listing the types of decisions included (classified, allowed, blocked, approved, denied, promoted) and by whom. This clearly distinguishes it from sibling action tools like approve_action or deny_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reviewing historical decisions, which contrasts with sibling tools that perform actions. However, it does not explicitly state when to use this tool over alternatives, mention prerequisites, or provide exclusions. Usage context is implied but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project time-to-exhaustion on the team's 5M AI token budget
| Name | Required | Description | Default |
|---|---|---|---|
| used | Yes | ||
| budgetTotal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It does not state whether the tool is read-only, what assumptions underlie the projection (e.g., linear extrapolation), or what input 'used' represents. It also doesn't mention response format or error conditions, making behavior unpredictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that puts the core purpose first. No wasted words. It conveys the essential idea efficiently, though it could benefit from additional detail elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description needs to explain what the tool returns and any necessary context. It fails to state the output format, whether it returns a date, a number, or a report, and it lacks guidance on how to supply input. The description is too sparse for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the 5M budget (budgetTotal) but does not explain the meaning of 'used' or how the projection is calculated from the parameters. The description adds minimal value in clarifying parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Project' and identifies the resource ('time-to-exhaustion on the team's 5M AI token budget'), clearly distinguishing this from sibling tools focused on server registration, approvals, and trust. It states the core function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to forecast when the token budget will run out, but it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites like what 'used' represents or how to interpret the result. It offers only implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the approval record and autonomy state for every governed tool — the evidence behind each promotion decision.
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | No | Omit to see every server |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. The verb 'Show' implies a read-only operation, and the description explains what is returned (approval record and autonomy state). However, it does not explicitly state that the operation has no side effects, nor does it mention any authorization requirements or scope limitations beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently communicates the tool's purpose and value. The dash adds relevant contextual detail without redundancy, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description adequately explains what is returned (approval record and autonomy state) and why it matters (evidence behind promotion decisions). It could mention that serverId can be used to filter by server, but that is already covered in the schema, so the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the only parameter ('Omit to see every server'), achieving 100% schema coverage. The tool description does not add additional meaning about parameter usage or formatting, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Show the approval record and autonomy state for every governed tool.' The verb 'Show' is specific, the resource is well-defined, and the added context about 'evidence behind each promotion decision' distinguishes it from sibling tools like get_audit_log or list_pending_approvals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to view trust status and promotion evidence, but it does not explicitly say when to use it over alternatives such as get_audit_log or list_pending_approvals. No exclusions or alternative comparisons are provided, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show every action currently blocked and waiting on a human decision, newest first. Renders the interactive approval console.
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | No | Limit to one server; omit for all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It says 'Show' and 'Renders', implying a read-only operation, and includes the behavioral detail of 'newest first' ordering. Yet it does not explicitly state that no changes are made, nor does it clarify what 'interactive approval console' entails (e.g., whether it requires user input or has side effects). This is moderate disclosure for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences totaling 23 words, with no redundant phrases. The first sentence states the core function and ordering, the second adds the output format ('interactive approval console'). Every word earns its place, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the main purpose and ordering but lacks detail on the exact return format or any prerequisites/permissions. Given no annotations, it could mention that it is a safe, read-only operation. The phrase 'interactive approval console' is vague and could be expanded, but the tool is straightforward enough that this is adequate yet not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, serverId, with the description 'Limit to one server; omit for all', giving 100% schema description coverage. The tool description adds no additional parameter semantics, which is acceptable since the schema fully explains the parameter. Baseline 3 is appropriate because the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Show every action currently blocked and waiting on a human decision, newest first.' This identifies a specific verb ('Show') and a clear resource (actions blocked on human decisions), which distinguishes it from sibling tools like approve_action, deny_action, and request_action that modify or request approvals rather than listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to view all pending approvals. It doesn't explicitly exclude alternatives, but the role is evident from the sibling set. However, it does not mention specific scenarios where a different tool should be used, such as filtering by server or taking action on an approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grant a reversible tool standing permission to run unattended. Requires a clean approval record. Irreversible tools are refused.
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | Yes | ||
| toolName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the action type, the prerequisite of a clean approval record, and that irreversible tools are refused. However, it does not mention potential side effects, reversibility of the grant itself, or error behavior when conditions are not met, leaving important behavioral details undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action. Every sentence adds value: the first defines the purpose, the second conveys prerequisites and constraints. There is no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a privileged operation with two parameters, no output schema, and no annotations. The description covers the core purpose and key constraints, but lacks information on return values, failure modes, or the meaning of a 'clean approval record.' This leaves gaps given the absence of other structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (serverId, toolName) with no descriptions, resulting in 0% schema coverage. The description does not mention either parameter, failing to compensate for the schema's lack of detail. Parameter names are reasonably self-explanatory, but no additional meaning or format is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: granting a reversible tool standing permission to run unattended. It distinguishes from sibling tools like approve_action (which handles pending actions) and revoke_tool (which revokes permissions), though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to grant standing permission) and includes prerequisites ('Requires a clean approval record') and a constraint ('Irreversible tools are refused'). However, it lacks explicit guidance on when not to use it or how it compares to related tools like request_action or approve_action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register an MCP server with NitroWatch so it can be watched
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| apiKey | No | ||
| endpoint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the outcome ('so it can be watched') but does not disclose side effects, whether registration is idempotent, whether the endpoint is validated at registration time, or how the apiKey is used. This is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and object. It contains no filler or repetition, and every word contributes to conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, and the bare-bones parameter schema, the description is the only source of contextual information. It covers the basic purpose but omits usage guidance, parameter meaning, and behavioral details, leaving significant gaps for an agent trying to decide when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the parameters. While 'name' and 'endpoint' are somewhat self-explanatory, 'apiKey' is ambiguous—the description does not clarify its purpose or whether it is required. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Register'), a specific resource ('an MCP server'), and the intended outcome ('so it can be watched'). This clearly differentiates it from sibling tools like discover_capabilities or request_action, none of which involve server registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: use this tool when you want to register an MCP server to be watched by NitroWatch. However, there is no explicit guidance about when not to use it, prerequisites (e.g., endpoint reachability), or alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments to pass to the downstream tool | |
| serverId | Yes | ||
| toolName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behavior: immediate execution vs queueing for human approval with an approvalId. It gives the core behavioral distinction but doesn't describe side effects beyond the approval flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences that front-load the core action and immediately clarify the execution policy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main API behavior but omits what immediate runs return and doesn't elaborate on argument structure. Given no annotations and no output schema, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes the 'args' parameter, leaving serverId and toolName undocumented. The description adds no parameter-specific details, so an agent must infer from names alone, which is insufficient for a 33% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Ask NitroWatch to run a tool on a governed server.' It also distinguishes behavior for read/promoted tools vs others, differentiating it from sibling tools like approve_action and list_pending_approvals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that read tools and promoted tools run immediately, while others require approval, giving clear context for expected behavior. However, it doesn't explicitly name alternative tools or say when not to use this tool, relying on context from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Withdraw a tool's autonomy immediately. It returns to requiring approval on every call.
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | Yes | ||
| toolName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the immediate behavioral change ('returns to requiring approval on every call') and the immediacy ('immediately'). It does not mention permissions or side effects, but for a straightforward state change, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action, and contains no fluff or repetition. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description explains what it does and the resulting state. It does not explain the parameters, but the schema names plus the tool's purpose provide reasonable context. Overall, it is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention the parameters (serverId, toolName) at all. While the names are somewhat self-explanatory, the description adds no semantic meaning or guidance about how to fill them, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Withdraw' and clearly identifies the resource (a tool's autonomy), distinctly differentiating it from sibling tools like promote_tool. The effect is unambiguous: the tool returns to requiring approval on every call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (revoking autonomy) and states the immediate consequence. While it does not explicitly name alternatives or exclusions, the distinction from promote_tool and approval management tools is clear from the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually override a tool's risk tier when the classifier gets it wrong. Recorded as a human decision in the audit trail.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | Yes | ||
| reason | Yes | Why the override is correct — stored and shown in future briefings | |
| serverId | Yes | ||
| toolName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by noting that the action is 'Recorded as a human decision in the audit trail,' which is a significant behavioral trait. However, it does not disclose other important aspects such as whether the override is reversible, what permissions are needed, or immediate side effects beyond the audit trail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two concise sentences that directly convey the core purpose and a key behavioral consequence. There is no redundant information, and it is well front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 required parameters, low schema coverage, no output schema, and no annotations), the description is too brief. It lacks details about parameter mapping, the allowed tier values, and the operational impact of the override. An agent would need additional information to confidently invoke the tool, making the description incomplete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 25% (only 'reason' has a description), and the tool description does not compensate by explaining the purpose of serverId, toolName, tier, or reason. While parameter names are somewhat self-explanatory, the description adds no additional meaning, leaving agents to infer that serverId and toolName identify the tool and tier is the new value. This is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: manually overriding a tool's risk tier when automatic classification is incorrect. The verb 'override' and the specific resource 'tool's risk tier' make the action unambiguous. It also distinguishes itself from sibling tools like classify_tools (which performs automatic classification) and promote_tool/revoke_tool (which handle different lifecycle actions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the exact condition for use: 'when the classifier gets it wrong.' This provides clear context for when to invoke the tool. However, it does not explicitly name alternatives or exclude scenarios where other tools (e.g., promote_tool or revoke_tool) might be appropriate, so it lacks a fully explicit when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0approve_actionclassify_toolsdeny_actiondiscover_capabilitiesgenerate_glueget_audit_logget_burn_rateget_trust_statuslist_pending_approvalspromote_toolregister_serverrequest_actionrevoke_toolset_tierEvery 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Identity, authorization, audit trails, and revocable permissions for AI agents accessing MCP tools.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Agent governance with A2A/Shopify/MCP trust audits, action screening, and decision UI.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mohith535/nitrowatch'
If you have feedback or need assistance with the MCP directory API, please join our Discord server