Docs.

1. What StratOps isThe idea, and how it differs from a database with a chat box on it.
2. Connecting it in ClaudeSettings, Connectors, the /mcp URL, signing in.
3. The 44 toolsGrouped by what you'd actually be trying to do.
4. ModulesWhat each one owns, its default, and how to switch it off.
5. The dashboardWhat's at /app, page by page.
6. How editing worksApproval in conversation, the closed form registry on the dashboard, and undo.
7. The audit logWhat it records, what it deliberately never records, and what it doesn't cover yet.
8. Where it stopsThe plain list, not the pitch.

What StratOps is

StratOps is a system of record that you talk to instead of typing into. It runs as a single Cloudflare Worker over one D1 database and speaks MCP — there is no separate app to install. You connect it to Claude once, and from then on it is a set of tools Claude can call in the course of an ordinary conversation.

The distinction worth holding onto: this is not a database with a chat interface bolted on. A chat interface over a database still asks you to describe what you want in terms of rows and fields. StratOps' tools are named for the sentence you'd actually say — log_meeting, record_decision, update_deal — and each one writes everything that sentence implies in a single call. Say you just got off a call with someone, and the meeting, the contact, the task you owe them and the deal it moved can all land in one approval.

Reads never ask permission; writes always do, once, naming what they are about to record. That split, across the 44 tools and five layers described in full below, is the entire design. There is no dashboard-only feature and no conversation-only feature except four things that need a browser by nature: connecting an external account, switching a module, issuing a credential, and uploading a file. Everything else is reachable by talking.

Connecting it in Claude

There is no install, no download, no app store listing. You add StratOps as a custom connector, the same way you'd add any MCP server.

1. Open Settings.In Claude, go to Settings, then Connectors.
2. Add a custom connector.Choose "Add custom connector" and give it a URL ending in /mcp — the live one is https://stratops.stratops.workers.dev/mcp.
3. Sign in with Google.Claude opens a browser tab for the OAuth flow. Approve it, and Claude holds a token it presents on every call from then on.
4. Start talking.Claude now has whatever tools your enabled modules grant — up to 44 of them. Reads run without asking; writes ask once, before anything is saved.

It answers before you connect anything

$ curl https://stratops.stratops.workers.dev/health
{"ok":true,"environment":"production","foreign_keys":"enforced"}

/mcp refuses any request carrying a browser Origin header, with a 403 — Claude's own infrastructure sends none, so this stops a page in a tab from reaching your record, including this one. It is not authentication; the bearer token from the OAuth flow is what actually determines which account a call resolves to.

The 44 tools, grouped by what you're trying to do

Not grouped by which file they live in — grouped by the question or the sentence that would make you reach for one. Every write tool names, in its own description inside Claude, the nearest neighbour it might be confused with, so the model (and you) can tell them apart without reading source. "Type" below is Free for a read that never prompts, Write for one that always asks once, and Write, can overwrite for a write that can revise or retire a row that already existed — the case CLAUDE.md's own rule says deserves the bigger warning.

Asking questions — 19 tools, all free

Every one of these runs without a permission prompt. That's deliberate: asking should cost nothing, so there can be a lot of them and each can be precise.

Recording what happened — 8 tools, one approval each

Named for the past-tense verb in your own sentence. Each one writes everything that sentence implies in a single call.

Correcting the record — 7 tools

These change something that already exists, rather than adding something new. Every one writes the state-history trail throughput and stuck-work reporting are derived from.

Working through a backlog — 4 tools

Capture on this account is well used — 506 tasks, 51 ideas, 190 observations, 112 decisions on record. Closing them one at a time is not: 211 of those tasks are done, but 0 observations have been triaged and 0 decisions carry an outcome. These four tools exist because a backlog that size needs a verb that acts on a set, not one more single-item tool.

Setting things up — 6 tools

Rare, and kept away from capture on purpose, so configuring how StratOps behaves never competes for selection with recording what just happened.

Modules, and how to switch them off

A module is a slice of the product — a set of tools, and whatever dashboard pages go with them — that can be turned on or off for the account. Nothing is deleted when a module goes off: its rows sit exactly as they were, unreachable until it comes back on. Say, in conversation, "turn off Time tracking" or "I don't use Signals," and it's set_modules that does it — the same tool is what you'd use to turn one back on.

core cannot be switched off. It holds the tools every other module depends on, including the switch itself — a control panel able to disable its own switch has no way back in short of someone editing the database by hand.

An account that has never touched set_modules gets every default-on module — the product as it ships today, not a stripped-down trial. time and documents are the two exceptions.

The dashboard

Talking is the primary surface, but six months of record is 8,724 rows, and no amount of good prose makes that browsable. The dashboard at /app is the other half: a place to sign in with the same Google account and look at the whole record at once, plus the handful of things that need a browser by nature — connecting an external account, switching a module, issuing a credential, uploading a file.

