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

With no annotations provided, the description carries the full transparency burden. It discloses deterministic generation via a provided seed, the CSPRNG option when use_random_seed is true, and the complete set of output fields. It also names the standard and NIST security levels. However, it omits potential error conditions and side-effect behavior, which would be useful for a tool that generates sensitive key material.

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 well-organized into labeled sections (algorithm, parameters, outputs, subsequent operations), with every sentence contributing necessary information. It is compact enough for an agent to parse quickly while providing a complete overview of the tool's behavior.

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?

Given there is no output schema, the description compensates by enumerating all nine output fields and explaining the downstream workflow. It covers algorithm selection, parameter semantics, and output formats. Minor gaps include lack of error-handling details, but overall the tool description is contextually complete for a key generation operation.

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 schema already describes all three parameters with high coverage (100%), so the baseline is 3. The description adds value beyond the schema by noting that seed_in_hex enables deterministic generation, that use_random_seed overrides the seed, and by mapping each algorithm choice to a NIST security level—additional context not present in the schema descriptions.

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 clearly states its core function with a specific verb and resource: '生成 ML-KEM 密钥对' (generate ML-KEM key pair) and names the FIPS 203 standard. This distinguishes it from sibling operations like ml_kem_encap and ml_kem_decap, which are explicitly referenced as downstream uses for the generated keys.

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 provides clear guidance on when to use this tool by explaining the algorithm options (with a recommendation for ML-KEM-768) and specifying that the public key is used for ml_kem_encap and the private key for ml_kem_decap. It does not offer explicit 'when-not-to-use' exclusions, but the downstream workflow makes the usage context unmistakable.

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