← Docs

Memex for Codex

// overview

Overview

Memex is a docs-and-task graph designed for AI coding agents to plan, decide, and ship alongside human teammates. The Memex MCP connector gives Claude — in Claude.ai, Claude Desktop, or Claude Code — access to that graph: it can read your active Briefs, resolve open decisions, mark tasks complete as it ships work, leave structured comments, and flag drift on the Standards your code is supposed to follow.

Think of it as the difference between an agent that re-derives your project's plan every session from a CLAUDE.md file (which goes stale the moment two people edit it) and one that reads from a live, versioned source of truth and writes back as it works. The same Brief that Claude reads when it picks up a task is the one your humans see in the web UI five minutes later, with the same decisions, the same tasks, and the same comments.

Below: how to connect Claude to Memex (Setup), the full tool surface the connector exposes, and three worked examples showing common flows end-to-end.

For Memex's broader product documentation — Missions, decisions, tasks, standards, self-hosting — see the main docs page.

// setup

Setup — coming soon

The Codex connector for Memex is in preparation for submission to OpenAI Codex marketplace. While we work on that, you can already use Memex with Codex via the manual mxt_ Personal Access Token route documented in the main docs.

Once the connector listing is live, this page will document the one-click flow. The tool surface and worked examples below already apply — they describe what Memex exposes via MCP, regardless of which client you connect from.

Reference connector docs: Memex for Claude (live).

// tool surface

Tool surface

The connector exposes 23 tools in seven groups. Tool descriptions returned by tools/list carry MCP annotations (title, readOnlyHint, destructiveHint) so Claude can decide which tools to auto-call vs which to prompt the user on.

Why are some tools consolidated?

Several Memex tools deliberately accept multiple optional fields rather than splitting into one tool per action. update_task handles status changes, blocker adds/removes, title edits, and acceptance-criteria revisions through one entry-point. update_doc, update_decision, and list_comments follow the same pattern — one tool with optional fields rather than several near-identical names. Claude's tool-selection gets noisy when faced with three almost-identical options; consolidating reduces routing ambiguity without losing expressiveness.

This is a departure from the granular pattern some MCP servers use; we believe it's the right call for an agentic surface where the AI itself does most of the dispatch.

Memexes

ToolRead-onlyDescription
list_memexes✅List every Memex (personal + Org) the authenticated user can access under this grant's scope.

Briefs (Memex docs)

ToolRead-onlyDescription
list_docs✅List active Briefs in a Memex with decision/task counts and lineage.
get_doc✅Fetch a document by canonical ref (e.g. acme/api/briefs/b-3) with all sections, decisions, tasks, comments, and blockers.
create_doc❌Create a new Brief. Initial sections and seed decisions can be passed inline.
update_doc❌Update a document's status (lifecycle transition) and/or title.
add_section❌Append a new section to a document. Unique-per-doc sectionType identifier required.
update_section❌Replace the content of a document section.
assess_brief✅Run a deterministic Brief assessment — open decisions, incomplete tasks, ready-vs-blocked, narrative coverage, comment survey, or a phase-transition rubric.
publish_brief❌Move a Brief from draft → plan → build → verify → done. Honors gate criteria; refuses bad transitions.

Decisions

ToolRead-onlyDescription
create_decision❌Add a new decision to a document, with status of open (human-authored, blocks tasks) or candidate (agent-extracted, awaits human review).
update_decision❌Update a decision's status (e.g. reopen a previously resolved decision).
resolve_decision❌Mark a decision resolved with the chosen option + rationale. May unblock dependent tasks.
approve_candidate❌Approve a candidate decision, promoting it from candidate to open.
reject_candidate❌Reject a candidate decision with rationale.

Tasks

ToolRead-onlyDescription
list_tasks✅List tasks on a document, filterable by status, readiness, blocker chain, and section.
create_task❌Add a new task with acceptance criteria. Tasks may only be added to Briefs in build phase.
update_task❌Edit a task's status, title, description, acceptance criteria, blockers, or owning section. All in one call.
delete_task❌ (destructive)Remove a task. The only destructive tool — Claude prompts the user before calling.

Comments

ToolRead-onlyDescription
add_comment❌Add a comment to a section, decision, or task. 12 comment types model agent ↔ human handoff (progress, issue, question, discussion, cross_reference, drift, etc.).
list_comments✅List comments by target ref or doc-level, optionally filtered by comment type or shaped for review/task-notes contexts.
update_comment❌Edit your own comment's body or type.
ToolRead-onlyDescription
search_memex✅Semantic + full-text search across Briefs, Standards, free-form documents, and Decisions in a Memex. Filterable by kind (brief / standard / decision / document).

