Skip to main content
Glama
Regan-Milne

Obsideo MCP server

by Regan-Milne

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OBSIDEO_TRANSPORTNoSet to 's3' to use the S3 gateway transport with the SigV4 keypair instead of the default direct coordinator transport.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
trialA

Create 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_startA

Start 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_verifyA

Complete 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.

putA

Store 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.

getA

Retrieve 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.

lsB

List stored objects (size TAB key), optionally under a prefix.

rmC

Delete an object by key.

verifyA

Independently verify that the network still holds an object, without downloading it. Challenges each provider directly, recomputes the merkle root from your own copy of the bytes, and checks each provider's cryptographic signature. Trusts nothing the coordinator says for the verdict. Objects stored through this server verify at full strength with no extra arguments, because their commitment was recorded locally at upload time. Pass local_path (your copy of the stored file) to prove possession against a file on disk instead. Returns how many providers proved possession right now and whether any returned bad data.

usageA

Show account storage usage versus quota.

planA

Show 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.

upgradeA

Get 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).

portalA

Get 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.

backup_keysA

Copy everything needed to recover this account's data (credentials, account signing key, encryption key, upload commitments) to a path the human names. Obsideo holds no copy of the encryption key: if the local file is lost, encrypted objects are unrecoverable no matter how many providers hold them. Call this once right after the account is created and again after any signup that rotates keys. A .tar.gz path produces one archive; a directory path produces plain copies; no path produces an archive in the home directory.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 13 tools

Disambiguation4/5

The storage commands (put/get/ls/rm/verify) and account/billing tools are largely distinct, and the long descriptions clearly disambiguate the signup flow. Minor overlap remains between trial and signup_start (both can bootstrap an account) and between plan/upgrade/portal, but their roles are clear enough to avoid serious misselection.

Naming Consistency3/5

Names are consistently lowercase and terse, with signup_start/signup_verify and backup_keys using underscores, but the set mixes verb commands (put/get/rm), noun commands (usage/plan/portal), and noun-as-action commands (trial). It is readable, but no single predictable verb_noun grammar is maintained.

Tool Count5/5

Thirteen tools cover storage, account lifecycle, and billing without bloat; each tool addresses a distinct operation or workflow. The count is squarely in the ideal 3–15 range for this server's scope.

Completeness5/5

The surface covers account creation/claiming/verification, plan and quota inspection, upgrades and cancellations via portal, full object CRUD with encryption, independent integrity verification, and key backup. No obvious dead ends remain for the stated storage and account-management purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues