export_key

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

With no annotations provided, the description carries the behavioral burden. It explains that all wrapping material lives inside key_material, that TR-34 requires an ExportToken from get_parameters_for_export, and that ECDH is needed for AES-192/256. It does not mention permissions, side effects, or whether the key remains in place, but the main behavioral traits and dependencies are disclosed.

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 long but appropriately so for a complex union-shaped parameter. It is front-loaded with the when-to-use statement, followed by compact illustrative examples and a clean Args section. Every element serves a purpose, and the code blocks earn their 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?

All parameters, wrapping variants, prerequisites, and algorithm-specific guidance are covered. The only notable gap is the lack of any description of the response shape or required permissions, and since no output schema is provided, that information would have improved completeness. Still, the description is strong for a complex 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?

Schema description coverage is 0%, so the description must fully compensate, and it does. It defines export_key_identifier as ARN or alias, explains key_material as a single-member union with concrete JSON examples for every export method, and documents export_attributes as optional with named members ExportDukptInitialKey and KeyCheckValueAlgorithm.

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 an explicit trigger, 'Call this when distributing an APC-generated key to an external HSM or system,' and names the exact wrapping formats: TR-31, TR-34, RSA cryptogram, ECDH-derived, and AS2805. It also contrasts itself with import_key by noting there is no separate 'type' argument, making the tool's purpose unmistakable.

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 gives a clear when-to-use statement and routes to the required companion tool, get_parameters_for_export, for obtaining the ExportToken. It also explicitly distinguishes the key_material parameter from import_key, and notes ECDH is needed for AES-192/256, which helps an agent decide the correct export method.

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