What can you do with this server?

This server gives MCP-capable agents durable, encrypted object storage with zero-setup trial accounts and optional verified retention. * Store files or inline content as objects via put, with client-side AES-256-GCM encryption by default. * Retrieve objects with get, auto-decrypting locally encrypted data or saving to a path. * List stored objects with ls, optionally filtering by prefix. * Delete objects with rm. * Prove providers still hold your exact bytes without downloading via verify. * Check storage usage versus quota with usage. * Create a no-email trial account automatically on first use, or via trial. * Sign up for a 12 GB free tier with signup_start and signup_verify using a real email address. * Manage all credentials and keys locally in ~/.obsideo/, with no server-hosted secrets.

How do I use Obsideo MCP server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Obsideo MCP server store my database backup in Obsideo" 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.

de en es ja ko ru zh

Obsideo MCP server

by Regan-Milne

Overview Schema Source Related Servers Discussions Admin

TypeScript

Obsideo MCP server

Give any MCP-capable agent (Claude Desktop, Claude Code, Cursor, Cline, ...) durable storage that is encrypted on your machine before it is uploaded and that you can independently prove is still held. Zero setup: the first put/get/ls auto-creates a free no-email trial account (100 MB, proof-of-work instead of identity), so storage just works with nothing to configure. Want more? Self-serve signup from inside the conversation upgrades to 12 GB free, no card, no CAPTCHA, no expiry.

Obsideo is S3-compatible object storage where every stored object is replicated to 3 providers and challenged with chunk-level merkle proofs on a continuous cycle; providers are paid only for proofs they pass. Paid tier: $15/TB-month, egress included.

Privacy posture (read this first)

This server runs on YOUR machine. Obsideo never hosts it. Credentials, the account signing key, and the encryption key live in ~/.obsideo/ and are sent nowhere except the endpoints they authenticate against.
The account signing key is generated locally; only the public half is ever sent. Keep ~/.obsideo/signing.pem private. Re-running signup rotates credentials and the keypair with no overlap, so do not re-run casually.
Encrypted by default. put encrypts client-side (AES-256-GCM) with a locally generated, user-held key before anything leaves the machine, so the platform stores ciphertext it is architecturally incapable of reading. Pass encrypt: false only when another tool must read the stored bytes directly (S3 interop).

Back up your key

The encryption key is generated on your machine on first use and written to ~/.obsideo/mcp.json. Obsideo does not have a copy and cannot recover it. If that file is lost, every encrypted object is permanently unreadable, no matter how many providers still hold it and how many proofs it passes. Replication protects against providers losing your bytes; it does not protect against you losing your key. Back up ~/.obsideo/mcp.json somewhere you would still have after losing this machine.

~/.obsideo/roots.json is written alongside it: the merkle root of each object as committed at upload time. It holds no secrets, and it is what lets verify prove providers hold your bytes without re-uploading them. Encryption uses a fresh IV per upload, so ciphertext cannot be recomputed from a plaintext file later; this record is what keeps the strong proof available for encrypted objects. Losing it costs you strength of proof, not data.

Related MCP server: serac

Install

Claude Desktop, one click: download obsideo-mcp.mcpb from the latest release, then Settings -> Extensions and drag the file in. No Node or npm setup needed.

Everything else, via npx:

{
  "mcpServers": {
    "obsideo": {
      "command": "npx",
      "args": ["-y", "obsideo-mcp"]
    }
  }
}

(Claude Desktop: claude_desktop_config.json. Claude Code: claude mcp add obsideo -- npx -y obsideo-mcp. Cursor/Cline: their MCP settings, same command.)

Tools

Tool	What it does
`trial`	Create an instant no-email account (100 MB, ~7 days, proof-of-work, no human needed). Usually unnecessary: storage tools auto-create one on first use
`signup_start`	Email a 6-digit code (12 GB free tier; real inboxes only, refusals are labeled)
`signup_verify`	Complete signup; generates the signing keypair locally, stores credentials
`put`	Store a file or inline content, encrypted client-side by default (`encrypt: false` opts out). Auto-creates a trial account if none is configured
`get`	Retrieve an object (auto-decrypts with the local key)
`ls`	List objects, optionally by prefix
`rm`	Delete an object
`verify`	Prove the network still holds an object, without downloading it
`usage`	Storage used vs quota

