hydrate-dehydrate-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SLIDINGBOX_URL | No | The base URL of the Slidingbox API. | https://slidingbox.ai |
| SLIDINGBOX_API_KEY | No | An issued evaluation key (sbk_<id>.<hmac>). Covers a fixed number of reads for free. | |
| SLIDINGBOX_NETWORK | No | The network chain ID for x402 payments (default Base mainnet). | eip155:8453 |
| SLIDINGBOX_PRIVATE_KEY | No | A Base wallet private key holding USDC for per-call payment over x402. |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| store_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. |
| retrieve_secretA | 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. |
| verify_endpointA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
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.
All tool names follow a consistent verb_noun pattern: store_secret, retrieve_secret, verify_endpoint. The naming style is uniform and predictable.
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.
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.