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

With no annotations, the description carries the full burden and delivers: input validation semantics (trailing bytes rejected), tolerance for indefinite-length items, and explicit truncation behavior (structure_tree truncated with truncated=true above 20000 nodes or depth 64). It also warns that cbor2 applies built-in semantic decoding for tags 0/1/2/3, so wire-level form should be read from structure_tree.

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?

Bracketed section labels (【算法】【参数】【输出】【注意】) front-load the algorithm and constraints before parameters and outputs, which suits an agent scanning for call preconditions. It is dense and repeats the size/closure constraint already in the schema, costing some 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?

No output schema exists, so the description must enumerate return values, and it does: decoded_json (with byte/tag/semantic-tag forms), decoded_type, decoded_length, structure_tree field list, truncated, and warnings. Nothing needed to interpret a successful or truncated response is missing.

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?

There is only one parameter and schema description coverage is 100%; the schema already documents the hex-string format, the 1B~128KB range, and the single-item/byte-closed constraint. The description restates the same range and constraint rather than adding syntax or new semantics, so the baseline of 3 applies.

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 (decode) plus resource (CBOR byte stream) and the exact output artifact (JSON plus a per-field structure tree), citing RFC 8949. The decode direction is unambiguously distinct from the sibling cbor_encode.

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 【算法】 and 【注意】 sections define the operational preconditions clearly: definite/indefinite length both accepted, single data item required, byte-closed input, trailing bytes rejected. It never names an alternative tool (e.g. cbor_encode) or states when not to use it, so it stops short of a 5.

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