Generate public key from private key

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

The annotations indicate readOnlyHint=false, meaning this operation may have side effects, and idempotentHint=false, so repeated calls may produce different results. The description does not disclose any behavioral traits beyond the basic operation, such as whether it writes to storage, requires specific permissions, or has side effects. It does not contradict the annotations, but it also does not add value beyond them. Given that annotations already hint at non-read-only behavior, the description should provide context but does not.

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 short and front-loaded with the core purpose, but it is also redundant. The first sentence and the second sentence say essentially the same thing. It is concise in terms of length, but the repetition wastes the opportunity to add useful detail. It is not egregiously long, but it could be improved by replacing the second sentence with additional information.

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?

The tool performs a cryptographic operation with two parameters, one of which (keyPassword) is not described at all. There is no output schema, so the description should explain what the tool returns (e.g., the public key in a specific format) and any error conditions (e.g., invalid private key, wrong password). The description is severely incomplete for a tool that requires careful parameter handling. An agent would likely misuse this tool without additional guidance.

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 description coverage is 0% (the schema has no descriptions for parameters). The description mentions 'private key' but does not explain the parameters in detail. Specifically, the 'privateKey' parameter's format (e.g., PEM, OpenSSH) is not specified, and the 'keyPassword' parameter is not mentioned at all, leaving its role unclear (e.g., whether it is required for encrypted keys). With 0% schema coverage, the description must compensate but fails to do so, leaving the agent without essential semantics for two parameters.

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 restates the title almost verbatim: 'Generate public key from private key. Generates a public key from a given private key.' It does not add any new information about the tool's purpose beyond what the title already conveys. It is not a complete tautology, as it does mention 'from a given private key', but it lacks specificity about any additional context, such as the key types or formats involved.

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 no guidance on when to use this tool versus any alternatives. Among the sibling tools, there are related credentials tools such as detect_ssh_key_type and validate_ssh_key_pair, but the description does not mention them or any conditions for choosing this tool. The description implies it is used for generating a public key, but it does not clarify scenarios like when to use this vs. detect_ssh_key_type or validate_ssh_key_pair.

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