Click on "Deploy 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., "@Sentinel MCP Server is it safe for my agent to send this email to all customers?"
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.
An MCP (Model Context Protocol) server that puts Sentinel, Aridon's pre-execution authorization layer for AI agents, in front of any MCP client. Before an agent acts, Sentinel evaluates the proposed action and returns a verdict — allow, hold (a human must approve first), or deny — and records the decision in a SHA-256 hash-chained audit log.
Honest stage — read this first. Sentinel is a development-stage technical preview. It has been validated in internal synthetic testing only (September 2026 harness: 18/18 scenarios passed, 13/13 hostile actions held pre-execution, 0 false positives). It has no customers and no revenue, has not had an independent penetration test, and carries no SOC 2 / ISO / FedRAMP certification. The evaluation is heuristic, not a guarantee of safety. This package is a small, working slice of Sentinel, published so agents and developers can try the evaluation model — it is not the full Sentinel product (no hosted policy store, no tenant management, no approval-workflow UI, no persistent audit storage).
Tool | What it does |
| Evaluate a proposed agent action before execution. Inputs: the action description, optional |
| Explains the scoring bands, the independent action gate for consequential tool calls, the trajectory/authorization adjustments, and the signal categories and weights Sentinel uses. |
| Reports the audit log state for this server process: entry count, genesis and tip hashes, and a full SHA-256 chain re-verification ( |
Sentinel scans the action text, prior turns, and requested tool calls with weighted heuristic rules (credential theft, malware, data exfiltration, instruction override / prompt injection, approval evasion, mass resource provisioning, and others) and sums a 0–100 risk score:
0–24 allow · 25–49 allow with restrictions · 50–74 hold for human review · 75–100 deny
Independently of the score, an action gate covers consequential tool calls (sending email, payments and transfers, shell/command execution, database writes/deletes, credential or secret access, network requests, file deletion): those require human approval even when the content looks benign, and are denied outright when risk is elevated. Risk also accumulates across conversation turns, and a clearly authorized defensive context (your own systems, a lab, blue-team work) lowers the score — without disabling checks — unless the action text itself carries clearly harmful language.
The evaluation and audit code in this package is the real Sentinel logic,
ported from Aridon's codebase (lib/sentinel-grid.ts and
lib/sentinelAudit.ts in the Aridon app repository).
Every sentinel_evaluate_action call appends a decision entry to a SHA-256
hash-chained log: each entry commits to the previous entry's hash, so any
edit, insertion, or deletion in the history breaks verification. In this
package the log is process-local (in memory) and resets when the server
restarts; the full product persists entries. sentinel_audit_status
re-verifies the whole chain on demand.
Related MCP server: varco_mcp
Requires Node.js 18+.
Run it directly with npx:
{
"mcpServers": {
"sentinel": {
"command": "npx",
"args": ["-y", "@aridon/sentinel-mcp"]
}
}
}That configuration works in MCP clients that read mcpServers config
(e.g. Claude Desktop, Cursor, and similar). The server speaks MCP over
stdio; it needs no API keys, accounts, or network access.
Or install it:
npm install -g @aridon/sentinel-mcp
sentinel-mcpnpm install
npm run build # tsc -> dist/
npm run smoke # starts the server over stdio and calls every toolSource (Aridon app monorepo): https://github.com/jimrusk/aridon-app
MCP Registry name: io.github.jimrusk/sentinel-mcp (see server.json)
Product page: https://aridon-v02.vercel.app/sentinel
MIT — see LICENSE. Copyright (c) 2026 Aridon (Triple R Restoration, LLC dba Aridon).
Some systems never propose actions to an agent: legacy and OT devices that accept commands directly over a network. In November 2026, attackers reached end-of-life refrigeration controllers in European supermarkets over the internet and ran them hot. NetGuard is the layer for those devices:
Command broker (sentinel_register_device, sentinel_device_command):
the only identity allowed to command a registered device. Enrolled sources
only; parameters outside hard safety limits are denied outright; defrosts
and out-of-band changes hold for a human; command text is scored by the
same intent engine as agent actions.
Enforcement plan (sentinel_enforcement_plan): generated segmentation
rules (JSON + nftables) making the broker the only reachable path: no
internet route to the devices, no device egress.
Telemetry watchdog (sentinel_device_telemetry): observed state is
compared with the last brokered state. A change nobody brokered is treated
as tampering: an audit-chained incident and a quarantine rule set.
Test it: node test/netguard.mjs replays the supermarket attack end to end
(18 checks). Honest scope: NetGuard protects devices enrolled in its registry
behind the enforcement rules it generates; it does not patch the devices.
Development-stage technical preview, internal testing only, no customers yet.
We are looking for lab testing partners, especially controller manufacturers
and food-retail operators. Contact: jimrusk66@gmail.com.
Report the state of this server process's Sentinel audit log: entry count, genesis and tip hashes, and a full SHA-256 chain re-verification. The log is process-local and resets when the server restarts; it demonstrates the same hash-chain used by the full product.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does real work: it discloses that the log is process-local, resets on server restart, and that the call performs a full SHA-256 chain re-verification (a non-trivial whole-chain operation). It stops short of stating whether the re-verification is expensive, what a failed verification looks like, or any permission requirements, but the demo/non-durable nature of the data is clearly surfaced.
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, zero filler. The substantive payload (what is reported) comes first, and the caveats (process-local, resets on restart, demo of the production chain) follow as necessary qualification.
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?
With no output schema, the description compensates by listing the returned fields, so an agent knows roughly what to expect. It does not describe the shape of the verification result (e.g., pass/fail flag versus first broken index), which is the one meaningful gap for a tool whose headline function is chain re-verification.
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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a no-param tool 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?
States a specific verb ('Report') and a specific resource (this server process's Sentinel audit log), then enumerates what is returned: entry count, genesis/tip hashes, and a full SHA-256 chain re-verification. This is unmistakable against siblings like sentinel_evaluate_action or sentinel_device_telemetry, which concern actions and devices rather than log state.
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 only implied: an agent can infer this is the tool to call when it wants to inspect log state or check integrity. There is no explicit guidance on when to prefer it, no statement of prerequisites, and no mention of cost or when not to trigger a full re-verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a command for a NetGuard-registered device BEFORE it is forwarded. Verdicts: allow (forward it), hold (a human must approve first), deny (never forward). Unenrolled sources are denied; parameters outside hard safety limits are denied outright. Every decision is audit-chained.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| source | Yes | Identity submitting the command. Must be an enrolled NetGuard identity. | |
| deviceId | Yes | ||
| setpointC | No | ||
| description | No | Free-text intent; scored by the Sentinel intent engine. | |
| defrostMinutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it names the three verdicts and their consequences, states that unenrolled sources are denied, that out-of-limit parameters are denied outright, and that every decision is audit-chained. The remaining ambiguity is whether this tool only evaluates or also performs the forward, since the title says 'send a command' while the description says evaluate before forwarding.
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?
Four short sentences, front-loaded with the core action and followed by the verdict semantics, with zero filler. Each sentence contributes either the purpose or a behavioral rule the agent could not otherwise know.
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?
There is no output schema and no annotations, so the description must cover returns and safety behavior; it covers the verdicts and denial rules but not what accompanies a verdict (reason, policy reference, audit identifier) or the enrollment/auth requirements in any detail. For a six-parameter policy-gate tool, that leaves meaningful gaps for an agent deciding how to call it and how to interpret the result.
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 only 33% (just source and description are documented), so the description needed to compensate for the undocumented parameters. It adds only an indirect hint that 'parameters outside hard safety limits are denied,' without explaining kind's enum values, deviceId, setpointC units, or defrostMinutes. An agent still cannot tell from this text what setpointC range is safe or how the custom kind behaves.
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 and resource: 'Evaluate a command for a NetGuard-registered device BEFORE it is forwarded.' It usefully corrects the impression created by the tool name and title ('Send a command'), making clear this is a gatekeeper evaluation rather than an execution. However, it never distinguishes itself from the sibling sentinel_evaluate_action, which by name appears to do something very similar.
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 phrase 'BEFORE it is forwarded' implies the point in the workflow where this tool belongs, and the verdict list clarifies the decision outcomes. There is no explicit when-not guidance and no routing to alternatives such as sentinel_evaluate_action or sentinel_explain_policy, so an agent facing those siblings has to infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a protected device's observed setpoint and temperature. The watchdog compares them to the last brokered state: a change nobody brokered is treated as tampering, an out-of-limits state as unsafe. Either raises an audit-chained incident and quarantines the device.
| Name | Required | Description | Default |
|---|---|---|---|
| deviceId | Yes | ||
| temperatureC | Yes | ||
| observedSetpointC | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that values are compared to the last brokered state, that unbrokered changes are treated as tampering and out-of-limits states as unsafe, and that either outcome raises an audit-chained incident and quarantines the device. Remaining gaps are secondary traits such as idempotency, return value, and whether repeated identical reports re-trigger incidents.
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 tight sentences: the first states the action, the second front-loads the decision logic and consequences. No filler, and the highest-stakes information (incident plus quarantine) lands before the reader stops.
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 three-parameter tool with no annotations and no output schema, the description covers the important unknowns: what the inputs are compared against and what side effects follow. It stops short of saying what the call returns (incident identifier, verdict, quarantine status) or whether it is safe to retry, which an agent deciding how to react would want.
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, and it only partly does: it maps deviceId to 'a protected device' and the two numeric fields to 'observed setpoint and temperature'. It adds no units, ranges, or format expectations beyond what the parameter names already imply.
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 and resource: report a protected device's observed setpoint and temperature to the NetGuard watchdog. It implicitly separates itself from sentinel_device_command by contrasting 'observed' state with 'brokered' state, though it never names that sibling directly.
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 rather than stated: an agent can infer this is the reporting path for device telemetry, and the description clarifies what the watchdog does with it. There is no explicit when-to-use versus when-not-to-use guidance or reference to alternatives such as sentinel_device_command or sentinel_enforcement_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate the segmentation rules (portable JSON + nftables) that make the Sentinel broker the only reachable path to every registered device: default-deny inbound, no internet route to the devices, no device egress. Review before applying on the segment gateway.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the essential traits: the output comes in two concrete formats, the tool generates rather than applies changes, and the generated rules enforce a specific deny-by-default posture. It leaves open edge behavior such as what happens with zero registered devices or whether output is deterministic, which keeps it short of a 5.
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 pairing the artifact with its purpose, followed by a short clause on the resulting policy semantics and one operational caveat. No filler, no restatement of the tool name.
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 zero-parameter generation tool with no output schema, the description supplies the return formats and the policy contents, which is what an agent needs. The only gap is that the actual structure of the JSON plan is not sketched, so an agent cannot predict field names before calling.
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 tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter schema applies. The description correctly implies the plan is derived entirely from existing registered-device state rather than caller-supplied arguments.
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?
Uses a specific verb ('Generate') plus a concrete artifact ('segmentation rules' in portable JSON and nftables) and spells out the resulting policy posture: broker-only path, default-deny inbound, no internet route, no device egress. This distinguishes it cleanly from the sibling evaluation, explanation, audit, telemetry, command, and registration tools.
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 phrase 'Review before applying on the segment gateway' implies this is a generate-then-review-then-apply workflow, which hints at appropriate usage. It never states prerequisites (e.g. devices must be registered first) or when to prefer sentinel_explain_policy or sentinel_audit_status instead, so routing among siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a proposed AI-agent action against Sentinel policy BEFORE it executes. Returns a verdict of allow, hold (a human must approve first), or deny, with the risk score, the signals that fired, and reasons. Each evaluation is appended to a SHA-256 hash-chained audit log.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Plain-language description of what the agent proposes to do, including intent and target. | |
| context | No | Authorization context, e.g. "Authorized blue-team incident response on our own environment." | |
| history | No | Prior conversation turns; Sentinel scores escalation across turns, not just the latest request. | |
| requestedActions | No | Tool calls the agent wants to run, e.g. ["send email"], ["payment"], ["database write"], ["credential access"]. Consequential actions are gated independently of content risk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does well: it discloses the three possible verdicts (allow, hold, deny), that hold requires human approval, and — importantly — that every call is persisted to a SHA-256 hash-chained audit log, which is a real side effect an agent must anticipate. It stops short of stating auth requirements, latency, or whether evaluations are rate-limited.
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?
Three sentences, front-loaded with the action and its timing constraint, followed by the return values and then the audit side effect. No filler or restatement of the title.
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?
There is no output schema, so the description usefully names what comes back — verdict, risk score, fired signals, reasons — and the persistence behavior. Given the absence of annotations and the 100% schema coverage on inputs, the only real gap is operational context (permissions, failure modes, what a hold verdict requires of the caller procedurally).
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 100%, so all four parameters (action, context, history, requestedActions) are already documented in the schema, including the rationale for escalation scoring and independent gating of consequential actions. The description adds no parameter-level meaning beyond that, 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 gives a specific verb and resource ('Evaluate a proposed AI-agent action against Sentinel policy') plus the decisive scoping detail 'BEFORE it executes,' which distinguishes it from siblings like sentinel_explain_policy or sentinel_audit_status that inspect policy or logs rather than gate an 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 timing condition 'BEFORE it executes' is a clear usage cue, so an agent knows this is a pre-flight gate rather than a post-hoc audit check. However, it never names alternatives or exclusions — e.g., that sentinel_explain_policy should be used to understand a deny verdict, or when to skip evaluation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain how Sentinel scores a proposed action, the verdict thresholds, the independent action gate for consequential tool calls, and the signal categories it looks for.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It discloses the subject matter it explains, which is the key behavioral fact, but does not state that it is a read-only, side-effect-free documentation lookup, nor what form the explanation takes. For a zero-parameter explain tool the risk is low, so the gap is modest rather than serious.
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 with no filler; every clause names a concrete topic the explanation covers. The enumerated list is slightly dense but each item earns its place by telling the agent what knowledge it can obtain.
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?
There is no output schema, so the description must convey what comes back, and it does so by listing the four subject areas the explanation covers. That is adequate for a no-input documentation tool, with the only shortfall being no hint about depth, format, or how to apply the returned policy.
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 tool takes zero parameters, so there is no parameter semantics to add and the baseline of 4 applies. The description correctly implies no input is needed by framing the tool as a pure explanation of policy.
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?
States a specific verb ("Explain") and a specific resource (the Sentinel evaluation policy), then enumerates the four topics covered: scoring, verdict thresholds, the independent action gate, and signal categories. This makes it clearly distinct from the action-executing siblings like sentinel_evaluate_action, though it never names an alternative explicitly.
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 only implied — an agent can infer this is the reference-reading tool to consult before or alongside sentinel_evaluate_action, but the description never says when to call it, when not to, or that it takes no input and produces no side effects. No exclusions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enroll a legacy/OT device (refrigeration controller, PLC, building system) that cannot route actions through the agent gate. Once registered, commands to it are accepted only through the NetGuard broker, inside its hard safety limits, and its observed state is watched for tampering.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stable device id, e.g. "store-114-freezer-ctrl-1". | |
| kind | Yes | Device class, e.g. "refrigeration-controller". | |
| name | Yes | ||
| address | Yes | IP or host on the protected segment. | |
| commandPort | Yes | ||
| hardLimitsC | Yes | Hard setpoint safety limits in °C. Brokered commands outside are denied outright. | |
| normalBandC | Yes | Normal operating band in °C. Outside it but within hard limits: held for a human. | |
| maxDefrostMinutes | Yes | Longest defrost the broker will hold for approval. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well on consequences: commands are only accepted through the broker, hard safety limits deny out-of-range commands, and observed state is monitored for tampering. It says nothing about required permissions, whether re-registering an existing id is idempotent or overwrites, or what happens on a conflicting address/port — meaningful gaps for a state-creating 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?
Two tight sentences, zero waste, with the enrollment target and its constraint front-loaded before the post-registration behavior. Nothing is repeated from the schema or title.
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 an 8-parameter, all-required enrollment tool with nested objects, no annotations, and no output schema, the description covers purpose and enforcement semantics well but omits prerequisites, idempotency/conflict behavior, and any hint of what a successful enrollment returns. An agent would still need to guess at error and re-registration handling.
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 75%, so the schema already documents the key fields, including the semantics of hardLimitsC, normalBandC, and maxDefrostMinutes (deny outright / held for a human / held for approval). The description adds no field-level meaning beyond that — commandPort, address, name, and the relationship between hardLimitsC and normalBandC are left entirely to the schema.
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?
States a specific verb (enroll/register) and a precisely scoped resource: legacy/OT devices that cannot route actions through the agent gate, with concrete examples (refrigeration controller, PLC, building system). That scoping naturally separates it from sentinel_device_command (act on a device) and sentinel_device_telemetry (observe one).
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?
Gives a clear condition for use: the device is legacy/OT and cannot route actions through the agent gate. The implied exclusion of already-gated devices is strong, but no sibling is named as the alternative path for those devices, so the routing decision still requires inference.
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.
v0.1.0sentinel_audit_statussentinel_device_commandsentinel_device_telemetrysentinel_enforcement_plansentinel_evaluate_actionsentinel_explain_policysentinel_register_deviceScored across 7 tools
Each tool targets a clearly distinct operation: agent-action evaluation, policy explanation, audit-log status, device command evaluation, enforcement planning, device enrollment, and device telemetry. The only nearby pair is sentinel_evaluate_action and sentinel_device_command, but the descriptions sharply separate generic AI-agent actions from NetGuard device commands.
All tools use the same sentinel_ prefix and snake_case style, which makes the set predictable. However, several names are noun phrases (sentinel_device_command, sentinel_enforcement_plan, sentinel_device_telemetry) rather than a consistent verb_noun pattern.
Seven tools is well-scoped for the server's purpose, covering policy evaluation, device control, registration, telemetry, enforcement planning, and audit verification without obvious redundancy. Each tool appears to earn its place in the workflow.
The core lifecycle is covered: evaluate actions and device commands, explain policy, enroll devices, inspect telemetry, generate enforcement rules, and verify audit integrity. Minor gaps remain, such as listing or unregistering devices and retrieving audit entries or incident details, but agents can still execute the main security workflows.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Human-in-the-loop review and approval for AI agents. Audit trail, approval policies, native MCP.
MCP enforcement layer that intercepts AI agent actions and blocks rule violations before execution.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.