sentinel_explain_policyExplains how Sentinel scores proposed actions, sets allow/hold/deny thresholds, gates consequential tool calls, and identifies the signals used for risk decisions.
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 arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does 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.