Skip to content
Official MCP RegistryListed

ZeroWidth Ledger

Part ofZeroWidth LedgerMCP server

Log decisions with expectations, add evidence, and track metrics in Ledger.

First seen 7 Oct 2026. Evidence as of 17 Oct 2026.

40
Tools
From an anonymous probe
1
Source listings
Each with its own history
43
Recorded changes
Since first seen

Tools

ToolDescriptionBehaviour
comments_createPosts a comment on a workspace entity — a new thread, or a reply when rootId is given. Use it to leave findings where the discussion already lives (an eval result on the flow being debated, a summary on a long thread). Mention people via mentionedUserIds (from workspace member ids) to ring their notification bell; never mention someone who didn't ask to be pulled in.Changes data
comments_listLists the comment threads on one workspace entity (open first, then resolved) with authors and timestamps. Read this before weighing in on contested work — the threads are where disagreement lives before it becomes a decision.Read-only
comments_resolveSets a comment thread's resolved state (rootId = the thread's root comment id). Resolve ONLY when the human asked or the thread's question is demonstrably settled — and say what settled it in a reply first. Reopening is for new evidence.Destructive
entity_tags_browseWithout a tag: every tag in use across the workspace with how many entities carry it, most-used first — the vocabulary the team already organizes by. With a tag: everything filed under it across every tool, each with its kind, id, title, and path. Use it to reuse existing labels instead of inventing near-duplicates, and to answer 'show me everything about X' when X is a label.Read-only
entity_tags_getReturns the tags on a batch of entities of one kind — the labels galleries organize by. Ids come from the kind's list/get tool or from search_workspace. Use it before entity_tags_set so you replace the full set knowingly, and to answer 'what is this filed under'. Entities the user can't see are omitted.Read-only
entity_tags_setReplaces the FULL tag set on one entity (an empty list clears it). Read the current tags with entity_tags_get first and pass the merged list — this is not additive. Tags are lowercase letters, numbers, spaces, and hyphens; prefer labels already in use (entity_tags_browse) so the workspace's vocabulary stays small. The id comes from the kind's list/get tool or search_workspace.Destructive
get_docFetch the full Markdown body of a specific docs page by its slug. Use this after `search_docs` when the user needs the complete content of a page. No authentication required.Read-only
ledger_entries_add_evidenceRecords what happened against an open decision — a manual observation the user reports ('the pilot team says triage feels faster'), an implementation note, or a reference to a Caliper run. Evidence is what settlement later reads, so attach it as it arrives and cite it in the lesson. Metric readings attach themselves via ledger_metrics_record_reading — don't duplicate them here. Fails with conflict on superseded entries. Ids come from ledger_entries_list. May return `needs_confirmation`.Changes data
ledger_entries_createRecords a memory entry. Every entry is a TITLE (`summary`: one short plain sentence) over a BODY (`rationale`: the detail, markdown welcome) — never put the detail in the title. Three kinds: `decision` — a change being made now; PRE-REGISTRATION IS THE POINT, so `prediction` (what we expect) must be written NOW, before any evidence exists, and never backfilled to match an outcome. `lesson` — a distilled belief the team already holds (`lesson` text required, no prediction). `observation` — a durable fact worth remembering (no prediction): something already true, never something planned. Ideas, pitches, backlog items, and upcoming work are NOT entries — a dated piece of work that carries out a decision is a plan item (ledger_plan_add on that decision), and a running list you keep across runs belongs in a Napkin doc or sheet. When a user states something durable about their business in conversation, offer to capture it as a lesson or observation. When a user shares MEETING NOTES, propose the decisions you find with ledger_entries_draft so they keep or drop each one in Ledger; use this tool for an entry they've asked you to record. Link the Compass pages the entry touches so future consult-before-acting finds it. May return `needs_confirmation` — summarize the entry and wait for approval.Changes data
ledger_entries_draftWrites up to 50 entries as DRAFTS: proposals that stay out of the record until a person confirms each one in Ledger's Drafts view. Use it for entries you found rather than were told — decisions in meeting notes, or a team's past changes read from its tracker, pull requests or launch posts (set `fromHistory: true`). For history: take each claim from what the source said AT THE TIME, set `landedAt` to when it shipped, attach the source URL, and leave `rollout` as full unless the source says otherwise. These read as low confidence because they were written down after the fact; say so plainly rather than overstating them. Tell the person how many drafts are waiting and that they review them under Decisions → Drafts. May return `needs_confirmation`.Changes data
ledger_entries_getOne entry's full anatomy — the six fields, attached evidence (Caliper runs, measurements, observations), and the supersede chain (what replaced it, or what it replaced). Cite entry ids when telling the user about prior related decisions.Read-only
ledger_entries_listThe workspace's memory: decisions (changes with pre-registered expectations), lessons (distilled beliefs), and observations (captured facts). CONSULT BEFORE ACTING — before proposing a flow change, prompt edit, or process decision, filter by the Compass page it touches (compassPageId) and check whether prior attempts exist and how they settled. Filter status=open for unsettled expectations awaiting evidence (each carries a derived `lapsed` flag — true when its deadline has passed; surface lapsed ones when the user asks what needs attention); kind=lesson for what the team already believes.Read-only
ledger_entries_retractTakes an entry out of the curated ledger — THE remedy when you recorded something wrong (a decision that wasn't made, a duplicate, a fact the user corrects). Reversible from Ledger and fully audited, so it is safe to offer as soon as the user says 'that's not right'. Not for overturning a settled claim the team once believed — a human supersedes that. Fails with conflict if already retracted. Ids come from ledger_entries_list. May return `needs_confirmation`.Destructive
ledger_entries_settleThe ritual moment: evidence has landed, the expectation closes, the lesson is written. Only propose settlement when attached evidence actually answers the prediction — check `ledger_entries_get` first and cite the evidence in the lesson. `lesson` (what we now believe) is required and permanent; settlement happens exactly once. May return `needs_confirmation`.Destructive
ledger_entries_updateCorrects an entry in place — its title (summary), body (rationale), the pre-registered prediction of an OPEN decision (null clears it), or its facet (filing category; editable even after settlement). Works on open decisions, and on lessons, observations, and beliefs (they carry no expectation, so fixing their wording is fine any time). Use to fix a typo, swapped fields, or a misrecorded detail. Never edits kind or lesson. Fails with conflict on a settled decision — its claim is corrected by a human superseding it in Ledger — and on superseded or retracted entries. Entry ids come from ledger_entries_list. May return `needs_confirmation`.Destructive
ledger_feed_sources_listThe connected servers this workspace exposes to you, with the id a feed needs. Their tools appear to you namespaced as `ext__<name>__<tool>` — call one directly to see what it returns before proposing a feed. A server the workspace has switched off for you is not listed and cannot be fed from here.Read-only
ledger_feeds_backfillRun the same frozen instruction over a past range, so a metric has history instead of starting the day it was set up. Offer this whenever you create a feed — a chart with a year behind it is worth far more than one that begins today, and an expectation can be judged against what normal looked like. Works when the source returns a series; a source that only ever reports 'right now' will write one point. Safe to repeat: overlapping ranges dedupe. Keep ranges to a few hundred points; a run that fills up says so. May return `needs_confirmation`.Changes data
ledger_feeds_createFreeze a tool call as a metric's standing source: it runs on the cadence you give and records what it finds, with no model involved. `metric` takes an id or a snake_case slug; an unknown slug starts tracking that metric. Confirm the mapping with ledger_feeds_preview first. Tell the user they can backfill history afterwards with ledger_feeds_backfill. May return `needs_confirmation`.Changes data
ledger_feeds_deleteRemove a feed. The readings it already wrote stay — the series is the record and outlives the instruction. Prefer pausing with ledger_feeds_update when the user might want it back. May return `needs_confirmation`.Destructive
ledger_feeds_listThe standing instructions for how metrics' numbers arrive — which tool each one calls, how often, and how the last run went. Check before proposing a feed so you don't duplicate one, and consult when a user asks why a metric is stale: a feed with a failing last run is usually the answer.Read-only
ledger_feeds_previewCall a connected server's tool once and see what a mapping would pull out of the response — nothing is written and no feed is created. Send no `mapping` for a first look: you get a sample of the response plus the paths that hold numbers. Then send a mapping to confirm it finds the readings you expect. Always do this before ledger_feeds_create; proposing a feed whose mapping you haven't seen work is how a metric fills up with the wrong number. May return `needs_confirmation`.Changes data
ledger_feeds_runRun a feed immediately over its own window and record what it finds. Use it right after creating one to prove the mapping works — a run that comes back `empty` names the path that missed, which is what you fix with ledger_feeds_update. Does not move the feed's schedule. Re-running is safe: readings dedupe per time bucket. May return `needs_confirmation`.Changes data
ledger_feeds_updateChange a feed's arguments, mapping, cadence, or pause it. Reach for this when a feed's last run reports `empty` (the response shape moved, so the mapping needs a new path) or `error`. Changing the mapping changes what the number means, so say what you're changing and why. May return `needs_confirmation`.Destructive
ledger_metric_presets_adoptCreates the named presets as real metrics the workspace owns, tagged from the catalog. Safe to repeat: a preset the workspace already has comes back `already_present` rather than creating a second series, and a workspace's own renames and targets are never overwritten. Adopt only what the user agreed to — a metric nobody reads is noise on the Metrics tab, and eight thoughtful ones beat forty. Tell them the metrics start empty and the next step is a feed (ledger_feeds_create) or a first reading. May return `needs_confirmation`.Changes data
ledger_metric_presets_listReady-made metrics a business can start tracking, each with a unit, a cadence, which direction is good, a business surface (facet), and cross-cutting tags. Reach for this when a workspace has few or no metrics, when someone asks what they should be measuring, or when a decision needs a number to settle against and none exists. Filter by `facet` (where it lives in the business) or `tag` (what kind of number it is). Suggest a SMALL set — three to six that fit what you know about this business — and say in one sentence why each one, rather than listing the catalog. Adopt with ledger_metric_presets_adopt. These are starting points: a workspace renames and retargets them freely afterwards.Read-only
ledger_metric_starters_adoptCreates a starter's metrics at their levels and links them. Pass `slugs` to keep only some of its metrics; links are made only where both ends exist. Safe to repeat and safe after a different starter: metrics the workspace already has are left as they are and get linked into the tree. Adopt only what the user agreed to. Tell them the metrics start empty and the next step is connecting a source (ledger_feeds_create) or a first reading. May return `needs_confirmation`.Changes data
ledger_metric_starters_listStarter trees by shape of business or team (subscription software, services firm, online store, sales team, service operation). Each lists its metrics with a level (outcome / driver / activity) and the links between them (which number moves which). Reach for this before ledger_metric_presets_list when a workspace has no metrics yet or asks how its numbers fit together: pick the starter that matches what you know about the business, describe its tree in a sentence or two, and offer to adopt it with ledger_metric_starters_adopt, dropping any metric that doesn't fit.Read-only
ledger_metrics_archiveTakes a metric out of the gallery (`archived: true`) or puts it back (`false`). Readings stay, and entries that settled against it still read correctly — this is the cleanup for a metric minted once and abandoned, or one the workspace stopped watching. `metricId` accepts the id or slug from ledger_metrics_list. May return `needs_confirmation`.Destructive
ledger_metrics_createCreate a metric — a number the workspace watches (triage time, weekly signups, cost per run). Check ledger_metrics_list first; names are unique per workspace. When a user says they want to track or measure something, offer this. May return `needs_confirmation`.Changes data
ledger_metrics_getOne metric's definition (unit, kind, direction, target, cadence) plus its readings newest first and the open decisions bound to it. Use before answering 'how is X trending?' or before recording a reading against it. `metricId` accepts the id or the snake_case slug from ledger_metrics_list. For an event metric whose readings carry labels, `labels` lists each label and its values, largest total first. Pass `slice` to get the series for part of it ("new users in DE"), or `by` to split the series by one label ("new users by country"); either returns `series`, summed per `bucket`.Read-only
ledger_metrics_listThe numbers the workspace watches — each with unit, latest reading, and how many open decisions are bound to it. Consult when a user mentions a number that sounds like a tracked metric, and before recording a reading.Read-only
ledger_metrics_record_readingRecord one observation of a tracked metric. `metricId` accepts a metric id OR its snake_case slug from ledger_metrics_list; an unknown one is a not_found error — check ledger_metrics_list, create it with ledger_metrics_create, or pass `createIfMissing: true` to mint a "measure" metric at that slug in the same call (an "event" metric when the reading carries `labels`). The reading automatically lands as evidence on every open decision whose prediction is bound to this metric — so when a user reports a number ("triage is down to 12 minutes"), offer to record it. For event-kind metrics, omit `value` to count one occurrence. May return `needs_confirmation`.Changes data
ledger_metrics_updateCorrects a metric's name, unit, description, kind (measure / event), direction (which way is good), target, cadence, icon, level, or the metrics it drives (its place in the metric tree). Readings are untouched. Only what you pass changes. The slug is not editable here — external writers address metrics by slug. Fails with conflict when a rename collides with a live metric. `metricId` is the id from ledger_metrics_list. May return `needs_confirmation`.Destructive
ledger_plan_addAdds a plan item to an OPEN decision (the work that carries it out: a post, a launch step, an email). Omit entryId for a standalone date (a holiday, an event you're only watching). Items are all-day unless you pass startTime with timeZone (and optionally endTime), for a webinar, a scheduled post, or a launch at noon. If the date costs money or time and comes with an expectation, record it as a decision with ledger_entries_create instead. Use repeatWeeklyUntil for a weekly cadence: it writes one row per week (max 60), each movable on its own. Fails with conflict once the decision is settled. May return `needs_confirmation`.Changes data
ledger_plan_deleteRemoves one plan item while its decision is open, for an item added by mistake or work that's no longer planned. If the work was planned and then dropped, prefer ledger_plan_update with status 'skipped' so settlement can see it. Fails with conflict once the decision is settled. May return `needs_confirmation`.Destructive
ledger_plan_listPass `entryId` for one decision's plan items, or `from` + `to` (YYYY-MM-DD, at most about a year apart) for the calendar: decision spans (recorded day → expectation deadline) plus every dated item inside the window, including standalone dates with no decision. Filter the calendar by `ownerUserId` to answer 'what's mine this week' or to find tomorrow's items to draft. Never use it to compare or rank people's output.Read-only
ledger_plan_updateEdits one plan item while its decision is open: move it (dueOn), rename it, change the owner (null clears), attach the link, or set status (planned | done | skipped). Mark done only when the user says it shipped; a link alone doesn't mean done. Fails with conflict once the decision is settled. May return `needs_confirmation`.Destructive
list_docsEnumerate all available docs pages, optionally filtered by product (e.g. 'compass', 'legal', 'overview'). Use this to discover what slugs exist before calling `get_doc`. No authentication required.Read-only
search_docsSearch ZeroWidth product documentation. Returns matching pages with title, slug, public URL, and a query-relevant snippet. Use this when the user asks about a ZeroWidth product (Compass, Workbench, Caliper, Prism, Ledger, Napkin, zv1), an API behavior, or a policy. No authentication required — the docs corpus is public.Read-only
search_workspaceFinds anything in the workspace in one call — uploaded files (searching the text inside them), folders, Workbench flows, shims, knowledge bases and tasks, Compass pages and changes, Caliper datasets, evals, rubrics, reviews, specs and sources, Ledger entries, Napkin sketches, decks, docs, sheets, diagrams and interfaces. The same search the person uses in Home. Use it FIRST whenever the user mentions something without saying where it lives ('the SOW', 'the dispatch interviews', 'that invoice'). The query is words in any order: each word must appear in the thing's name, its tags, the names of the folders it's filed under, or the text inside it — so 'northwind sow' finds the SOW filed in the Northwind folder, and 'dispatch interview' finds 'Dispatcher interview 1.md'. Results are ranked best first. Each hit carries its id, kind, path (for a link), folderPath (where it's filed, top-down), tags, and a snippet when the words were found inside it rather than in its name — say where a thing lives using folderPath. A file's id feeds workspace_files_read; other ids feed the kind's *_get tool. Pass folderId to search only inside one folder and everything under it. If nothing comes back, try fewer or different words before telling the user it doesn't exist. Results only include what the user can see, and only kinds this token may read.Read-only

Change history

  1. search_workspace: input schema changed (+folderId)
  2. search_workspace: description changed (+"anything in the workspace" +"uploaded files (searching the text inside them), folders," +"shims, knowledge bases and tasks,")
  3. search_workspace: annotations changed
  4. search_docs: annotations changed
  5. list_docs: annotations changed
  6. ledger_plan_update: annotations changed
  7. ledger_plan_list: annotations changed
  8. ledger_plan_delete: annotations changed
  9. ledger_plan_add: annotations changed
  10. ledger_metrics_update: annotations changed
  11. ledger_metrics_record_reading: annotations changed
  12. ledger_metrics_list: annotations changed
  13. ledger_metrics_get: annotations changed
  14. ledger_metrics_create: annotations changed
  15. ledger_metrics_archive: annotations changed
  16. ledger_metric_starters_list: annotations changed
  17. ledger_metric_starters_adopt: annotations changed
  18. ledger_metric_presets_list: annotations changed
  19. ledger_metric_presets_adopt: annotations changed
  20. ledger_feeds_update: annotations changed
  21. ledger_feeds_run: annotations changed
  22. ledger_feeds_preview: annotations changed
  23. ledger_feeds_list: annotations changed
  24. ledger_feeds_delete: annotations changed
  25. ledger_feeds_create: annotations changed
  26. ledger_feeds_backfill: annotations changed
  27. ledger_feed_sources_list: annotations changed
  28. ledger_entries_update: annotations changed
  29. ledger_entries_settle: annotations changed
  30. ledger_entries_retract: annotations changed
  31. ledger_entries_list: annotations changed
  32. ledger_entries_get: annotations changed
  33. ledger_entries_draft: annotations changed
  34. ledger_entries_create: annotations changed
  35. ledger_entries_add_evidence: annotations changed
  36. get_doc: annotations changed
  37. entity_tags_set: annotations changed
  38. entity_tags_get: annotations changed
  39. entity_tags_browse: annotations changed
  40. comments_resolve: annotations changed
  41. comments_list: annotations changed
  42. comments_create: annotations changed
  43. Listed (registry)
Source listings
SourceListingFirst seenLast seenVersions
Official MCP Registryai.zerowidth/ledger7 Oct 202617 Oct 20261