@memoket-ai/cli

Onboard the Memoket MCP into your local AI client and log in. The CLI only does register + login + passthrough; the tool catalog is always pulled live from the server, so it never drifts.

Pure Node.js (ESM), zero native bindings, two runtime dependencies (commander, open). OAuth: well-known discovery → DCR → PKCE S256 → browser callback.

Hacking on this CLI or building from source? See CONTRIBUTING.md. Maintainer ops (publishing, NPM_TOKEN) live in RELEASE.md — internal only, not shipped to npm.

Install

npm install -g @memoket-ai/cli

Then:

memoket doctor   # connectivity + OAuth discovery
memoket setup    # register into Claude Code / VS Code and log in

Commands

memoket setup                                          register MCP into local AI clients (Claude Code / VS Code…) and log in  ← most common
memoket login                                          browser-authorize and save the token (for tools/call)
memoket doctor                                         connectivity + OAuth discovery + token login status
memoket tools                                          list tools exposed by the live MCP (tools/list passthrough)
memoket call <tool> [key=value ...] [--json '{...}']   call a tool (tools/call passthrough)
memoket describe <tool>                                show a tool's input parameters

memoket endpoints                                      list named endpoints, mark the ACTIVE one
memoket endpoints use <name>                           switch the active endpoint (persisted)
memoket endpoints add <name> <baseURL>                 add a custom endpoint
memoket endpoints remove <name>                        drop a custom endpoint

memoket token create [--name X] [--scope a,b] [--expires-in 90]   issue a Personal API Token
memoket token list                                                  list Personal API Tokens
memoket token revoke <id>                                           revoke a Personal API Token
memoket token rotate <id>                                           rotate a token (new mtok, old revoked)

memoket webhook events                                                  list subscribable event names
memoket webhook create --to <https-url> --events a,b                   register a webhook endpoint
memoket webhook list                                                    list webhook endpoints
memoket webhook update <id> [--to <url>] [--events a,b | --clear-events]  update URL or replace/clear subscriptions
memoket webhook delete <id> [--yes]                                    delete a webhook endpoint
memoket webhook test <id>                                               send a webhook.ping test delivery
memoket webhook deliveries <id> [--page N] [--page-size N]              delivery history

Every command and sub-command accepts -h / --help for its full options. Type memoket <command> -h to drill in (e.g. memoket token create -h, memoket webhook create -h).

Endpoints

Each build of the CLI ships with only its own endpoint baked in (a public npm install always bakes prod). The active endpoint is what's used by every command; the selection is persisted to ~/.memoket/config.json.

memoket endpoints                                  # list; the ACTIVE one is marked with *
memoket endpoints add myenv https://api.example.com  # add a custom one
memoket endpoints use myenv                        # switch to it (persisted)
memoket endpoints remove myenv                     # drop a custom one

A prod-built artifact looks like:

NAME  BASE URL                 ACTIVE
prod  https://mcp.memoket.ai  *

Need a different environment? Run memoket endpoints use <name> to switch among what's already baked in plus your customs. To expose more endpoints in one binary, edit config/<env>.json and rebuild — see CONTRIBUTING.md.

Global flags: --url <url> (one-off endpoint override, wins over the active endpoint) / --name <name>.

Generic HTTP integrations

For n8n, Make, Zapier HTTP Request, scripts, and customer backends, use the generic HTTP integration commands. These are not n8n-specific; they create the same primitives any HTTP client can use.

memoket login

memoket token create \
  --name "My automation" \
  --scope recordings:read,summaries:read,transcripts:read,search:read

The command creates a Personal API Token (mk_pat_...) for customer -> Memoket API calls. Use it as:

Authorization: Bearer mk_pat_...

The underlying management commands are also available directly:

memoket token create --name "n8n" --scope recordings:read,summaries:read --expires-in 90
memoket token list
memoket token revoke <id>
memoket token rotate <id>          # rotate: mint a new mtok, the old token stops working immediately