`verify`

Challenges every provider holding the object directly, recomputes the merkle root, and checks each provider's Ed25519 signature. It asks the coordinator only where to go; nothing the coordinator asserts is trusted for the verdict. For objects this server uploaded, it verifies against the commitment recorded locally at upload time, so the answer is "they hold my bytes" rather than "they agree with each other". Objects uploaded elsewhere can be verified by passing local_path.

What it is good for

App file storage, automated backups (databases, snapshots, state), agent artifacts and memory that must survive sessions and machines, provable offsite copies. Not a CDN, not a queryable database, not sub-millisecond storage; Obsideo stores objects and backup artifacts.

Full integration contract (per-step postconditions, error table): obsideo.io/agents.md

Verified

Every tool in this server was exercised end to end against the production gateway before release, including an encrypted put/get roundtrip verified hash-exact (sha256) and labeled-error passthrough from the signup service.

License

MIT

Privacy Policy

This extension runs entirely on your machine. Credentials, your account signing key, and any client-side encryption key are stored locally in ~/.obsideo/mcp.json and are never sent to or hosted by Obsideo. Conversation content from your AI assistant is not collected; only the tool calls you make (for example an upload) reach the storage service.

Full policy: https://obsideo.io/privacy/

Available Tools

3 tools

getRetrieve an objectA

Read-only

Retrieve an object. Client-side-encrypted objects are decrypted automatically with the local key. Small text objects return inline; pass local_path for anything else.

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes
`local_path`	No	Save to this path instead of returning inline

TDQS

A3.5/5.0

Behavior3/5

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

The description adds useful behavioral details not in annotations: automatic decryption of encrypted objects and condition for inline vs. file return. However, it does not mention error cases like missing keys or decryption failures.

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 extremely concise with two sentences. The first sentence states the primary purpose, and the second adds critical behavioral context. No filler 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 simple nature of the tool and supportive annotations (readOnlyHint, openWorldHint), the description covers key aspects: purpose, encryption, and return behavior. It does not address error conditions or permission requirements, but these are acceptable omissions for a straightforward retrieval tool.

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?

The description adds meaning beyond the schema by explaining that local_path is used for non-small-text objects. This clarifies the parameter's role, especially since schema coverage is only 50% (only local_path has a description).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves an object and provides details on decryption and return behavior. However, it does not explicitly differentiate from sibling tools 'usage' and 'put', which could help agent choose among them.

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

Usage Guidelines2/5

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

The description lacks explicit guidance on when to use this tool versus alternatives. The only usage hint is 'pass local_path for anything else', which is parameter-level advice, not tool selection guidance.

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

putStore an objectA

Destructive

Store a local file or inline content as an object. Optional encrypt=true encrypts client-side with AES-256-GCM using a locally generated, user-held key before upload (the platform then cannot read the object; key loss = data loss). Zero-byte objects are rejected. Objects are replicated to 3 providers and verified on a continuous cryptographic challenge cycle.

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Object key, e.g. backups/db-2026-07-19.sql.zst
`content`	No	Inline UTF-8 content (alternative to local_path)
`encrypt`	No	Encrypt client-side before upload
`local_path`	No	Path of a local file to upload

TDQS

A4.7/5.0

Behavior5/5

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

Discloses client-side AES-256-GCM encryption, platform inability to read, key loss consequences, zero-byte rejection, and replication/cryptographic verification. Annotations already indicate destructive nature, so description adds valuable detail beyond annotations.

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?

Four sentences, each serving a purpose: main action, encryption details, zero-byte rule, durability guarantees. No redundancy or fluff.

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?

