Data apps

Overview

Three apps for talking to things that hold data: TDE API for HTTP, TDE Database for SQL and document stores, TDE Redis for keys. All three are mouse-first, and two of them hand what you configure to your agents — TDE API through a skill, TDE Database through MCP.

TDE API

A Postman-style HTTP client. A request is a method, a URL, query parameters, headers, a body and an auth mode; the response comes back as a status pill, a timing and a size, with the body and headers on their own tabs.

Content-Type: application/json is added for you when the method carries a body, the body starts with { or [, and you have not set the header yourself. Requests time out after 30 seconds and invalid certificates are never accepted.

Collections

Saved requests live in a sidebar and can be grouped into folders. Right-click a row for rename and delete, or drag a request onto a folder to refile it. Everything is written to ~/.config/tde/api/collection.json on every edit — there is no explicit save.

Keys

With the mouse: click the method to pick a verb from a modal, click Send, click a field to type in it with drag-select, click the request or response tabs, and scroll the response with the wheel.

From an agent

The tde-api skill lets an agent build and fire a request without touching the keyboard:

ID=$(tde agent windows | awk -F '\t' '$2=="TDE API"{print $1}')
tde agent api $ID method POST
tde agent api $ID url https://api.example.com/v1/jobs
tde agent api $ID header Authorization "Bearer $TOKEN"
tde agent api $ID body '{"name":"nightly"}'
tde agent api $ID send

send prints the response as JSON — status, status text, headers, body, elapsed time, size and any transport error — and updates the visible window at the same time, so you can see what your agent just did. get reprints the last response. clearheaders empties the header list. There is no agent command for auth, params or collections; set Authorization with header.

TDE Database

A SQL studio with five panes — Profiles → Schema → Queries → SQL → Results — cycled with Tab.

Engines

DuckDB and FlightSQL can be selected as a profile driver, but there is no execution backend for them yet — a query will come back as an unsupported engine. All drivers are pure Rust and statically linked; nothing shells out.

Profiles

Create a profile in Control Center → Database: a name, a driver, a DSN and an enabled toggle. The connection string is written into the encrypted vault before the profile row is created, and the profile itself stores only a reference. Profile metadata lives in ~/.tde/mcp_registry.db. Debug output redacts URIs, usernames and passwords everywhere.

Running queries

In the Schema pane, Enter expands an object, o opens a SELECT tab for it, d previews its DDL and r reloads. In the Results pane, Space copies, e exports, v cycles Table / JSON / Explain view. Export writes CSV from the table and Explain views, and JSON from the JSON view.

Profiles become MCP servers

Every enabled profile is materialized as an MCP server into all four agent CLIs TDE knows about — ~/.claude.json, ~/.codex/config.toml, ~/.cursor/mcp.json and ~/.config/opencode/opencode.json — so your agents query the database through a named profile and never see a DSN.

The server name is tde-db-p<id>: the id is opaque on purpose, so no profile metadata leaks into an agent config file. Older profiles that still hold a plaintext connection string get the legacy tde-db-<slug> name instead, built from the profile's display name; those are blocked from MCP sync until they are migrated into the vault. The tde-db- prefix is reserved — you cannot create your own MCP server under it.

Each server exposes exactly two tools:

A write needs both allow_write: true on the call and a server started with --read-write. Anything else is read-only, and unclassifiable SQL fails closed. Request and response are capped at 2 MiB each.

TDE also generates a tde-database skill from your live profile list, so an agent is told which profiles exist, which MCP key each maps to, and to prefer reads. See MCP for how servers reach your agents.

TDE Redis

Two screens: Connections, a list of saved profiles, and Browser, a SCAN-fed key sidebar with a viewer that changes shape per value type. All network calls run on a background worker, so the UI never blocks on a slow server.

Value types are recognised and badged: strings, lists, sets, hashes, sorted sets, streams and RedisJSON. HyperLogLog counts, bitmap info and geo members get their own on-demand views, and streams are shown newest-first, read-only.

What you can do

• Keys — scan by pattern, load, rename, delete, create, set a TTL or persist. Batch delete and batch TTL by pattern.
• Collections — push to the head or tail of a list, set or remove an element, add or delete hash fields, add or remove set and sorted-set members with scores.
• Search — filter by key pattern, or turn on value search to match inside values.
• Tools — eight tabs: Metrics, Server, Slow log, Clients, Pub/Sub, Lua, Watch and Cluster. Pub/Sub can subscribe, publish and enable keyspace notifications; Lua runs EVAL with keys and args; Watch auto-reloads a key and keeps value snapshots.
• Import and export — JSON, written to ~/Downloads, up to 1 000 keys.

Keys

TDE Redis is deliberately mouse-first; the keyboard set is small.

Everything else is clicking: profile rows, the tree grouping chip, the All / Fav / Recent sections, the value-search toggle, Batch, refresh, + Key, the collection + Head / + Tail / + Field / + Member chips, the Tools tabs, and right-click menus on rows.

Connections

A profile carries a name, host, port, username, password, database number (0–15), a TLS toggle, an insecure toggle that skips certificate verification, and optional SSH tunnel settings. Profiles are saved to ~/.config/tde/redis/profiles.json, with favourites and recents in state.json beside it.