Signing in sets an HMAC-signed session cookie. It is not a credential /mcp can accept — that endpoint only takes a bearer token resolved against the credential table, and a browser session is never allowed to become a row there. The identity behind a session is re-checked against the database on every page view rather than trusted from the cookie, which is what makes revoking access possible at all: a stateless session has no row to delete, so this is where cutting someone off actually happens.

Pages, grouped the way the sidebar groups them:

A disabled module's page 404s outright rather than merely disappearing from the sidebar menu — a hidden link with a live route is one bookmark away from being visible again, and that is not the same thing as access being actually withdrawn.

How editing works

There are exactly two ways to change what's recorded, and they are built very differently on purpose.

In conversation

Claude picks a write tool, shows what it is about to record, and you approve once. Every write tool validates everything it can before writing anything: log_meeting checks every attendee, every task title and every workstream reference before the first row lands, so a call that would fail on its fifth task fails before the first four are written — a rejected call costs zero rows, not a half-written meeting. When a name is ambiguous — two contacts both plausibly "Sarah" — the tool refuses and names both candidates rather than guessing, because a wrong guess creates a duplicate that silently splits that person's deals and meetings across two records.

If a multi-part write partly succeeds — a database fault after the third of five tasks, say — the error names exactly what was already written and what wasn't, so nothing has to be re-entered or double-recorded to recover.

On the dashboard

The dashboard's forms do not post a tool name and its own arguments to the Worker — that would let any page reach any of the write tools with arguments of its choosing, which is a code-execution surface wearing a form's clothes. Instead every form on /app names one of exactly six predefined actions, each of which calls exactly one tool with arguments the server itself reads out of the submission:

Every submission is checked against a CSRF token and the same re-verified session the page itself required, and no dashboard action ever deletes anything — that stays a deliberate limit while there's no general undo behind it. The other thirty-eight tools, including every destructive one that isn't in that list of six, are reachable only in conversation, where Claude states what it's about to do before it does it.

Undo

retract_capture reaches back exactly one step: the most recent capture, named by the id that call returned, and nothing older. It deletes only the rows that call itself created — a contact the meeting merely matched, rather than created, is left alone even though the meeting mentions them, because deleting anything a later call also touched is how this tool once produced real data loss during development. Once anything else has been recorded after it, the newer records are named and nothing is deleted; correcting an older mistake means saying the correction, not undoing it. A contact update has no undo at all, which is exactly why an ambiguous name is refused rather than guessed at write time.

The audit log

get_audit_log reads an append-only, account-scoped trail of writes — never reads, and it exists specifically to answer "what changed and when," not "who looked at what."

What it records

Only the shape of a write: which row changed, what kind of row it was, what happened to it (created, updated, status changed), and which fields moved. It never records a field's actual value, and never a token or a secret — the same line the separate sign-in audit trail already draws for authentication events, applied here to the record itself. Every audit row is written in the exact same atomic batch as the change it describes, so the two can never disagree: an audit row written as a separate step could commit while the change it claims to describe rolled back, or the reverse, and a trail that can be wrong is worse than no trail, because it would still be trusted.

What it deliberately never records

• Reads. A single call to get_today_briefing issues dozens of SELECTs; logging those would roughly double the write volume of the most-used tools, for a log almost nobody would ever query.
• Values. Only which fields changed, never what they changed to or from.
• Anything past 180 days. Rows older than that are pruned automatically — opportunistically, on every write, since nothing in this deployment runs on a schedule that could do it any other way.

Where it stops

Facts about today, not a roadmap.

• One person per account, and it isn't a setting. No user, session, member or role table exists separately from the account row itself. A second person cannot get a credential today short of an operator running SQL by hand, and the Google consent screen behind sign-in lists exactly one test user.
• Alerts are stored faithfully and never fire. set_alert writes the condition correctly, but no checker exists anywhere in this deployment, and nothing runs on a schedule — no [triggers] in the Worker config, no scheduled handler. Nothing arrives while you're not asking.
• Documents are metadata, not files. list_documents and create_task's sibling tools can record a document's name, type and size, but the file's actual bytes are never stored or searched by anything here, and there's no upload path. That's also why the documents module ships off by default.
• The dashboard can change six things. Conversation can change everything. The closed action registry in the "How editing works" section above is the entire dashboard write surface. Every other tool, including every genuinely destructive one, is reachable only by talking to Claude.
• The audit log covers five tools out of forty-four. See the section above. A write outside that set leaves no trail today, and the table itself may not exist on the live database yet.
• Undo reaches one step back. retract_capture undoes the single most recent capture and nothing older. There is no general undo, no version history, no trash.
• No export tool. There's no button and no route that hands your data back to you in a file. What exists instead is the shape of the storage: the rows sit in a D1 database, which is plain SQL, reachable by whoever holds the Cloudflare account.

Write to Jake