io.github.daedalus/mcp-cryptography

by daedalus

Overview Schema Source Related Servers Discussions Admin

Python

Remote

rsa_encrypt

Use an RSA public key to encrypt data with OAEP padding. Result is base64-encoded ciphertext.

Instructions

Encrypt data using RSA with OAEP asymmetric_padding.

Args: public_key_pem: RSA public key in PEM format. data: String to encrypt (max ~446 bytes for 4096-bit key).

Returns: Base64-encoded ciphertext.

Raises: ValueError: If data is too large for the key size.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "public_key_pem": "<public_key_pem>",
      "data": "<data>"
    },
    "name": "rsa_encrypt"
  }
}

Input Schema

Name	Required	Description	Default
`data`	Yes
`public_key_pem`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Jul 30, 2026

TDQS

A4/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.