Integrations

ToolRead-onlyDescription
memex__send_slack_message❌Send a Slack message as the authenticated user via the connected Slack integration. Targets a channel, DM user ID, or display name.
// worked examples

Worked examples

Three end-to-end flows that exercise the connector's read and write paths. Each runs in a few seconds and covers the patterns most teams hit in their first week.

Example 1 — Draft a new Brief from a Slack thread

Scenario. A Slack discussion converges on a decision to add a "soft-delete" toggle to your archive API. You ask Claude to capture it as a Brief so the team has a single live doc to plan against.

Prompt. In memex, in acme/api, draft a Brief titled "Soft-delete on the archive endpoint". Add a section called "Background" summarising the Slack thread, an "Approach" section with the implementation outline, and a candidate decision asking whether soft-deletes should be hard-deleted after 30 days. Status: draft.

Tools invoked.

  • list_memexes — Claude confirms the acme/api Memex is in scope.
  • create_doc — creates the Brief with title + initial Background section.
  • add_section — appends the Approach section.
  • create_decision — adds the 30-day-retention question with status: 'candidate'.

What you see. Claude prints the new Brief's canonical ref (acme/api/briefs/b-42) and its URL. Open the URL in the Memex UI: you see the Brief in draft phase with two sections, one candidate decision, and no tasks yet (tasks come later, once decisions are resolved and the Brief moves to build).

Memex UI showing a newly-created Brief with Background and Approach sections plus a candidate decision
The newly-created Brief in the Memex web UI, with both sections and the candidate decision visible.

Example 2 — Resolve open decisions in an active Brief

Scenario. A Brief is mid-build. You want to see what's blocking progress, resolve a decision the team agreed on yesterday, and confirm the Brief is ready to advance.

Prompt. In memex, show me the open decisions on acme/api/briefs/b-42. The 30-day-retention question — we decided yes, default to 30 days, configurable per-tenant. Resolve it with that rationale. Then assess the Brief — what's left before we can move it to verify?

Tools invoked.

  • get_doc — fetches the Brief with its decisions + tasks.
  • resolve_decision — closes the candidate decision with the chosen option + rationale. Triggers unblocking of any task that depended on it.
  • assess_brief — runs the automated readiness assessment, returns a structured list of remaining gates (open comments, incomplete tasks, missing acceptance criteria).

What you see. Claude lists the open decisions, then a confirmation that the retention decision is resolved with your stated rationale. The assess_brief output reads like a checklist — "6 of 8 tasks complete; t-7 is in_progress, t-8 is ready; 2 comments open on dec-3 awaiting response" — and Claude offers to take the next ready task.

Memex UI showing the resolved decision with the chosen option, rationale, and the assess_brief output panel listing remaining gates
The resolved decision with the captured rationale, alongside the readiness assessment panel.

Example 3 — Flag drift on a Standard and propose a fix

Scenario. You're reading code and notice the API doesn't follow what a Standard says ("All API responses use UTC ISO-8601 timestamps"). You want to record the drift so a future agent picks it up, and propose a tightening to the Standard so the same mistake can't recur.

Prompt. In memex, search for the standard on API timestamps. Flag drift on packages/server/src/routes/api/exports.ts:48 — the standard says ISO-8601 with a trailing Z, the code emits epoch milliseconds. Then propose a candidate change to the Standard to add a migration-lint sub-rule that catches this at the source.

Tools invoked.

  • search_memex with kind: "standard" — locates the timestamps Standard semantically.
  • add_comment with type: "drift" — records the drift on the Standard's relevant section, with the file + line number of the offending code and a verbatim quote of the code excerpt.
  • create_decision with status: "candidate" — opens a candidate revision on the Standard, proposing the new sub-rule plus structured options + trade-offs for the human to pick.

What you see. Claude returns the Standard's ref, the drift comment it added, and the candidate decision pending review. Anyone reading the Standard now sees a flagged drift item with provenance. The candidate sits in candidate state until a human approves it via approve_candidate (or rejects via reject_candidate with rationale).

Memex UI showing the drift comment attached to std-7 with the offending code reference, alongside the candidate standard change pending review
The drift comment on std-7 with the candidate change visible in the review queue.
// privacy & support

Privacy & support