Context Keeper (Remote) MCP Server

Self-hosted Cloudflare Worker remote backend for context-keeper (D1, streamable-HTTP). Exposed over MCP by the context keeper (remote) mcp server, that capability becomes something an assistant can invoke while it works, not something you go and do afterwards.

What it actually does

A remote MCP server on Cloudflare Workers that exposes context-keeper's rationale store (decisions, pipelines, constraints) over Streamable HTTP. It works as a claude.ai custom connector, including on mobile, so your project's decisions and constraints are available from any Claude session — no PC left running, no tunnel.

• Worker, not tunnel — — no "PC must be on" dependency
• D1, not KV — — row-level writes and WHERE queries; two writers (desktop +
• Stateless handler, no Durable Objects — — the tools are stateless RPCs against
• Secret-path auth — — claude.ai custom connectors don't reliably send custom
• Self-migrating — — the Worker creates its own D1 schema at runtime, so a

Adding it to your client

npm on npm is all you need. Most clients run it directly, so configuration is a few lines and a restart.

Its toolset

Everything the assistant can do here goes through one of these:

• config — Read or write config: op='get' reads a key, op='set' writes it (value required). Use key default_project (global scope, no project) to pick the
• record_entry — Unified write: record a decision, constraint, or pipeline. Required field depends on kind — decision needs summary, constraint needs rule, pipeline
• record_decision — Deprecated alias for record_entry(kind='decision'): summary, problem, why_chosen, what_we_tried, tradeoffs, tags
• record_constraint — Deprecated alias for record_entry(kind='constraint'): a rule that must hold — rule, reason, tags
• record_pipeline — Deprecated alias for record_entry(kind='pipeline'): a reusable process — name, purpose, steps (extra fields kept verbatim)
• get_context — Relevance-ranked retrieval for a query (keyword scoring; excludes deprecated unless include_deprecated)
• query_entries — Structured filters: id, kind, tags (all must match), status (active/deprecated/all), free text, and limit
• get_project_summary — One-call orientation: entry counts by kind and status, the ids present, the active constraints (compact), and the most recent decisions
• list_projects — The org registry: every project with entries, plus per-project active counts (decisions/constraints/pipelines), active/deprecated totals, and
• update_entry — Merge patch fields into an entry's payload; optionally change status
• deprecate_entry — Mark deprecated, optionally linking superseded_by
• reload_constraints — Compact list of the active constraints

Configuration

You will need 4 environment variables: AUTH_TOKEN, CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID, WORKER_URL. The server will not start without them, which is usually why the tools fail to appear on a first run. Keep credentials in your client's env block or a secrets manager rather than in a file you might commit.

Caveats

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Context Keeper (Remote).
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the context keeper (remote) mcp server does with a few real requests.

When to reach for it

Plenty of cloud and infrastructure servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Context Keeper (Remote)'s toolset — config, record_entry, record_decision and 11 more — is a fair guide to whether it matches your workflow. It is maintained by jarmstrong158; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.