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

With no annotations provided, the description carries the full burden, and it is exceptionally transparent. It explains the two cryptographic code paths (GmSSL for GM certs, cryptography for RSA/EC/Ed25519), defines verified=false as a successful response with a reason taxonomy, clarifies that validity only affects time_status, and discloses the exact error condition for 'Certificate verify failed'.

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 front-loaded with the core purpose and scope, then adds dense but relevant implementation and response-semantics details. It is long, but nearly every clause contributes behavioral information an agent needs; there is only minor redundancy with the schema regarding sm2_id.

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 complex verification tool with no output schema and no annotations, the description covers the essential contract: accepted cert types, algorithm selection, response boolean/reason/time_status semantics, and error boundaries. It does not explicitly state that both PEM parameters are mandatory despite schema defaults of '', nor describe the exact output envelope, so a small gap remains.

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

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

Schema description coverage is 100%, and the schema already documents sm2_id's default, GM-only usage, size range, and PEM formatting for both certs. The prose adds algorithm-path context for sm2_id but does not materially change parameter semantics, so the baseline of 3 is appropriate.

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 opens with a specific verb and resource — '用 CA 证书验证终端实体证书' — and immediately narrows scope to single-level direct issuance. It explicitly excludes chain building and revocation checking, which distinguishes it from cert_parse and any broader validation tool.

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 concrete context: use this tool for one-level direct CA issuance verification, and it explicitly states what it does not do (no chain building, no revocation checking). It does not name a sibling alternative or say 'use X instead', so it stops just short of the top score.

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