YAFL — Yet Another File Layer (MCP server + CLI) vs Obsideo MCP

A side-by-side look at the YAFL — Yet Another File Layer (MCP server + CLI) and Obsideo MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

YAFL — Yet Another File Layer (MCP server + CLI) logoYAFL — Yet Another File Layer (MCP server + CLI)File Systems · Local subprocess (stdio)Agent-first E2EE file transfer over MCP: move files between machines in one tool call, gone in 24h.59GoodAuth: not declaredObsideo MCP logoObsideo MCPFile Systems · Local subprocess (stdio)Encrypted S3-compatible object storage with continuous cryptographic possession proofs. In-conversation signup (12 GB free), put/get/ls/rm/usage, optional client-side encryption; credentials stay on your machine.63GoodAuth: not declared

Verdict: choose YAFL — Yet Another File Layer (MCP server + CLI) for file systems work as a local process; choose Obsideo MCP for file systems as a local process. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

YAFL — Yet Another File Layer (MCP server + CLI) logoChoose YAFL — Yet Another File Layer (MCP server + CLI) when

  • You need dedicated capabilities in the File Systems domain.
  • You prefer a local stdio subprocess transport.
  • You want tools like upload_file, get_status, download_file.
Explore YAFL — Yet Another File Layer (MCP server + CLI)

Obsideo MCP logoChoose Obsideo MCP when

  • You need dedicated capabilities in the File Systems domain.
  • You prefer a local stdio subprocess transport.
  • You want tools like trial, signup_start, signup_verify.
Explore Obsideo MCP

Feature & specification comparison

Rows where the two servers differ are marked.

SpecYAFL — Yet Another File Layer (MCP server + CLI) logoYAFL — Yet Another File Layer (MCP server + CLI)Obsideo MCP logoObsideo MCP
CategoryFile SystemsFile Systems
Quality signal59/100 · Good63/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthNot declaredNot declared
PricingNot declaredNot declared
Required env varsNone listedNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars00
Directory activity 3 views 0 installs 0 upvotes 2 views 0 installs 0 upvotes
Tools713

Tools & capabilities

YAFL — Yet Another File Layer (MCP server + CLI) tools 7

  • upload_fileEncrypts and uploads exactly the file or directory at the given local `path` (absolute, or relative to the current working directory). A directory is zipped client-side into a single archive before upload. Reads only that one path – never scans unrelated files or directories. Returns a shareable link (24h expiry, 100MB cap) with the decryption key embedded in the URL fragment; the key is never sent to the API. Optionally make the link one-time (burned after the first download) or password-protected.
  • get_statusChecks whether the YAFL share link at the given `url` is still live — live, expired, or not found — without downloading or decrypting anything. Returns liveness, size, and expiry only. Does not read the decryption key even if present in the URL fragment, and never fetches any file bytes.
  • download_fileDownloads and decrypts exactly the one file referenced by the given YAFL share `url`, writing it only into `destDir` (default: the current working directory) — never anywhere else. Requires the decryption key embedded in the URL fragment; the key is used only locally to decrypt and is never sent to the API. No YAFL API key is required for retrieval — anyone holding the link can download it; only uploading or managing files requires a key. Optionally pass a `password` for password-protected links.
  • list_filesLists the caller's OWN YAFL transfers only — metadata only (id, size, status, expiry, and a download path). Never returns file contents, never a decrypted name, and never another account's files. Optionally cap the number of results with `limit`.
  • delete_filePermanently deletes ONE of the caller's own YAFL transfers, identified by `id` (a bare transfer id or a full share URL — the fragment/key, if present, is never read). This cannot be undone: the R2 object is purged and the transfer record is removed. Destructive action.
  • email_linkEmails this YAFL share link to a recipient. The link carries the decryption key in its fragment – anyone with access to that inbox can open the file. Requires a verified account.
  • loginStarts a device-code login for an MCP agent that has no shell. Returns a verification URL and a short user code for the human to open and approve in a browser; approving is a one-time email-link sign-in that proves the human controls the account. This tool does NOT open a browser itself - relay the returned URL and code to the human. Once approved, the minted API key is stored locally and subsequent tool calls in this session authenticate automatically, with no further action needed.

