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

No annotations are present, so the description carries the full burden. It does disclose useful traits: records are 'redacted' (privacy masking) and 'hash-chained' (tamper-evident/immutable), and 'Read' implies read-only. It omits auth requirements, ordering, pagination, and what happens at the tail boundary.

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 zero waste. Every word (redacted, hash-chained, recent) carries signal.

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?

An output schema exists, so return values need not be explained. However, with no annotations and an undocumented parameter, the description is thin for a tool whose 'limit' and tailing semantics are entirely unstated.

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 single 'limit' parameter has 0% schema description coverage, so the description must compensate and does not. 'Recent' hints that a cap exists but gives no meaning, default, or bounds for 'limit'.

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 (Read) and resource (audit records) with distinguishing qualifiers (recent, redacted, hash-chained). This clearly separates it from siblings like ops_list_hosts or ops_run_command, though it does not name 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?

No when-to-use, when-not-to-use, or alternative guidance is provided. 'Recent' weakly implies a tailing/monitoring use case, but the agent is left to infer everything about selection.

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

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

With no annotations, the description carries the full disclosure burden, and it usefully explains that SQLite state transitions, the exact digest, expiration, and remote agent nonce/signature are re-checked. It also states the safety invariant that calling the tool cannot bypass approval. It does not describe failure behavior, side effects, or required permissions, keeping 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?

The description is short and front-loaded: the first sentence states the action and gating condition. The remaining sentences add safety context without excessive length, though 'cannot bypass approval' slightly overlaps with the list of checks. Overall it is efficient and easy to scan.

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

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

The description covers the critical approval gate and validation checks, and an output schema exists so return values need not be explained here. But it omits how an agent obtains the required request_id, how to verify approval status beforehand, and what happens on failure. For a safety-critical execution tool, that leaves meaningful gaps.

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 only parameter, request_id, is not mentioned in the description at all, and schema description coverage is 0%. The parameter name implies a request identifier, but the description adds no meaning about where it comes from, its relation to the approved digest, or any format expectation. This is a clear gap for a one-parameter execution tool.

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: execute a request, gated on prior approval of an immutable digest. It also communicates the core constraint (cannot bypass approval), which helps distinguish it from a generic execution sibling like ops_run_command. It does not explicitly name or compare against sibling tools, so a 4 is appropriate.

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

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

The description gives a clear condition for use: the immutable digest must already be approved. However, it does not say when not to use it or point to alternatives such as ops_pending_approvals or ops_request_status for checking approval state. Usage is implied rather than fully instructed.

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

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

With no annotations, the description carries the full behavioral burden. It hints that secrets are excluded ("non-secret"), which is useful, but says nothing about permissions required, pagination, cost, or whether results are cached/live. For a zero-annotation tool this is a thin disclosure.

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, and the most important information (list + resource scope) comes first. It is arguably too terse, but nothing in it is wasted.

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?

An output schema exists, so return values need not be explained, and with zero parameters the schema side is trivially complete. The description adequately covers what the call returns, though the absence of any usage context leaves a small gap for a discovery-oriented tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter detail is expected or missing.

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 ("List") and resource ("server targets") and adds the scope of what is returned ("non-secret security posture"). This is clearly distinguishable from siblings like ops_run_command or ops_stage_script, though it does not explicitly name them.

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

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

No when-to-use guidance, no prerequisites, and no named alternatives. The description never says whether this is a discovery step before ops_run_command or an independent inventory call, leaving usage entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not state that this is a read-only operation, whether results are scoped to the caller or approver, or how the list is ordered or paginated. For a zero-annotation tool 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.

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

One short, front-loaded sentence with no filler; the resource and scope come first. It is efficient, though its brevity edges into under-specification rather than pure conciseness.

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

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

The tool is simple, the single parameter is optional, and an output schema exists so return values need not be described. However, the description says nothing about result scoping, ordering, or the limit parameter, leaving minor but real gaps for an agent deciding how to page through the queue.

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

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

Schema description coverage is 0%, and the description never mentions the single 'limit' parameter or its default of 50, so it fails to compensate for the undocumented schema. The only saving grace is that the parameter is optional with a sensible default.

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 ('List') and a well-defined resource ('requests waiting for human approval'), which is easy to distinguish from siblings like ops_run_command or ops_audit_tail. It does not explicitly contrast with the closest sibling, ops_request_status, so it stops short of a 5.

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 'waiting for human approval' implies the use case (checking the approval queue before executing), but there is no explicit when-to-use statement, no mention of alternatives such as ops_execute_approved or ops_request_status, and no exclusions.

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

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

