MCP tools

MarkDB ships a Model Context Protocol (MCP) server so any MCP-aware client can recall and search your agent's memory without custom glue. This is the read path from the operating model: your agent captures work through the proxy, then retrieves it through these tools.

Not using MCP? Every tool has a plain HTTP equivalent. See the Memory API.

Endpoint

https://mcp.markdb.cloud/mcp

• Transport: streamable HTTP (JSON responses).
• Auth: send your mk_live_... key as a bearer token, the same key you use for the proxy. The tools are scoped to that key's (account, workspace, agent), so recall stays inside the workspace the key was minted for.

Add it to a client

Any MCP-aware client works. Point it at the endpoint with your key in an Authorization header.

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "markdb": {
      "url": "https://mcp.markdb.cloud/mcp",
      "headers": { "Authorization": "Bearer mk_live_xxx" }
    }
  }
}

For Claude Code, add it as an HTTP MCP server:

claude mcp add --transport http markdb https://mcp.markdb.cloud/mcp \
  --header "Authorization: Bearer mk_live_xxx"

Once connected, your agent sees the memory tools below and can call them mid-task.

Read tools

These are always available. They're how an agent recalls context.

memory_search

Hybrid search over your memory. Returns scored results with summary_text, key_facts, decisions and a page_id for drill-down, often enough to answer without fetching anything else.

{
  "query": "postgres shm exhaustion fix",
  "mode": "hybrid",
  "artifact_kind": "session_summary",
  "limit": 5
}

Summary levels run daily_summary > hourly_summary > session_summary > turn_summary > transcript_chunk: higher levels cover more time with less detail.

memory_get_detail

Fetch the full content of a summary by page_id. Returns summary_text, key_facts, decisions, open_questions, citations and child_summaries.

Each child summary includes a preview, its own page_id, plus start_time and session_id. Read the previews, then recurse into the relevant children. When children are capped, total_children and children_truncated tell you how many exist.

memory_list_events

Query raw conversation events by time range. Use this when you need exact wording, code snippets, tool outputs or specific IDs that summaries don't keep.

Time windows come from search provenance or from memory_get_detail children (e.g. an hourly scope id 2026-04-12T04 means 04:00–05:00 UTC).

memory_get

Fetch any artifact by reference (type + id). Use it to follow citation IDs from a summary to the underlying raw content.

Turn summaries include citation event_ids; memory_get(type='event', id=…) returns that event's full content.

The drill-down workflow

The read tools compose into a search-then-expand loop. Start broad, then descend only into what's relevant, so you spend tokens on the right turns instead of re-reading whole transcripts.

memory_search("Firestore errors")
  → daily_summary (page_id = X)
memory_get_detail(X)
  → child: hourly_summary (page_id = Y, "Resolved Firestore…")
memory_get_detail(Y)
  → child: session_summary (page_id = Z, session_id = abc, start_time = 10:15)
memory_get_detail(Z)
  → child: turn_summary (page_id = W, citations: [{event_id: abc}])
memory_get(type="event", id="abc")
  → full raw event content

Write tools

When the server is configured with write access (not read-only), an additional set of tools lets agents shape memory directly: