rsa_encrypt

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

With no annotations, the description must disclose all behavioral traits. It mentions OAEP padding and a ValueError for oversized data, but does not state that OAEP makes encryption non-deterministic (ciphertext varies), which could affect usage. It also omits details on key validation or encoding of the input data. The description covers basics but lacks some behavioral nuance.

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 concise and well-structured: purpose in the first line, followed by Args, Returns, and Raises sections. Every sentence adds value, and the information is front-loaded. No wasted words.

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 the presence of an output schema (not shown), the description covers inputs, output format, and error handling. It lacks details on the OAEP hash algorithm and support for different key sizes, but these are secondary. For a cryptographic tool, it is fairly complete and sufficient for typical use.

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 coverage is 0%, so the description must compensate. It explains both parameters: public_key_pem as 'RSA public key in PEM format' and data as 'String to encrypt (max ~446 bytes for 4096-bit key)'. This adds crucial format and size constraints beyond the schema's type-only definitions. Could further specify encoding (e.g., UTF-8), but current detail is strong.

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 'Encrypt data using RSA with OAEP asymmetric_padding', specifying the algorithm and padding scheme. This distinguishes it well from siblings like rsa_decrypt, aes_encrypt, and fernet_encrypt, and uses a specific verb+resource.

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 a maximum data size limit for a 4096-bit key, giving some usage context. However, it lacks explicit guidance on when to use RSA over symmetric encryption or other asymmetric tools like rsa_sign, which is critical given the many sibling tools. The guidance is implied from the size limit but not made explicit.

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