With no annotations, the description carries the full behavioral burden, and 'Get' only weakly implies a read-only operation. It does not disclose permission requirements, whether status is cached/live, rate limits, or what happens for an unknown or expired request_id.

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?

One short, front-loaded sentence with no filler. However, the brevity edges into under-specification rather than tight expression, since nothing substantive follows the verb-resource statement.

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?

An output schema exists, so return-value explanation is not required, and the input surface is a single id. Still, the definition is thin for a status-polling tool sitting among several approval-related siblings that it does not disambiguate from.

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

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

Schema description coverage is 0% and the single required parameter (request_id) is documented in neither schema nor description. The phrase 'for a request' hints at the identifier but gives no format, origin, or validity constraints, so it fails to compensate for the coverage gap.

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 (Get) and a clear compound resource (approval and execution status for a request). This meaningfully distinguishes it from siblings like ops_pending_approvals (a list) and ops_execute_approved (a mutation), though it never names those alternatives 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?

There is no guidance on when to call this versus the sibling status/approval tools, no mention of prerequisites (e.g., having a request_id from a prior submission), and no stated exclusions. Usage can only be inferred from the name.

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

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

With no annotations, the description carries the full burden and does well: it discloses automatic execution for known read-only diagnostics, the external-approval gate for mutations, outright denial of unknown commands/shell launchers/pipelines/escape primitives, and that approval routing is not model-controlled. It omits whether the call blocks waiting for approval, timeout behavior, and rate limits.

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

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

The purpose is front-loaded in the first line and the policy statements are terse and information-dense. The closing DingTalk sentence is tangential to invoking this tool and is the one line that does not clearly earn its place.

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

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

An output schema exists, so return values need no explanation, and the behavioral policy for a high-risk command execution tool is covered well. The remaining gap is parameter-level guidance for host_id, cwd, and reason, which an agent needs to populate the required fields correctly.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and largely does not. It clarifies that 'argv' is a structured token array, but host_id, cwd, requester, and especially the required 'reason' (presumably the justification driving approval) are never explained. The DingTalk sentence adds an unrelated detail about delivery targets rather than parameter meaning.

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+resource ('Submit a structured argv command') and clarifies that input is a pre-tokenized argv rather than a shell string, which distinguishes it conceptually from a shell-execution tool. It does not explicitly name or contrast with siblings like ops_stage_script or ops_execute_approved, so it stops short of full sibling differentiation.

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?

It tells the agent what will happen for different command classes: read-only diagnostics may run automatically, mutations require external approval, and specific patterns are denied. However it never states when to choose this tool over ops_stage_script or ops_execute_approved, leaving the sibling-selection decision implied rather than guided.

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

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

With no annotations, the description carries the full burden and delivers real behavioral context: content is staged immutably, an exact-SHA256 approval request is generated, scripts are disabled by default on production, and privileged scripts are never auto-approved. It still omits permission/auth requirements and whether staging is idempotent, so it falls 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?

Two short, front-loaded sentences: the action leads, the policy caveat follows. Zero filler, and the most decision-relevant fact (this creates an approval request, not an execution) is stated first.

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?

An output schema exists, so return values need not be explained, and the behavioral posture is well covered. The large gap is the 0% parameter documentation for a 7-parameter tool with 5 required fields, which the description does nothing to close.

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% across 7 parameters (host_id, language, content, args, reason, cwd, requester), and the description explains none of them. 'Immutable script content' and 'exact-SHA256' hint at content handling but give no guidance on format, arg conventions, or the meaning of requester, leaving required fields undocumented.

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?

Specific verb+resource: 'Stage immutable script content and create an exact-SHA256 approval request' clearly states what the tool does. It implicitly distinguishes itself from execution-oriented siblings like ops_execute_approved and ops_run_command by framing the action as staging plus approval request, though it never names a 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?

'Scripts are disabled by default on production hosts' and 'never auto-approved' imply this is the prerequisite step before approval/execution, so usage is inferable. However, it never explicitly says when to choose this over ops_run_command or that ops_execute_approved is the follow-up, leaving the workflow to inference.

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