Skip to main content
Glama

@slidingbox/hydrate-dehydrate-mcp

Discontinued: SlidingBox was permanently decommissioned on 2026-09-21. Its service endpoints are unavailable. This repository remains archived as an accurate historical record; do not install or depend on this package.

An MCP server for handing a secret from one agent, machine, or person to another without leaving a copy behind.

store_secret encrypts on your machine and returns one token. Whoever holds the token gets the secret exactly once — the first successful read delivers it and destroys it, and a second read returns nothing. Slidingbox stores only ciphertext: the key travels in the token and is never sent to the server.

store_secret("sk-live-...")  ->  sb_PApm-Ui...#0zgYgq2d...
                                 ^ pointer, on the server   ^ key, never sent

retrieve_secret("sb_PApm-Ui...#0zgYgq2d...")  ->  sk-live-...   (and it's gone)

A third tool, verify_endpoint, answers a different question: before your agent pays an unfamiliar x402 endpoint, is it live, is it payable, and do its price and payee still match what the CDP Bazaar catalog advertises.

verify_endpoint("https://example.com/v1/thing")
  ->  {"payable": true, "price_matches_catalog": false,
       "reason_codes": ["price_drift"], "last_changed_at": "2026-09-01T..."}

Two more tools answer a third question: has this web page changed since it was last checked — by anyone? Every check of a URL is kept as hashes, so you learn what changed without the page ever being stored or returned.

has_page_changed("https://vendor.example/pricing")
  ->  {"changed": {"content": true, "scripts": false, ...},
       "sections": {"total": 12, "changed": [3]},
       "history": {"observations": 7, "last_changed_at": "2026-09-18T..."}}

watch_page("https://shop.example/checkout", "https://my-agent.example/hooks/drift")
  ->  {"watch_id": "...", "secret": "...", "checks": 168, "expires_at": "..."}
      then a signed POST to the callback whenever an hourly check finds a change

changed.scripts reports whether the set of external scripts a page loads has changed — the kind of change PCI DSS 11.6.1 asks payment-page operators to detect. It is an observation from outside the page, not a compliance control.

Why there is no hosted version

There is deliberately no hosted instance of this server, and no entry under Glama's connectors or any other remote-MCP directory. store_secret encrypts in the process it runs in, so a hosted instance would receive your plaintext before it ever became ciphertext, and retrieve_secret takes a token that carries the decryption key. Hosting either one moves the secret into somebody else's environment, which is the exact thing this exists to avoid.

Running it locally is the feature, not a limitation. The Dockerfile in this repo exists so directory listing checks can start the server and introspect it; it is not a deployment target.

Related MCP server: volta-mcp-server

Install

{
  "mcpServers": {
    "hydrate-dehydrate": {
      "command": "npx",
      "args": ["-y", "@slidingbox/hydrate-dehydrate-mcp"],
      "env": { "SLIDINGBOX_API_KEY": "sbk_..." }
    }
  }
}

That block goes in your MCP client's config — claude_desktop_config.json for Claude Desktop, or claude mcp add for Claude Code.

Paying for reads

Storing is free. Reading costs $0.02 and a verify costs $0.01. A page's first has_page_changed is free; later checks cost $0.05, and a watch_page costs $0.50 once. Evaluation keys cover reads and verifies; page checks and watches are paid by wallet only. The ways to pay:

Variable

What it does

SLIDINGBOX_API_KEY

An evaluation key (sbk_<id>.<hmac>). Covers a fixed number of reads for free. Get one instantly: curl -X POST https://slidingbox.ai/v1/key — no account, no email.

SLIDINGBOX_PRIVATE_KEY

A Base wallet holding USDC. Reads are paid per call over x402 — no account, no invoice, no subscription.

SLIDINGBOX_URL

Defaults to https://slidingbox.ai.

SLIDINGBOX_DRIFT_URL

Defaults to https://drift.slidingbox.ai (page checks and watches).

SLIDINGBOX_NETWORK

Defaults to eip155:8453 (Base mainnet).

With neither set, store_secret still works, and retrieve_secret and verify_endpoint tell you which one to configure. SLIDINGBOX_PRIVATE_KEY signs payments: give it a wallet funded for this purpose and nothing else.

What it is good for

  • Passing a credential between two agents that share no store and no account.

  • Sending a secret through a channel you would rather it not persist in — the token in the chat log is inert the moment it is read.

  • Proving a handoff happened once. A replayed token fails visibly instead of quietly serving a second copy.

What it is not

Not storage, backup, messaging, or key management. Secrets live 60–900 seconds and then expire. Not for protected health information or payment-card data.

How it works

Encryption is AES-256-GCM, done in this process before anything is sent. The server receives {ciphertext, iv} and a time-to-live, and returns an opaque pointer.

Payment, when a wallet is configured, is x402 — the read returns 402, the client signs an EIP-3009 authorization for $0.02 USDC, and retries. Paying wallets are screened against the OFAC SDN list before settlement; see https://slidingbox.ai/compliance.

Development

npm install
npm test        # offline: crypto round-trip and token parsing
node server.mjs # speaks MCP over stdio

If this stops working

Slidingbox is a small product and may be retired. This server is built to say so rather than fail opaquely: a retired service answers 410, and a domain that no longer resolves is reported as a retirement, not as a stack trace. Nothing you store is ever held longer than 900 seconds, so a shutdown cannot strand data.

ISC © SLIDINGBOX LLC

Available Tools

3 tools
retrieve_secretRetrieve a secretA
Destructive

Read a secret stored on Slidingbox, using the token from store_secret. This destroys it: the token is dead the instant this succeeds, and a second call returns nothing. Reading is paid (x402) unless an evaluation key is configured.

Inputs: token (required).

store_secretStore a secretA

Encrypt a secret locally and store the ciphertext on Slidingbox. Returns one token that carries both the pointer and the decryption key. Hand that token to whoever should read it: the first read delivers the secret and destroys it. Slidingbox never sees the plaintext or the key.

Inputs: text (required), ttl_seconds.

verify_endpointVerify an x402 endpointA
Read-only

Check an x402 endpoint before paying it: whether it is live and payable, whether its live price and payee still match the CDP Bazaar catalog listing, and when either last changed. Use before the first payment to an endpoint you have not used. Paid (x402) unless an evaluation key is configured.

Inputs: resource (required).

Tool Schema Changelog

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

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 3 tools

    Disambiguation5/5

    Each tool has a distinct lifecycle role: store_secret creates a secret, retrieve_secret consumes it, and verify_endpoint checks an endpoint before payment. There is no overlap between the three operations.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern: store_secret, retrieve_secret, verify_endpoint. The naming style is uniform and predictable.

    Tool Count4/5

    Three tools is a small but reasonable surface for a focused secret-handoff and endpoint-verification utility. It is slightly minimal but each tool earns its place and the scope is narrow.

    Completeness4/5

    The core secret lifecycle is covered: store, retrieve, and destroy-on-read. The verify_endpoint tool covers the pre-payment check. Minor gaps exist (e.g., no explicit revoke or status check for a stored secret), but the intended workflow is complete.

    Maintenance

    ActivityNo data
    ResponsivenessSyncing

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      Self-hosted, zero-knowledge encrypted, self-destructing secrets for secure agent-to-agent coordination
      3
      AGPL 3.0
    • A
      license
      A
      quality
      D
      maintenance
      Create and read burn-after-read encrypted notes. AES-256-GCM E2E encryption with self-destructing URLs for secure credential handoff between users and AI agents.
      2
      65 npm
      1
      MIT
    • F
      license
      Not graded
      quality
      D
      maintenance
      Enables AI agents to create end-to-end encrypted, self-destructing notes that can be securely shared via a one-click link, ensuring secrets are never stored in plain text in chat history.
      1
      -