These commands target the Gateway REST management API (/v1/api-tokens). If the backend endpoint is not deployed yet, the CLI will fail with the returned HTTP status.

Recommended integration flow

For a backend integration, use a webhook as the processing trigger and the live read tools as the source of current recording content:

1. Create a subscription with memoket webhook create and save the secret shown once at creation.

2. Verify the HMAC against the raw request body, reject stale timestamps, and deduplicate deliveries by the top-level event id.

3. Read data.conversation_id as an opaque string. Do not parse it as a JavaScript number.

4. Fetch recording metadata and transcript content with the same conversation_id:

   memoket call get_conversations --json '{"conversation_ids":["<conversation_id>"]}'
   memoket call get_transcripts conversation_id=<conversation_id>

5. Fetch the content that caused the event:

   # Auto-analysis event without report_id: fetch the generated Brief.
   memoket call get_brief --json '{"conversation_ids":["<conversation_id>"]}'
   
   # Explicit report event with report_id: fetch that exact report.
   memoket call get_summaries --json '{"summary_ids":["<report_id>"]}'

   Calling get_summaries with only conversation_ids fetches the latest Deep Dive summary and may return no items for a recording that has only a Brief. Read each returned format; fetched content may use a different representation from the callback snapshot.

6. Store the event id and your per-recording processing state before acknowledging the webhook, so a retry cannot create duplicate work.

summary.completed currently may include transcript and summary content in the callback. Treat that content as the delivery snapshot. If content is missing or transcript.truncated is true, use the read tools above to fetch the current data.

There is no stable incremental-sync cursor today. For a polling fallback, use list_conversations with a small overlapping start_time window, page with offset / next_offset, and deduplicate by the opaque conversation id.

Public data contract notes

Recording and transcript timestamps

• When present, summary.completed.data.recorded_at is the recording's wall-clock start time.
• summary.completed.data.transcript.segments[].start and .end are offsets in seconds from the start of the recording. An absolute segment time is recorded_at + offset_seconds.
• get_transcripts returns line offsets as started_offset_ms and ended_offset_ms. These values are in milliseconds from the recording start; combine them with the recording's started_at from get_conversations when an absolute line time is needed.
• list_conversations and get_conversations return recording-level started_at and ended_at as ISO 8601 timestamps. ended_at may be null when the end time is not available.
• The current summary.completed callback does not have a separate ended_at field. When recorded_at and duration_ms are both present, the callback snapshot's end time is recorded_at + duration_ms milliseconds; otherwise fetch recording metadata.

Participant labels

participants contains per-recording speaker display labels, not verified identities or stable participant IDs. Unnamed speakers are returned as placeholders such as A and B; some clients may display them as Speaker A and Speaker B. When a user has saved a confirmed participant name, that name may replace the placeholder. The current response does not expose the original label-to-name mapping or indicate whether a value is confirmed. Do not use participants alone for cross-recording identity matching, automatic task assignment, or authorization.

Why "passthrough" rather than hardcoded commands

The MCP's tool catalog is loaded at runtime from the server, not hardcoded. Hardcoding tools in the CLI would drift. This CLI passes tools/list / tools/call through, so any add/change/drop on the server is followed automatically.

Build & try from source

git clone https://github.com/memoket/memoket-cli.git
cd memoket-cli
npm install
npm run build:dev        # bake dev as the default active
node bin/memoket.js doctor
node bin/memoket.js tools
node bin/memoket.js setup            # registers into clients + browser login
node bin/memoket.js describe <tool>  # inspect a tool's schema (after running `tools` above)
node bin/memoket.js call <tool>      # invoke a tool by name

Requires Node ≥ 18 (tested on Node 20+). Full release / staging workflow and per-env tarball commands are documented in CONTRIBUTING.md.

One honest caveat

memoket login's token is for this CLI's own tools / call only; it is not shared with Claude Code. Claude Code does its own OAuth: after memoket setup registers the MCP, you still need to run /mcp in Claude Code and pick memoket to log in there. The CLI writes the config; each client does its own login. This is a client limitation, not something the CLI can route around.