Audits all changes between base and head branches in CI, ensuring each has a pandaone write record before merge.
CI 审计验证：对比 base..head 的所有改动，确认每条变更都通过 pandaone write 审计
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | 基线分支 | origin/main |
| head | No | 对比分支 | HEAD |
| root | Yes | . |
Changes observed during successful MCP inspections.
v0.7.14Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context: it diffs all changes in the range and verifies each against the pandaone write audit. It does not mention failure/exit behavior, but safety characteristics are covered by annotations.
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 compact sentence conveys purpose, scope, and audit criterion without filler. The tool's role is front-loaded and every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent audit tool with defaults for base and head, the description is mostly sufficient for selection and invocation. However, there is no output schema and the description does not state what happens when an audit fails or what the tool returns, leaving some ambiguity for CI result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful relational meaning by showing that base and head define the comparison range ('base..head'). However, schema coverage is 67% and the root parameter lacks a description in both the schema and the tool description, so parameter semantics are only partially compensated.
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 action and resource: CI audit validation that compares base..head and confirms every change passed pandaone write audit. This clearly distinguishes the tool from siblings like pandaone_write (the audited operation) and pandaone_status.
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 'CI 审计验证' framing gives an explicit context for when the tool is appropriate, and the base..head comparison defines its operational scope. It does not name alternatives or exclusions, but the intended usage is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.