Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@erickwendel/ciphersuite-mcp Encrypt the message 'Hello there' with passphrase '12345'."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that provides AES-256-CBC encryption and decryption tools, a resource describing the algorithm, and a ready-to-use prompt — all runnable directly inside VS Code Copilot Chat.
Capability | Name | Description |
🔧 Tool |
| Encrypts any plain-text message with a passphrase |
🔧 Tool |
| Decrypts a previously encrypted message with the same passphrase |
📄 Resource |
| Returns details about the algorithm, key derivation, and output format |
💬 Prompt |
| Pre-built prompt that asks the agent to encrypt a message |
Algorithm: AES-256-CBC
Key derivation: scrypt(passphrase, fixedSalt, 32) — you pass any passphrase string; the server derives a strong 32-byte key automatically
Output format: <IV in hex>:<ciphertext in hex> — keep the full string to decrypt later
IV: a fresh random 16-byte IV is generated on every encryption call, so the same message encrypted twice produces different output
Related MCP server: cryptoseed-mcp
Python 3.11+
uv (recommended) or pip
uv syncor with pip:
pip install -e ".[dev]"Create (or open) .vscode/mcp.json in your workspace and add:
{
"servers": {
"ciphersuite-mcp": {
"command": "uv",
"args": ["run", "python", "-m", "ciphersuite_mcp"]
}
}
}Tip: You can also add this server to your user-level MCP config at
~/.vscode/mcp.jsonto make it available in every workspace.
Open the Command Palette (Cmd+Shift+P) and run Developer: Reload Window (or just restart VS Code).
Open Copilot Chat (Agent mode) and try:
Encrypt the message "Hello, World!" using the passphrase "my-secret-key"Decrypt this message: a3f1...:<ciphertext> using the passphrase "my-secret-key"Show me the encryption://info resourceThe agent will automatically call the appropriate tool and return the result.
The MCP Inspector lets you explore and test all tools, resources, and prompts interactively in a browser UI:
npx @modelcontextprotocol/inspector uv run python -m ciphersuite_mcpThis opens the inspector at http://localhost:5173 and connects it to the running server.
uv run pytestThe test suite covers:
Encrypting a message
Decrypting a message with the correct passphrase
Error: decrypting with the wrong passphrase
Listing the encryption://info resource
Fetching the encrypt_message_prompt
src/ciphersuite_mcp/
__init__.py
__main__.py # Entry point — connects the server to stdio transport
server.py # All tools, resources, and prompts are registered here
service.py # AES-256-CBC encryption/decryption logic
tests/
conftest.py # Shared MCP client fixture
test_mcp.pyCommand | Description |
| Start the server (used by MCP clients) |
| Run all tests |
| Run a subset of tests |
| Open the MCP Inspector UI |
Decrypt a message that was encrypted with the encrypt_message tool
| Name | Required | Description | Default |
|---|---|---|---|
| encryption_key | Yes | ||
| encrypted_message | Yes |
| Name | Required | Description |
|---|---|---|
| decryptedMessage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action (decrypts) and offers no details about error handling, key requirements, output format, or side effects. This is a significant gap for a tool that could fail on wrong keys or invalid input.
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 a single sentence with no fluff, front-loading the action and resource. It is appropriately concise for a simple operation, though it sacrifices depth for brevity.
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?
While an output schema exists, the description lacks essential context such as key format, error behavior, or any caution about invalid inputs. For a tool with two required parameters and no annotations, this is insufficient for confident invocation.
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 has 0% description coverage, so the description must explain the parameters. It does not mention encrypted_message or encryption_key at all, leaving the agent without any semantic guidance beyond the property names. This fails to add value over the schema.
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 states a specific verb (Decrypt), a resource (message), and explicitly ties it to the encrypt_message tool, which clearly differentiates it from its sibling. This meets the highest bar for purpose clarity.
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 gives a clear prerequisite: the message must have been encrypted with encrypt_message. This tells the agent when the tool is applicable, though it doesn't explicitly mention when not to use it or name the sibling as the encryption counterpart. Still, the context is clear enough to guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encrypt a message
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| encryption_key | Yes |
| Name | Required | Description |
|---|---|---|
| encryptedMessage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the operation and gives no information about output format, encryption algorithm, error behavior, or what happens with different key formats. For a security-sensitive operation this is a significant gap.
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 extremely short and avoids redundancy, which is structurally clean. However, it is under-specified rather than economically informative; it essentially restates the tool name and leaves all behavioral and parameter details to be inferred.
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 has only two straightforward parameters and an output schema exists, so the description is minimally usable. But for an encryption operation, key handling, expected encryption scheme, and output characteristics are important context that is entirely absent.
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%, and the description provides no additional meaning for the message or encryption_key parameters. The parameter names are self-explanatory, but the description does not compensate for the lack of schema documentation, such as expected key format, message encoding, or length constraints.
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 states a specific verb ('Encrypt') and resource ('a message'), making the core operation clear. It is differentiated from the sibling decrypt_message by semantic opposition, though it does not explicitly name or reference that sibling.
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 intended usage is implied by the tool name and the 'encrypt' verb, and the sibling is decrypt_message, so the context suggests when to use this tool. However, there is no explicit statement of when to use it instead of alternatives, no prerequisites, and no mention of key requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.1decrypt_messageencrypt_messageScored across 2 tools
The two tools have mutually exclusive and clearly defined purposes: one encrypts, the other decrypts. There is no possible confusion between them, as the operations are exact inverses and each description explicitly points to the other.
Both tool names follow a consistent verb_noun pattern (encrypt_message, decrypt_message). The naming is predictable and symmetrical, making the intent immediately obvious without needing to read descriptions.
With only two tools, the server covers a narrow but coherent feature set. While this is on the low end, it is not unreasonable for a dedicated cipher suite that aims to provide basic symmetric encryption and decryption. The count is thin, but not absurdly so for the stated scope.
The tool surface covers the fundamental encrypt/decrypt cycle, but lacks other expected operations in a cipher suite, such as key generation, rotation, or support for additional algorithms. For a simple utility, this might be sufficient, but it leaves notable gaps for real-world use cases.
Encrypted LangChain Session Agent
LLM Orchestration Agent (Cryptography)
Secure P2P File Transfer, Encrypted Chat & Communication | Decentralized P2P & AES-256-GCM encryption | Zero cloud logs. Zero registration. For humans and autonomous AI agents / MCP servers.
Production-grade cryptography toolkit with 31 MCP tools for classical, PQC, and KMS workflows.