Obsideo MCP tools 13

  • trialCreate a free Obsideo account with no email and no human in the loop: a small proof-of-work and a ~10 second wait in place of identity. Returns a real account on the production network (100 MB, about 7 days, RF=3 replication, continuous possession proofs) and saves credentials locally. You usually do NOT need to call this: the first put/get/ls/usage auto-creates a trial if no account is configured. Call it to provision explicitly. To keep data beyond the trial, claim it with an email via signup_start (same account and data, quota rises to 12 GB). Takes about 15 to 30 seconds (proof of work plus a 10 second issuance window); progress is reported while it runs.
  • signup_startStart Obsideo signup: emails a 6-digit verification code (12 GB free tier, no card, no expiry). If a no-email trial is configured on this machine, this CLAIMS it in place: same account, bucket, keys and data, only the quota rises. Otherwise it creates a new account for the email. Use a real inbox you or your human can read; documentation placeholders and disposable domains are refused with labeled errors. Then call signup_verify.
  • signup_verifyComplete signup with the emailed code. When claiming a trial, nothing but the quota and the identity changes (credentials stay valid, no propagation wait). For a new account, generates the Ed25519 account signing keypair locally (only the public half is sent) and stores S3 credentials in ~/.obsideo/mcp.json; re-running that path rotates credentials and keypair with no overlap, so do not re-run to retry.
  • putStore a local file or inline content as an object. ENCRYPTED BY DEFAULT: the bytes are encrypted client-side with AES-256-GCM using a locally generated, user-held key before they leave the machine, so the platform stores ciphertext it cannot read. The key lives only in the local config file and Obsideo has no copy: if the user loses it the data is unrecoverable, so tell them to back it up. Pass encrypt=false only when another tool must read the stored bytes directly (S3 interop); that stores plaintext. Zero-byte objects are rejected. Objects are replicated to 3 providers and verified on a continuous cryptographic challenge cycle. The first call on a fresh machine also creates the account and can take 20 to 50 seconds; progress is reported while it runs. Encrypted objects are readable only with this machine's key: there is no cross-user sharing of encrypted objects.
  • getRetrieve an object. Encrypted objects (the default for anything stored through this server) are decrypted automatically with the local key; retrieval from a machine without that key will fail, which is the intended property. Small text objects return inline; pass local_path for anything else. WRITES TO DISK: passing local_path writes the bytes to that path and overwrites any existing file there, so treat it as a write operation and confirm the path with your human first.
  • lsList stored objects (size TAB key), optionally under a prefix.
  • rmDelete an object by key.
  • verifyIndependently verify that the network still holds an object, without downloading it. Challenges each provider directly and compares every answer, on this machine, against a merkle root. For objects stored through this server, that root is the one this machine recorded at upload time, if the local record still has it. Pass local_path (your copy of the stored file) to compare against a root computed from that file instead. If neither is available, it falls back to the coordinator's recorded root and says so. The coordinator chooses which providers to ask, where to reach them, and the public keys their signatures are checked against. Returns how many providers proved possession right now, how many of those answers were signed, and whether any returned bad data.
  • usageShow account storage usage versus quota.
  • planShow the account's plan: free tier or paid blocks (200 GB per block, $5/month each), status, period end, and any upgrade offer waiting for the human's agreement. Never changes anything and never contacts Stripe.
  • upgradeGet a Stripe-hosted checkout link for a paid plan of N x 200 GB blocks at $5/month per block. This tool charges NOTHING and changes nothing: the human opens the link and pays on Stripe's page, and the quota rises after payment. Call it only when the human has asked for more space, and hand the link back to them; do not open or submit it yourself. If the account already has a paid plan this returns the plan instead (plan size is never changed from here; only the human's click on Obsideo's emailed agree link does that).
  • portalGet the Stripe Customer Portal link for a paid plan: cancel, change card, download invoices. For the human to open. Cancelling keeps everything stored and readable; the account returns to its free quota at the end of the paid period.
  • +1 more on the listing page

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

YAFL — Yet Another File Layer (MCP server + CLI)

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "mcp-175": {
      "command": "npx",
      "args": [
        "-y",
        "@yafldev/mcp"
      ]
    }
  }
}

Obsideo MCP

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "regan-milne-obsideo-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "obsideo-mcp"
      ]
    }
  }
}

Frequently asked questions

YAFL — Yet Another File Layer (MCP server + CLI) is categorized under File Systems and uses a local stdio subprocess. Obsideo MCP belongs to File Systems and uses a local stdio subprocess. Pick YAFL — Yet Another File Layer (MCP server + CLI) for file systems work and Obsideo MCP for file systems.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

YAFL — Yet Another File Layer (MCP server + CLI) has no declared pricing — check the project's own site. Obsideo MCP has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add mcp-175 and regan-milne-obsideo-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, YAFL — Yet Another File Layer (MCP server + CLI) has a quality signal of 59/100 (Good) with 3 views, 0 installs and 0 GitHub stars. Obsideo MCP has 63/100 (Good) with 2 views, 0 installs and 0 GitHub stars.