Given the four parameters are fully described in schema and the description covers critical behaviors (encryption, zero-byte rejection, replication), the tool is well-specified for an AI agent to use safely.

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 100%, and the description adds context for 'encrypt' (client-side, risk of key loss) and clarifies the distinction between 'content' and 'local_path'. This adds meaning beyond the schema parameter descriptions.

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 states 'Store a local file or inline content as an object' with a specific verb and resource, clearly distinguishing from siblings 'get' and 'usage'.

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?

Provides clear conditions: encryption warning ('key loss = data loss') and zero-byte rejection. However, it does not explicitly mention when to use vs. alternatives, though the context and tool name make it obvious.

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

usageShow storage usageA

Read-only

Show account storage usage versus quota.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint. Description adds 'versus quota' context but does not disclose additional behavioral traits like rate limits or data format. Satisfactory given annotations.

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?

Single sentence, front-loaded, no waste. Every word earns its place.

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

Completeness3/5

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

Description is adequate for a simple read-only tool with no parameters, but lacks detail about output format or structure. With no output schema, a bit more context would improve completeness.

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?

No parameters exist; baseline score of 4 applies. Description adds no parameter info since none are needed.

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?

Description clearly states the verb ('Show') and resource ('account storage usage versus quota'), distinguishing it from generic sibling tools 'get' and 'put'. It is specific and unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Siblings 'get' and 'put' are present but not mentioned; no explicit when-to-use or when-not-to-use context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.2.0Jul 22, 2026
- First observedget
- First observedput
- First observedusage

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-23 00:02 across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: get retrieves objects, put stores them, and usage shows storage quota. No overlap exists.

Naming Consistency4/5

Tool names are short, but 'usage' is a noun while 'get' and 'put' are verbs, creating a minor inconsistency. However, with only 3 tools, it's still readable.

Tool Count5/5

Three tools are appropriate for a basic storage server covering retrieval, storage, and usage monitoring. No unnecessary tools.

Completeness2/5

The server lacks essential operations like delete, list objects, and explicit update functionality. This leaves significant gaps for typical storage workflows.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

casa A
io.github.tony8713
Private, permanent encrypted storage for AI agents. Paid per call in USDC via x402.
File Systems Cloud Storage Cryptocurrency
32
Synapse Layer — Trust Infrastructure for AI Agents B
io.github.SynapseLayer
MCP-native Trust Infrastructure for AI Agents. Persistent encrypted memory with Trust Quotient.
Knowledge & Memory Autonomous Agents Security
13313
DocDeploy
io.docdeploy.www
Document hosting and encrypted agent memory with multi-tenant persistence.
Knowledge & Memory Cloud Storage File Systems
2
nukez-mcp A
io.github.ZlaylowZ
Agent-native storage with cryptographic verification on Solana. Keyless: clients sign and pay.
Blockchain Web3 & Decentralized Tech
151

Related MCP Servers

MemoraМCP
Cloud Storage Web3 & Decentralized Tech
RomanHasanSourab
F
license
Not graded
quality
D
maintenance
An MCP-powered storage system for AI agents that provides IPFS-secured, verifiable, and sovereign data storage capabilities.
Updated a year ago (2025-06-02 05:02 UTC)
-
serac
Cloud Storage Knowledge & Memory
AikoGilpin
F
license
Not graded
quality
D
maintenance
Sovereign E2E cloud storage for AI agents. MCP-native, zero-knowledge, RGPD-compliant, built in France.
Updated 4 months ago (2026-05-21 13:55 UTC)
-
SharedContext
Knowledge & Memory Autonomous Agents
Eversmile12
A
license
Not graded
quality
D
maintenance
Provides encrypted, portable memory for AI agents via MCP, allowing fact storage, conversation recall, and cross-machine sync using Arweave.
Updated 7 months ago (2026-02-24 13:54 UTC)
25 npm
50
MIT
hive-mcp-agent-storage
srotzin
A
license
Not graded
quality
C
maintenance
Agent-native object storage MCP server with per-agent DID isolation and x402 pay-per-byte metering in real Base USDC, enabling autonomous agents to store and retrieve objects with hot, warm, or cold retention classes.
Updated 4 months ago (2026-05-04 01:27 UTC)
MIT