Server Quality Checklist

Tool Scores

• sentinel_run_attackC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations at all, the description carries the full burden of behavioral disclosure. It doesn't state whether the attack actually mutates state (e.g., whether tool_poisoning permanently rewrites the tool description or restores it afterward), whether this requires prior demo setup, whether it's reversible, or what effects it has on the demo environment. The security-demonstration purpose is clear but the side effects are not.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one dense but efficient sentence followed by a scenario list. The scenarios are enumerated inline rather than as formatted bullet points, but it's compact and front-loaded with the core purpose first. All content earns its place, though the scenario explanations could be slightly more structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a demo/attack tool in a broader demo suite with many siblings (setup_demo, setup_demo_policies, run_full_demo, reset_demo). The description doesn't clarify the order of operations relative to these tools, whether state is permanently mutated, or what observable outcomes the agent should expect. No output schema and no annotations leave substantial gaps for a tool that mutates demo state.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a single enum-backed parameter, and the description reiterates the four scenario options with brief parenthetical explanations. This adds marginal clarity (explaining what each scenario does), but the schema already enumerates all options. The description gives no guidance on which scenario suits which demonstration goal beyond the one-line explanations. Baseline 3 is appropriate given full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb and resource: 'Run a simulated attack scenario to demonstrate Sentinel Gateway's security capabilities.' It lists the four specific scenarios with brief explanations of each. However, it doesn't explicitly distinguish from sibling tools like sentinel_run_full_demo or sentinel_setup_demo, though the attack-focused purpose is reasonably distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description enumerates the available scenarios but provides no guidance on when to choose this tool over sentinel_run_full_demo, sentinel_setup_demo, or sentinel_reset_demo. It doesn't mention prerequisites (e.g., whether setup_demo must run first) or when this is appropriate vs. running the full demo.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_check_agent_accessB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. The description doesn't state whether this is read-only, whether it makes external side effects, whether it requires prior registration of the agent/server, or what the 'policy decision' response shape looks like. For a tool that evaluates policy, it doesn't clarify how the policy is sourced or whether the test triggers rule evaluation or just looks up precomputed state.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with zero waste: states what it does, what it takes, and what it returns. Front-loaded and to the point.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, no annotations, and a tool that returns a policy decision and reason, the description should explain more about the return shape, whether the check is against live or cached policy, error behavior if the agent/server doesn't exist, and side effects. The tool is relatively simple (3 params, all strings), but the absence of any behavioral or output detail makes it incomplete for pre-flight decision-making.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter (agentId, serverName, toolName) already has a clear description. The tool description adds the conceptual context that these three parameters together represent a test request. Given full schema coverage, baseline is 3; the description slightly elevates by framing what the parameters accomplish together.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool tests whether a specific agent can call a specific tool, and returns a policy decision and reason. It uses a specific verb ('Test') with a clear resource (agent access to a tool). Among siblings like sentinel_add_policy_rule or sentinel_call_tool, this is well differentiated as a policy-checking operation, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says what the tool does but provides no guidance on when to use it versus alternatives. For example, it doesn't clarify how this check differs from making an actual call (sentinel_call_tool), whether it should be used to pre-validate before calling, or when policy review vs. direct testing is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_list_serversB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. The description indicates this is a read-only listing operation by its verb ('List'), but it doesn't disclose what 'connection status' means, whether this triggers any connection checks (potentially a non-trivial network operation), or what the return format looks like. With zero annotation coverage, more explicit behavioral detail would be warranted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence, zero wasted words, and front-loaded with the purpose. It efficiently conveys action, scope, and result. There is nothing to trim.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple list operation with no parameters and no output schema, so it doesn't need extensive documentation. However, without annotations or an output schema to fall back on, some mention of what fields/status values the listing contains would improve completeness. The description is adequate but leaves the returned status vocabulary to the agent's imagination.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema does no work and the description isn't required to explain anything. With 0 params the baseline is 4, and the description properly focuses on what it returns rather than parameters, keeping expectations clear about the no-input nature of the call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') with a clear resource ('registered downstream MCP servers') and states the scope ('all'). It also adds connection status as the informational payload. It doesn't explicitly distinguish from siblings like sentinel_list_tools, but the resource is specific enough (servers vs tools) that confusion is unlikely.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. With siblings like sentinel_list_tools and sentinel_get_dashboard_stats, an agent might wonder which listing tool to choose. However, the resource name (servers) makes the intent fairly unambiguous, and there are no exclusions, prerequisites, or context cues provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_list_policy_rulesB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden of behavioral disclosure. 'List all' implies a read-only operation, which is safe, and the tool name supports that. However, it doesn't disclose pagination, ordering, output format, or whether listing all rules has any performance implications. It's a read operation which is fairly self-evident, but details about result structure are absent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with zero wasted words. The description states the core purpose and the optional filter in a compact, front-loaded manner. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one fully-described optional parameter and no output schema, the description is reasonably complete. However, it doesn't mention what a policy rule looks like or any context about which other sentinel tools relate to policy rules (e.g., check_agent_access). The simplicity of the tool means the description covers the essentials, but a brief note on return contents would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — the single agentId parameter is fully described ('Filter rules by agent ID'). The description adds marginal value by mentioning it first in prose, but the schema already documents it completely. The baseline 3 applies since the schema does the heavy lifting for the single parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (list), resource (RBAC policy rules), and optional filter (by agent ID). It distinguishes from siblings like sentinel_add_policy_rule and sentinel_remove_policy_rule since those are mutation operations while this is a read/list operation, though it doesn't explicitly call out that distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool vs alternatives. The tool name and description imply it's for viewing policies, and the optional agentId filter suggests targeted queries, but there's no mention of when to filter vs. list all, nor any reference to sibling tools like sentinel_get_review_queue or sentinel_query_ledger that might also be relevant in certain contexts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_list_toolsB
  3.3/5.0
  Behavior2/5

  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 names list output fields (fingerprint status, trust level) but doesn't state whether this is a read-only operation (likely given 'list'), whether it requires any auth/permissions, whether it hits all registered servers or follows any ordering/pagination, or what the response format looks like. For a listing tool this is moderately critical since agents may rely on it to understand what tools exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single clear sentence that front-loads the purpose and adds the relevant returned fields. Zero wasted words, no redundancy with the name or schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with one optional parameter and full schema coverage, the description is reasonably complete. However, the lack of any annotation coverage shifts more burden onto the description to state read-only safety and whether tool access is gated, which it doesn't address. The output schema is absent, so return-format details beyond the two named fields are unknown, though that's partially reasonable for a list endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single optional parameter 'serverName' is described as 'Filter by server name' in the schema. The tool description adds the queryable scope ('all registered servers'), which aligns with the filter parameter but doesn't add meaning beyond the schema. Baseline of 3 is appropriate when schema already documents the parameter well.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description has a clear verb+resource ('List all discovered tools') with meaningful scope ('across all registered servers'). It specifies what's included ('fingerprint status and trust level'), which adds useful detail. It's related to sentinel_list_servers but describes a distinct resource (tools vs servers), so the differentiation is mostly implicit rather than explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is a discovery/listing tool useful for browsing available tools, but there's no explicit statement of when to use this versus alternatives like sentinel_list_servers or sentinel_list_policy_rules. The context is clear enough but no exclusions or alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_run_full_demoB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. The description presents a sequence of actions but doesn't disclose side effects: does this write to state? Does it mutate demo data? Is it idempotent? Does it require servers to already be registered? The absence of any notes about state changes, side effects, or prerequisites is a substantial gap for a tool that triggers a multi-stage sequence.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, efficient and to the point. The pipeline breakdown adds useful detail without bloat. Minor redundancy: 'complete demo sequence' and 'full security pipeline in action' restate similar ideas, but overall it's concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless tool with no output schema, the description does a reasonable job explaining what the sequence covers (the five stages). However, it doesn't mention what the output/return looks like (dashboard link, log, status), expected duration, or whether partial failures are handled. Given the orchestration nature, more detail on expected outcome would help complete the picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, so there's nothing to add beyond what the schema provides. The description clarifies what the tool does without needing parameter documentation. A baseline 4 is appropriate for a parameterless tool since the schema-coverage baseline doesn't apply.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is clear about what the tool does: runs a complete demo sequence with a specific pipeline of steps (setup servers → configure policies → normal traffic → tool poisoning attack → RBAC violation). The verb 'run' plus the resource 'complete demo sequence' is specific. However, it doesn't fully distinguish from siblings like sentinel_run_attack or sentinel_setup_demo, since the scope overlap isn't explicitly clarified.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is for when you want to run the full end-to-end security demo in one go. It shows the full pipeline in action, which suggests it's an orchestration tool rather than a targeted single-action tool. However, it provides no explicit guidance on when NOT to use it versus running individual steps (e.g., sentinel_setup_demo, sentinel_run_attack) separately, nor prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_add_policy_ruleB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states the core mutation (granting access) but doesn't disclose whether the operation is additive vs. replacive (e.g., what happens if the rule already exists), whether it requires prior server registration, idempotency behavior, or consequences if serverName/agentId don't exist. For a policy-mutating tool with zero annotation coverage, this is a significant gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, both earning their place. The first states the core purpose clearly, the second encodes the wildcard usage pattern. Zero waste, perfectly front-loaded with the action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 4-parameter policy tool with no annotations and no output schema, the description covers the primary function and the special wildcard case. However, it doesn't address edge behaviors like duplicate rules, missing agent/server, or what the response indicates. Given no annotations or output schema exist, the description should carry more of the behavioral burden, making this adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all four parameters. The description adds the critical wildcard semantics for toolName ("*"), which is beyond the schema's generic 'Tool name to grant access to, or "*" for all tools'. The maxAmount parameter is documented only in the schema but not elaborated in the description, though the schema covers it adequately at 100% coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Grant an agent access to a specific tool on a specific server.' It uses a specific verb (grant) with clear resources (agent, tool, server). While it doesn't explicitly name a sibling alternative, it's distinct from sentinel_remove_policy_rule (which is the inverse operation) and sentinel_check_agent_access (which checks rather than grants).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (when you want to grant tool access) but doesn't explicitly state when not to use it or reference alternatives. It does note the wildcard usage pattern ('Use toolName="*" to grant access to all tools'), which is helpful guidance. However, no exclusions or differentiation from the remove/check siblings is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_approve_reviewB
  3.4/5.0
  Behavior3/5

  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 does disclose the side-effect behaviors—that drift detection approval re-pins the fingerprint with a new description and injection approval permits the call—which are meaningful mutation consequences. However, it doesn't disclose what happens on failure, whether actions are reversible, or what the return value indicates about success/failure. This is a mutating approval action, so these are notable gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, one defining the general purpose and one covering the two behavioral variants. No fluff, no repetition of the schema. Efficient and readable, though the structure could optionally front-load the action and relegate nuance to a second sentence—which it already does effectively.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a mutation with side effects on separate systems (fingerprint re-pinning, call approval) and no output schema. The description covers the primary behaviors adequately but omits the return value, error conditions, and whether either action is reversible. For an approval gate with permanently consequential effects, this is a moderate gap. It's workable but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter (itemId is described as 'The review item ID to approve'). The description adds nothing about what a valid itemId looks like or where to obtain it, but with full schema coverage and a single self-explanatory parameter, the baseline of 3 is appropriate. The description's value lies more in explaining the tool's effects than in parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb+resource ('Approve a review item') and goes further to explain what approval means for two distinct review types (drift detections re-pin the fingerprint; injection flags allow the call to proceed). This adds meaningful specificity beyond the tool name. It doesn't explicitly differentiate from sibling sentinel_deny_review, but the reciprocal action is implicit from the opposing name—slightly weakening the differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that there are multiple review categories (drift detections, injection flags) and explains what approval does for each, which gives context on when to use it. However, it doesn't state when NOT to use this tool (e.g., when to use sentinel_deny_review instead) or any conditions under which approval is inappropriate, such as whether certain review types should never be approved. The exclusion guidance is absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_call_toolB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the burden. It discloses the security pipeline behaviors (fingerprint verification, RBAC enforcement, ledger logging) well. However, it doesn't disclose failure behaviors (what happens when verification fails, RBAC denial, or whether the call is blocked or audited on failure) or the return format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single dense sentence that front-loads the purpose and lists the pipeline stages efficiently. No wasted words. Could arguably benefit from a second sentence on failure behavior, but as written it's tight and informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a gateway routing tool with no output schema and no annotations, the description provides a good pipeline overview but lacks failure-path information (denials, verification failures, error returns). An agent needs to know what to expect when RBAC fails or the ledger write errors. Adequate but with a meaningful gap being a security-critical gateway tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all four parameters. The description confirms that args are forwarded downstream but adds little beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds marginal context about how args flow through the gateway.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear verb+resource ('Route a tool call through Sentinel Gateway's security pipeline') and lists the specific pipeline stages (integrity check, RBAC, provenance ledger, forward). It's distinguishable from siblings like sentinel_list_tools and sentinel_check_agent_access, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this is the gateway entry point for executing tools (vs. management tools like register/list/policy). However, it doesn't explicitly state when NOT to use it or what prerequisites exist (e.g., agent must be registered, policy rules must exist). The stage listing implies but doesn't spell out requirements.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_get_call_historyB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries more burden, yet it only mentions read-style behavior (get, return) with no additional behavioral context such as whether it returns only the current agent's calls, whether responses are ordered, default limits, or any scoping restrictions. The word 'get' implies read-only but there's no explicit confirmation of non-mutating behavior or auth requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with no waste. 'Get recent tool call history through the gateway, with status and timing information' is concise and front-loaded with the action and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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, and there are many data-retrieval siblings, so more completeness is expected. The description covers basic purpose and return content (status, timing) but lacks guidance on ordering, message formats, error behavior, or how it differs from ledger/history retrieval tools. It's minimally adequate but not rich.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents both parameters (limit as number of records, agentId as filtering). The description adds little beyond 'status and timing information' for return content, which complements the parameters but doesn't deepen understanding of limit semantics (e.g., maximum allowed) or agentId format.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'get' with resource 'tool call history' and adds scoping ('through the gateway') plus 'status and timing information' as return details. It clearly distinguishes from siblings like sentinel_query_ledger (ledger) and sentinel_get_dashboard_stats (stats). Loses a point for not contrasting against the broader audit/ledger tools which overlap in purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies it's for retrieving call history but provides no explicit when-to-use guidance or exclusions versus alternatives like sentinel_query_ledger or sentinel_get_dashboard_stats, which could overlap for audit purposes. There's no mention of pagination or typical usage scenarios. No exclusions are stated, which is a gap given multiple similar data-retrieval siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_get_dashboard_statsB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It names the categories of stats returned but never describes the return format (e.g., is it a JSON object with named keys?), whether it aggregates across all servers or a subset, whether it triggers any side effects, or what 'chain status' entails. For an unannotated read tool, this is thin.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence that front-loads the purpose and enumerates the returned stat categories. Every word earns its place with no padding or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (0 params, no output schema), so the description is reasonably complete for a straightforward getter. However, the lack of any return-format description could leave the agent guessing about the structure of the summary statistics, and there is no indication of what 'chain status' values look like. Acceptable but could add a brief return-structure note.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, and the description correctly reflects that no arguments are required. The baseline for 0 params is 4 since parameter semantics don't need compensation; there is nothing to explain. The description accurately implies a no-argument call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('Get summary statistics for the Sentinel Gateway dashboard') and lists the specific stats returned (total calls, blocks, drift detections, chain status). It distinguishes this from siblings like sentinel_get_call_history or sentinel_query_ledger, though it doesn't explicitly contrast itself with them. Clear and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is for dashboard summary viewing, but provides no explicit when-to-use guidance nor any exclusions/alternatives. With 18 sibling tools, there is no mention of when to favor this over sentinel_get_call_history, sentinel_query_ledger, or others. Usage is only implied by the dashboard-focused wording.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_query_ledgerB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden. It discloses that results are cryptographically linked and hash-chain validated, which is useful behavioral context. However, it doesn't describe pagination defaults (beyond the limit param), ordering, error behaviors, or whether results reflect near-real-time data. Adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single, efficient sentence that communicates the core purpose and a notable behavioral feature (hash-chain validation). No fluff. Could arguably add a second sentence on usage but is appropriately compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a query/filter tool with 4 optional params, 100% schema coverage, and no output schema, the description covers the basics but omits return-format expectations, ordering, depth of entries, and limit behavior. No output schema means the description should hint at what results look like; it only says they're 'cryptographically linked entries.' Adequate but incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — all four parameters (limit, status, agentId, serverName) have descriptions in the schema. The description adds no parameter detail beyond what the schema already provides, so baseline 3 is appropriate. It does not explain interactions among filters or special semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource ('Search and filter the provenance ledger') and adds a distinctive detail about returning cryptographically linked entries with hash-chain validation. However, it doesn't differentiate from sibling tools like sentinel_get_call_history or sentinel_verify_chain_integrity, which could overlap in purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context ('provenance ledger' querying) but provides no when-to-use vs alternatives guidance. It doesn't mention exclusions, preferencing, or when a sibling (e.g., get_call_history, get_review_queue) would be more appropriate. The format feature mention hints at use but no explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_register_serverB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose key side effects: the gateway will discover tools, fingerprint descriptions, and begin monitoring for drift. This is genuinely useful behavioral context. However, it doesn't describe failure modes (what happens if the URL is unreachable), whether re-registering an existing name overwrites or fails, or what the response shape is.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, zero filler. The description is efficient and front-loaded with the core action. It conveys the essential behavioral effects without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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, and it performs a registration with side effects (discovery, fingerprinting, drift monitoring). The description communicates these side effects well. However, given the lack of annotations and output schema, it could benefit from clarifying idempotency/re-registration behavior and the shape of a successful response. Still adequate for a reasonably understood registration operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so both `name` and `url` have good descriptions in the schema itself (including an example for each). The description adds no additional parameter-level detail beyond what the schema provides, so baseline 3 is appropriate per the guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource ("Register a new downstream MCP server with Sentinel Gateway") and clearly differentiates it from siblings like sentinel_list_servers and sentinel_call_tool. However, it doesn't explicitly distinguish from potential write operations like sentinel_reset_demo or sentinel_run_attack, though the registration framing is clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is an onboarding/setup operation, and the sibling list suggests sentinel_list_servers would follow to verify registration. However, there is no explicit 'when to use' guidance, no mention of prerequisites (e.g., server must be running/reachable), and no exclusions or alternatives named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_deny_reviewA
  3.5/5.0
  Behavior3/5

  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 does disclose the key behavioral trait: denial does NOT unblock — the block remains active. This is genuinely useful non-obvious context. However, it doesn't disclose whether denial is reversible, what happens to the review item afterward, or any permissions/auth requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with zero waste. The first establishes purpose, the second adds the critical behavioral caveat about the block remaining active. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with full schema coverage and a simple action, the description is reasonably complete. However, given the lack of annotations and no output schema, some additional clarity about what 'deny' does downstream (is the review item removed from the queue? is there any return value? is there an undo path?) would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning the itemId parameter is already documented in the schema ('The review item ID to deny'). The description adds nothing beyond what the schema already provides about the parameter, which hits the baseline 3 for full coverage. The description does not add meaning beyond the schema field.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Deny a review item' and the resource being acted upon. It distinguishes from the sibling sentinel_approve_review (the opposite action). It also adds useful context about the block remaining active, clarifying the consequence. It could name the sibling explicitly for stronger differentiation, but the purpose is clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage in the context of a review queue (sibling sentinel_get_review_queue), but it doesn't explicitly state when to use this vs approve_review or when NOT to use it. The consequence note ('the flagged tool/call stays blocked') provides some behavioral context but no explicit when-to-use guidance or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_get_review_queueA
  3.5/5.0
  Behavior3/5

  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 correctly identifies this as a read operation ('Get all items'). However, it doesn't disclose whether approval/denial mutations are required afterward, pagination or limit behavior, ordering, or whether results are restricted by status when defaulted. The mention that status defaults to 'all' provides some transparency about default behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two efficient sentences with zero wasted words. The purpose statement is front-loaded and the item types enumerate is valuable context. Nothing extraneous, though it could benefit from one brief usage note.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with one well-documented parameter and no annotations, the description is adequately complete. It defines the resource, the item types, and the approval workflow context. It's missing minor details like ordering/pagination, but for this tool's complexity level it doesn't feel significantly under-specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents the single status parameter. The description mentions that items 'need human approval' and implies the queue contains pending items, which adds slight context about what the status filter governs. But the description doesn't elaborate on the status parameter beyond what the enum already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (get) and resource (review queue items), enumerating specific content types (drift detections, injection flags, policy violations). It distinguishes itself well from siblings like sentinel_get_call_history and sentinel_get_dashboard_stats. However, it doesn't explicitly contrast against the approval/denial sibling tools, though the purpose is clear enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (when reviewing pending human-approval items) but doesn't explicitly state when not to use it or mention alternatives. The sibling tools sentinel_approve_review and sentinel_deny_review provide complementary context, but the description doesn't reference them or explain the workflow relationship.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_remove_policy_ruleA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the behavioral burden. 'Revoke' clearly signals a mutating/destructive operation on access permissions, which is disclosed. However, it doesn't state side effects such as whether revocation is immediate, whether it affects active sessions, or whether existing calls are impacted. The core mutating nature is disclosed but depth is absent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that states the complete purpose with zero wasted words. It immediately conveys the action and scope. Perfectly sized for a simple three-parameter revocation tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a straightforward three-parameter, no-output-schema mutation tool whose inverse sibling exists (add_policy_rule). The description is adequate for selecting the tool correctly. It could benefit from noting that a corresponding add operation exists as a sibling, but the simplicity of the operation means minimal additional context is required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all three parameters (agentId, toolName, serverName). The description adds value by confirming that toolName is specifically about revoking access to that tool, but it doesn't add syntax, format, or behavioral details beyond schema. Baseline 3 is appropriate when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description "Revoke an agent's access to a specific tool" clearly states the verb (revoke), resource (agent's access to a tool), and scope (specific tool). It distinguishes from the sibling sentinel_add_policy_rule which does the opposite. It doesn't mention 'policy rule' naming but the purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (removing an agent-tool permission) but provides no explicit when-to-use vs alternatives guidance. The sibling sentinel_add_policy_rule suggests an inverse relationship that a skilled agent could infer, but no alternatives are named or exclusions stated. Basic clarity without explicit context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_setup_demo_policiesA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It does convey a behavioral outcome: which agents get which access and that 'rogue-agent' gets no access. However, it doesn't disclose what happens to existing policies (are they overwritten? appended?), whether there are guardrails (e.g., requires pre-registered servers), or what the result/return looks like. The description gives the gist but misses potentially important side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, reasonably compact sentence conveying the full purpose. It could be slightly more precise (e.g., noting whether this resets existing policies), but it earns its place without verbosity. Front-loaded with the core purpose statement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter demo-setup tool with no output schema and no annotations, the description covers the essentials: what it does and the specific access grants. However, it lacks context about the interaction with sibling tools—notably whether sentinel_setup_demo subsumes this or whether this is a standalone setup requiring servers to be registered first (which sentinel_register_server hints at as a prerequisite). This gap could lead an agent to misuse the tool sequence.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add in terms of parameter meaning. The description appropriately focuses on what the tool does rather than parameter details, since there are none. The baseline 4 for zero-parameter tools applies here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: creating demo RBAC policies for demonstration. It specifies the verb ('Setup'), the resource ('demo policies'), and describes exactly what access each agent gets. It's clear but doesn't explicitly distinguish itself from sibling tools like sentinel_add_policy_rule or sentinel_setup_demo, which is partially handled by the action-oriented scope specified.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is for quick demonstration setup, naming 'sales-bot', 'data-analyst', and 'rogue-agent'. However, it doesn't explicitly state when to use this vs alternatives like sentinel_setup_demo (which seems like a broader sibling) or sentinel_add_policy_rule (which adds individual rules). The distinction between 'setup_demo_policies' and 'setup_demo' is unclear from the description alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_verify_chain_integrityA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden. It explains the underlying mechanism (each entry hash-chained to previous) and the outcome (detects tampering), which adds genuine behavioral context. However, it doesn't disclose side effects (presumably none as a check), return format, or failure behavior, though for a non-destructive verification tool the provided detail is reasonable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action verb and resource. The second sentence adds the mechanism explanation, which earns its place. No filler or unnecessary phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema verification tool, the description conveys the essential purpose and mechanism clearly. It explains what the check detects (tampering) and how (hash-chaining). It could mention what the return indicates (pass/fail) but given the absence of an output schema, this is a minor gap rather than a significant deficiency.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, so parameter semantics are trivially satisfied. The description's mention of the 'entire ledger' scope clarifies there are no options to narrow or filter, which aligns with the empty schema. This dimension has no real burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear verb ('Verify') with a specific resource ('cryptographic integrity of the entire provenance ledger'). It distinguishes the intent (detect tampering) but doesn't explicitly differentiate from sibling tools like sentinel_query_ledger, which could be a competing read/verification tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is a verification/audit tool to run when suspecting tampering, but provides no explicit when/when-not guidance or mention of alternatives. The context is reasonably clear for a read-only check tool, but there's no guidance on when to run this vs sentinel_query_ledger or other ledger-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_setup_demoA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries some burden. It states the tool registers 3 servers with the gateway, which implies state mutation. However, it does not disclose what happens if servers already exist, whether this overwrites existing registrations, or whether it affects policy rules or other persisted state. The sibling sentinel_setup_demo_policies and sentinel_reset_demo suggest relationship to broader demo state that isn't disclosed here.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, both substantive. The first delivers the core function, the second contextualizes usage. No filler or redundancy. Could arguably drop the trailing clause, but it's brief enough that it doesn't hurt.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (0 params, no output schema) but has clear interactions with sibling tools like sentinel_setup_demo_policies, sentinel_run_full_demo, and sentinel_reset_demo. The description doesn't clarify ordering relationships or whether this tool should be run before/after those. For a setup/demo tool, understanding the sequence matters for correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, so there's nothing for the description to document about parameters. The description correctly reflects that no inputs are needed — it's a self-contained one-step operation. This is a baseline for a zero-parameter tool and the description handles it appropriately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states a specific verb+resource: registers 3 demo mock servers (filesystem, CRM, email) with the gateway in one step. It distinguishes itself as a batch/demo-setup operation versus the sibling sentinel_register_server which presumably does single registration. Slightly generic 'useful for demo initialization' but the specifics (3 named servers) make the purpose clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly frames this as a 'Quick setup' for 'demo initialization', signaling it's for demo scenarios rather than production use. It implies this is an alternative to registering servers individually via sentinel_register_server. No explicit when-not guidance, but the demo context is clearly communicated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sentinel_reset_demoA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the behavioral burden. 'Reset all mock servers to their original, clean state' conveys a destructive/state-changing operation and indicates what gets affected (all servers, restoring to original state). However, it doesn't disclose whether this is irreversible, whether it clears policies/rules added, or what the outcome/return looks like. It's adequately transparent for the reset action itself but lacks detail about what exactly is destroyed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded with the action ('Reset'), zero waste. Every word earns its place. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter reset tool with no output schema, the description covers the essential need: what it does and when to use it. It could add a note about whether review queues, call history, or ledger data are also cleared, but for the primary purpose of resetting mock servers, it's reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, so there's nothing for the description to document. With zero parameters, a baseline of 4 is appropriate per the rubric. The description doesn't need to add parameter semantics since the schema is complete at 100% coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb+resource: 'Reset all mock servers to their original, clean state after running attack simulations.' It distinguishes this from siblings like sentinel_setup_demo (which sets up the demo) and sentinel_run_full_demo. However, it doesn't explicitly contrast with sentinel_setup_demo, which could be confused as similar reset-type operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'after running attack simulations' gives clear context for when this tool should be used. It implies the workflow is run attack → reset. It doesn't explicitly name alternatives or exclusions, but the usage window is reasonably specified for a no-parameter reset tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.