Skip to main content
Glama
slidingbox

hydrate-dehydrate-mcp

by slidingbox
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

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

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenYesThe sb_<pointer>#<key> token from store_secret.

TDQS

A4.5/5.0
Behavior5/5

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

Explicitly discloses the destructive nature ('token is dead... second call returns nothing'), aligning with destructiveHint=true. Adds payment/cost context and the evaluation key exception, which annotations do not cover.

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?

Two sentences, front-loaded with purpose, then behavioral caveats. No redundant wording.

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?

Covers purpose, prerequisites, one-time behavior, and cost. Since there is no output schema, the description implies the return is the secret itself, which is sufficient for a single-parameter tool.

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 already fully documents the token parameter with format and origin. Description reinforces the origin but adds no new semantic meaning beyond the schema.

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?

Clearly states the action ('Read') and the resource ('secret stored on Slidingbox'), plus the token source. It distinguishes itself from siblings like store_secret by its read semantics, and from verify_endpoint by not mentioning verification.

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?

Specifies the prerequisite of having a token from store_secret and warns about one-time use. It doesn't explicitly name alternatives or exclusions, but the context of token provenance and destruction is clear.

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

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe secret to store. Encrypted before it leaves this machine.
ttl_secondsNoHow long it may sit unread, 60-900 seconds (default 900).

TDQS

A4.5/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: encryption happens locally, Slidingbox never sees plaintext or key, the returned token carries both pointer and decryption key, and the first read delivers and destroys the secret. This gives the agent a strong mental model of side effects and security properties.

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 tight sentences front-load the action, then explain the returned token, the consumption workflow, and the security guarantee. Every sentence adds necessary context with no repetition or filler.

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 tool has no output schema, the description fully explains what is returned (a single token) and what that token means. Combined with the rich schema and annotations, an agent has everything it needs to invoke the tool correctly and understand downstream behavior.

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 parameter semantics baseline is 3. The description reinforces that 'text' is encrypted before leaving the machine, but that information already appears in the schema field description. It adds no extra meaning for the parameters beyond what the schema provides.

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 uses a specific verb ('Encrypt a secret locally and store the ciphertext') and names the resource (Slidingbox), making the core operation unmistakable. It also clearly distinguishes this from sibling tools by explaining the unique token-and-destruction model, which retrieval and verification tools would not have.

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?

The description gives clear context for use: store a secret, get a token, and hand that token to the intended reader. It does not explicitly name alternatives or say 'when not to use,' but the intended workflow is obvious from 'Hand that token to whoever should read it' and the sibling names.

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

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
resourceYesAbsolute URL of the x402 resource to check.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating 'Check' – a read-only operation. It adds valuable behavioral context: 'Paid (x402) unless an evaluation key is configured,' informing the agent of potential cost implications. It also explains what data it checks (live price/payee vs catalog), which is not available from annotations alone. No contradictions.

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 two sentences, front-loaded with the core purpose and checks, followed by usage guidance and cost note. There is zero waste; every sentence earns its place. The structure is efficient and immediately scannable.

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?

For a single-parameter tool with no output schema, the description conveys the purpose, when to use it, and the key behavioral trait (payment). It implies what the tool returns (whether it is live, matches, and timestamps of changes), but does not explicitly state the response format. Since the tool is straightforward and the description is otherwise thorough, this minor gap is acceptable.

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?

The schema description for the only parameter is 100% complete, defining 'resource' as 'Absolute URL of the x402 resource to check.' The tool description adds no further parameter detail, merely echoing the same concept. Since the schema fully covers it, the description adds no semantic value beyond the baseline.

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 clearly states the verb 'Check' and the resource 'x402 endpoint', and specifies the exact checks performed: live/payable status, price/payee match with the catalog, and when changes occurred. This distinguishes it from sibling tools (retrieve_secret, store_secret) which deal with secrets, leaving no ambiguity about its role.

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 an explicit usage context: 'Use before the first payment to an endpoint you have not used.' This tells the agent when to invoke it. It does not mention when not to use it or alternative tools, but the siblings are unrelated in purpose, so no confusion arises. The payment condition also adds usage 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.

  1. 3 tool updates
    • First observedretrieve_secret
    • First observedstore_secret
    • First observedverify_endpoint
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

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
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • zKettle

    benderterminal
    A
    license
    Not graded
    quality
    C
    maintenance
    Self-hosted, zero-knowledge encrypted, self-destructing secrets for secure agent-to-agent coordination
    3
    AGPL 3.0

  • volta-mcp-server

    iamredmh
    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
    63 npm
    1
    MIT

  • SecureNote.link MCP Server

    jackalterman
    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
    -