Skip to main content
Glama

static.md

by md.static
OverviewDiscussionsAdmin

Create an encrypted note from ciphertext

create_note_ciphertext

Creates an end-to-end encrypted note owned by the signed-in user from ciphertext made on the user's side, such as by the static.md E2E bridge, and returns its link without the key. The ciphertext is the note's first Yjs update, encrypted in the read_note_ciphertext format; static.md stores it as is and can't read it. The title is stored unencrypted. New notes open to anyone with the link, and only the full link with #key= decrypts them. Pro.

Input Schema

NameRequiredDescriptionDefault
titleNoShort title, stored unencrypted (static.md keeps the first 32 characters)
folderNoFolder to put the note in, such as "work/launch"; it is made if it doesn't exist yet. A folder the user already has can be given exactly as the list tools show it, spaces included. Default: the top level ("/")
ciphertextYesOne encrypted Yjs update: base64 of a 12-byte IV, the AES-256-GCM ciphertext and its 16-byte tag

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / folder / description
      Previous value: -"Folder to put the note in, such as \"work/launch\"; it is made if it doesn't exist yet. Default: the top level (\"/\")"New value: +"Folder to put the note in, such as \"work/launch\"; it is made if it doesn't exist yet. A folder the user already has can be given exactly as the list tools show it, spaces included. Default: the top level (\"/\")"
  2. Changed1 schema field changed
    • addedInput schema / properties / folder
      Added value: +{
+  "description": "Folder to put the note in, such as \"work/launch\"; it is made if it doesn't exist yet. Default: the top level (\"/\")",
+  "maxLength": 700,
+  "type": "string"
+}
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the annotations: the server stores the ciphertext as-is and cannot read it, the title is stored unencrypted, new notes are link-accessible to anyone with the full link, and only the portion carrying '#key=' decrypts. That tells an agent the security model and the consequence of leaking the link — none of which is in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and the ownership model, then the storage/access caveats, then the plan gate. Dense but nearly every clause carries information; a slightly shorter sentence on the Yjs update format would tighten it without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return value ('its link without the key') and its access semantics, covers storage behavior and the Pro requirement, and leaves parameter details to a fully documented schema. An agent has what it needs to call this correctly and to warn about link sharing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents title, folder, and the IV/ciphertext/tag format. The description only reinforces that ciphertext is the first Yjs update and title is unencrypted, adding little beyond what the schema states. Baseline 3 applies.

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?

States a specific verb and resource ('Creates an end-to-end encrypted note') plus the distinguishing input ('from ciphertext made on the user's side') and the distinguishing output ('returns its link without the key'). That separates it cleanly from create_note (plaintext) and write_note_ciphertext (writing to an existing note) without the agent needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is clearly implied: call this when you already hold ciphertext in the read_note_ciphertext format, produced client-side. It also surfaces a precondition (Pro plan) that gates invocation. It stops short of explicitly naming create_note as the alternative for plaintext or stating when not to use this tool.

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

All static.md toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources