# ZeroWidth Compass (remote · api.zerowidth.ai)

Read and update your Compass map: pages, changes, opportunities and interviews.

- Trust score: 73/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-24

## Components

- remote · `api.zerowidth.ai`: 73/100 (this document), [markdown](https://verifymcp.io/servers/ai-zerowidth-compass/mcp-x-compass.md), [page](https://verifymcp.io/servers/ai-zerowidth-compass/mcp-x-compass)

## Channel facts

- Endpoint: `https://api.zerowidth.ai/mcp/x/compass`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-24.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (compass_pages_update).
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 86/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Tool/resource definitions use about 17388 tokens (~88/item across 196 items; 62 tools + 134 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 53/100
  - Stability observed for 16 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 97/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 90% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 63 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the ZeroWidth Compass MCP server?

ZeroWidth Compass is a hosted endpoint at https://api.zerowidth.ai/mcp/x/compass, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http ai-zerowidth-compass 'https://api.zerowidth.ai/mcp/x/compass'
```

### Cursor

```json
{
  "mcpServers": {
    "ai-zerowidth-compass": {
      "url": "https://api.zerowidth.ai/mcp/x/compass"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "ai-zerowidth-compass": {
      "type": "http",
      "url": "https://api.zerowidth.ai/mcp/x/compass"
    }
  }
}
```

### Codex

```toml
[mcp_servers.ai-zerowidth-compass]
url = "https://api.zerowidth.ai/mcp/x/compass"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-zerowidth-compass": {
      "type": "remote",
      "url": "https://api.zerowidth.ai/mcp/x/compass",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ai-zerowidth-compass --url 'https://api.zerowidth.ai/mcp/x/compass' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ai-zerowidth-compass:
    url: "https://api.zerowidth.ai/mcp/x/compass"
```

### Netclaw

```json
{
  "McpServers": {
    "ai-zerowidth-compass": {
      "Transport": "http",
      "Url": "https://api.zerowidth.ai/mcp/x/compass"
    }
  }
}
```

### Vellum

```bash
assistant mcp add ai-zerowidth-compass -t streamable-http -u 'https://api.zerowidth.ai/mcp/x/compass'
```

### Other

```json
{
  "mcpServers": {
    "ai-zerowidth-compass": {
      "type": "http",
      "url": "https://api.zerowidth.ai/mcp/x/compass"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-23 (score 73, 0)

- [security] Tool “compass_gaps_resolve” rewrote its description, which is the text the model reads
- [security] Tool “compass_interviews_create” rewrote its description, which is the text the model reads
- [security] Tool “compass_map_view” rewrote its description, which is the text the model reads
- [security] Tool “compass_step_claims_propose” rewrote its description, which is the text the model reads
- [security] Tool “search_docs” rewrote its description, which is the text the model reads
- [functional] New tool “compass_role_story”
- [functional] New tool “compass_roles_overview”
- [cosmetic] “compass_opportunities_mark_implemented” added an optional parameter “applyToMap”

### 2026-10-22 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-20 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-18 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-17 (score 70, 0)

- [security] Tool “compass_step_claims_propose” rewrote its description, which is the text the model reads
- [security] Tool “search_workspace” rewrote its description, which is the text the model reads
- [cosmetic] “search_workspace” added an optional parameter “folderId”
- [cosmetic] “compass_links_create” reworded the description of “sourceId”
- [cosmetic] “compass_links_create” reworded the description of “sourceKind”
- [cosmetic] “compass_step_claims_propose” reworded the description of “sourceId”
- [cosmetic] “compass_step_claims_propose” reworded the description of “sourceKind”
- [cosmetic] “compass_step_measures_propose” reworded the description of “sourceId”
- [cosmetic] “search_workspace” reworded the description of “kinds”
- [cosmetic] “search_workspace” reworded the description of “q”

### 2026-10-16 (score 70, +1)

- [security] Tool “compass_inbox_list” rewrote its description, which is the text the model reads
- [security] Tool “compass_links_create” rewrote its description, which is the text the model reads
- [functional] Server version: 0.0.0 → 1.0.0

### 2026-10-14 (score 69, +1)

- [security] Tool “compass_priority_steps_find” rewrote its description, which is the text the model reads
- [security] Tool “compass_step_claims_propose” rewrote its description, which is the text the model reads
- [security] Tool “compass_transformations_make_change” rewrote its description, which is the text the model reads
- [functional] New resource “prism/synthetic-panels”
- [functional] New tool “compass_transformations_respond”
- [cosmetic] “compass_interviews_create” reworded the description of “focusPrompt”

### 2026-10-13 (score 68, 0)

- [security] Tool “compass_step_claims_propose” rewrote its description, which is the text the model reads
- [security] Tool “compass_workflow_steps” rewrote its description, which is the text the model reads
- [functional] New tool “compass_priority_steps_find”
- [functional] New tool “compass_transformations_get”
- [functional] New tool “compass_transformations_make_change”
- [functional] New tool “compass_transformations_read”
- [cosmetic] Tool “compass_step_claims_propose” changed its title: Propose who does a workflow's steps → Propose who does a workflow's steps and what in

## MCP tools (62)

### `search_docs` (~111 tokens)

Search ZeroWidth docs

Search 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, the assistant), an API behavior, or a policy. No authentication required — the docs corpus is public.

Input parameters:

- `limit` (integer): Max number of results. Defaults to 10.
- `query` (string, required): Search query — keywords or natural-language phrase.

### `get_doc` (~73 tokens)

Fetch ZeroWidth doc by slug

Fetch 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.

Input parameters:

- `slug` (string, required): Page slug. Accepts 'compass/api', '/compass/api', or 'docs/compass/api'.

### `list_docs` (~75 tokens)

List ZeroWidth docs pages

Enumerate 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.

Input parameters:

- `product` (string): Optional product slug filter (e.g. 'compass', 'legal', 'overview').

### `compass_pages_list` (~236 tokens)

List Compass pages

Lists pages in the active workspace's Compass compendium. Optional `type` filter narrows to one node type (WORKFLOW, PERSON, ROLE, SYSTEM, PAIN_POINT, DOCUMENT, VALUE, PRIORITY, AUDIENCE, OFFERING). Returns summaries, 50 at a time (`limit` / `offset`, `total` and `nextOffset` in the result) — fetch one with `compass_pages_get` for the full body. When you know what you're looking for, `compass_pages_search` is the better first call.

Input parameters:

- `limit` (integer): Page size, default 50. Prefer compass_pages_search when you know what you're looking for.
- `offset` (integer): Skip this many, for the next page.
- `type` (string): Narrow to a specific page type (WORKFLOW, PERSON, ROLE, SYSTEM, PAIN_POINT, DOCUMENT, VALUE, PRIORITY, AUDIENCE, OFFERING).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_pages_search` (~177 tokens)

Search Compass pages

Keyword search over page titles, bodies, and tags (case-insensitive substring match), paginated. The fast way to check whether a subject already has a page before creating or linking. Returns summaries with a 300-char body snippet — fetch full text with `compass_pages_get`.

Input parameters:

- `limit` (integer): Results per page, 1-25. Default 10.
- `offset` (integer): Pagination offset. Default 0.
- `q` (string, required): Search term. Use the most distinctive word or phrase for the subject ('Zendesk', 'invoice approval') — not full sentences.
- `type` (string): Narrow to one page type.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_pages_get` (~108 tokens)

Get a Compass page

Fetches one Compass page by id, including its full Markdown body, header fields, and any attached Napkin sketches — view an attached sketch's actual drawing with `napkin_boards_view` (its boardId) before discussing it.

Input parameters:

- `pageId` (string, required): The page id (from compass_pages_list).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_pages_create` (~316 tokens)

Create a Compass page

Creates a typed page in the workspace's Compass compendium. Check `compass_pages_list` first — don't create a page for a subject the map already has; link to it instead. May return `needs_confirmation` — if so, tell the user what you're proposing, wait for their approval, then re-call with the approvalId. Only record what the human has actually told you.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `body` (string): Markdown body shaped to the type (steps for WORKFLOW, role/contact sections for PERSON, etc.).
- `tags` (array): Optional tags.
- `title` (string, required): ≤80 chars, sentence case, no filler verbs.
- `type` (string, required): Page type for this subject. PERSON = a specific individual; ROLE = a job, separate from whoever holds it (people hold roles); VALUE = something the business won't sacrifice; PRIORITY = an outcome it'…
- `visibility` (string): Who can see it: PRIVATE (only the user), WORKSPACE (every member, the default), or SHARED (specific people, granted afterwards). Say 'make it private' → PRIVATE.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_pages_update` (~372 tokens)

Update a Compass page

Edits an existing page's title, description, body, tags, header fields, or visibility — use this to FIX what you (or an extraction) got wrong instead of creating a duplicate. Fetch the current page with `compass_pages_get` first and preserve what the human wrote; title / body / tags replace the field wholesale, while `headerFields` MERGES over the current ones (send only the keys you're changing — 'set the owner' leaves status alone). Page ids come from compass_pages_list. May return `needs_confirmation` — tell the user what you're changing, wait for approval, then re-call with the approvalId.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `body` (string): New Markdown body — replaces the whole body.
- `description` (string): New one-line gallery summary (≤2,000 chars).
- `headerFields` (object): Partial header fields for the page's type (PERSON: role, email, …; WORKFLOW: owner, status, …) — merged over the current values; the server validates the merged result against the type.
- `pageId` (string, required): Id of the page to edit.
- `tags` (array): New tag set — replaces existing tags.
- `title` (string): New title (≤200 chars).
- `visibility` (string): Who can see it: PRIVATE (only the user), WORKSPACE (every member, the default), or SHARED (specific people, granted afterwards). Say 'make it private' → PRIVATE.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_links_create` (~546 tokens)

Connect two Compass pages

Creates a typed, directed edge between two pages — the knowledge graph's connective tissue. Canonical directions: PERSON or ROLE owns WORKFLOW/SYSTEM/PRIORITY, PERSON or ROLE involved_in WORKFLOW, PERSON holds ROLE, WORKFLOW uses SYSTEM, SYSTEM uses SYSTEM, PAIN_POINT affects WORKFLOW/SYSTEM/PERSON/ROLE, DOCUMENT documents anything, PRIORITY contributes_to PRIORITY (a priority that ladders up to a bigger one; each ladders up to at most one, and choosing a new one moves it; a priority has one owner the same way), UNIT part_of UNIT and ROLE or PERSON part_of UNIT (the org chart: one parent each; a UNIT's lead owns it, one owner), relates_to as fallback. Prefer attaching responsibilities to the ROLE and linking the PERSON to it with holds — the role outlasts whoever is in it. Pass validFrom / validTo when the source says when it was true ('took over approvals in March'), and sourceKind + sourceId for who said so (the interview or page you learned it from). Idempotent on an open (from, to, kind) edge — re-creating one returns it. May return `needs_confirmation`; tell the user what you're proposing, wait for their approval, then re-call with the approvalId.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `fromPageId` (string, required): Edge source page id.
- `kind` (string, required): Edge type, in canonical direction.
- `note` (string): ≤500-char qualifier when the kind alone undersells it.
- `source` (string): Provenance label. Defaults AI_ACCEPTED (agent writing under live human direction); pass USER for human-driven scripts.
- `sourceId` (string): Id of the interview, email thread, Prism report or page named by sourceKind.
- `sourceKind` (string): Who says this is true: an interview, an email thread, a Prism desk-research report (prism_report), a page (a DOCUMENT, or the PERSON who told you), or the user.
- `toPageId` (string, required): Edge target page id.
- `validFrom`: When the relationship started being true (YYYY-MM-DD). Omit when unknown.
- `validTo`: When it stopped being true (YYYY-MM-DD). Only for a relationship that has already ended — recording history.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_process_diagram_ensure` (~246 tokens)

Give a workflow its steps diagram

Returns the Napkin diagram that holds a WORKFLOW page's steps, creating it when the page has none. If the page body has a ```mermaid block, it moves into the diagram verbatim (node ids kept, so changes anchored to a step still point at it) and leaves the body. Then edit the steps with napkin_diagrams_update using the returned diagramId. One diagram per workflow holds every step anyone has described — when two people describe the same process differently, add the steps to this one diagram rather than making a second. A step that is itself a workflow is a node whose meta ref is { type: 'page', id: <that workflow's page id> }. compass_pages_get returns processDiagramId when one exists. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `pageId` (string, required): The WORKFLOW page id.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_page_links_list` (~132 tokens)

List a page's connections

All typed edges touching one page, both directions, each hydrated with the other endpoint's page summary. Use this to understand a subject's neighborhood before adding to it. Current connections only, unless includeEnded — then also relationships that have ended (validTo in the past), for questions like who handled this before.

Input parameters:

- `includeEnded` (boolean): Also return connections that have ended.
- `pageId` (string, required): The page id.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_interviews_create` (~479 tokens)

Invite someone to a Compass interview

Mints a stakeholder-interview invite: a no-account guest link where the person talks to an interviewer agent briefed by your focusPrompt, and the transcript flows back into Compass as reviewable draft pages. THE KNOWLEDGE-GAP MOVE: when caliper_flow_performance shows failures clustered on missing company facts (the judge says the flow invented a policy, missed a rule, didn't know who owns something), the fix is usually not a prompt edit — it's asking the human who actually knows. Write a focusPrompt that names the SPECIFIC gaps (cite the eval run id), pick the owner of the relevant workflow as interviewee when the map knows one. When you have their email, send the link with compass_interview_invite next rather than asking the user to forward it; otherwise hand the user the link. May return `needs_confirmation` — tell the user who you want to interview and why, then wait.

Input parameters:

- `anonymous` (boolean): The guest is told it's anonymous and never asked who they are; no name or email is kept, so leave intervieweeName and intervieweeEmail out, and the link isn't emailed from here. Use when the user ask…
- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `contextPageIds` (array): Compass page ids the interviewer gets as briefing context (e.g. the workflow page whose flow underperformed).
- `focusPrompt` (string, required): The interviewer's aim (≤2000 chars), never shown to the guest: why the team is asking, in one sentence; 2–3 things to come away knowing, each describable from experience (who does a step, what happen…
- `intervieweeEmail` (string): Their email, when known — enables compass_interview_invite to send the link directly (with approval).
- `intervieweeName` (string): Who this invite is for, when known.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_interview_targets` (~169 tokens)

Who should be interviewed about a page

Ranks the PEOPLE the map says know about a page (workflow, system, pain point): `owns` links first, then `involved_in`, then weaker edges. Each target carries contact email + role from their PERSON page and their latest interview (skip someone who just gave one — interview fatigue is real). Empty result = the map doesn't know an owner: ASK THE USER who runs this, create the PERSON page + owns link from the answer, and the map gets smarter. Use before compass_interviews_create to pick the interviewee.

Input parameters:

- `pageId` (string, required): The page the knowledge gap is about.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_interview_invite` (~256 tokens)

Email an interview invite

Emails the guest link for an existing interview, framed as coming from the REQUESTING USER (their name signs it; replies go to them). Author `message` in their voice — short, human, says why THEIR knowledge matters and that it takes ~15 minutes, no account needed. The approval card shows the exact subject + message before anything sends. Limit: the invite plus ONE reminder; a third ask is the user's conversation to have. Completion arrives as a notification with draft-page counts — don't poll.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `email` (string, required): The interviewee's email address.
- `interviewId` (string, required): Interview id from compass_interviews_create.
- `message` (string, required): The body, written in the requesting user's voice. Greeting + link + signature are added automatically — write only the middle.
- `subject` (string, required): Email subject, e.g. '15 minutes on how refunds actually work?'
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_gaps_list` (~148 tokens)

List Compass open questions (gaps)

Lists the workspace's open questions — the gap registry: what the map doesn't know yet. Defaults to OPEN gaps. This is where you keep your head — check it before asking the user something you may already have flagged, and compose interview briefs from a subject's open questions.

Input parameters:

- `status` (string): Filter by lifecycle stage. Default OPEN.
- `subjectId` (string): Only gaps ABOUT this subject id.
- `subjectType` (string): Only gaps ABOUT this subject type (e.g. compass_page).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_gaps_create` (~231 tokens)

Raise a Compass open question (gap)

Records something you don't yet know — the gap registry is your working memory, so use it liberally while mapping or interviewing. Give one clear question, WHY it matters (what answering it unblocks), and how you'd resolve it (ask the user / interview a specific person / connect a source). No approval needed — noting your own uncertainty isn't acting on the user's behalf. Attach it to a subject (subjectType/subjectId) when it's ABOUT a specific page or person.

Input parameters:

- `question` (string, required): The open question, plainly ('Who approves refunds over $500?').
- `rationale` (string): Why it matters / what answering it unblocks.
- `subjectId` (string): Id of the subject.
- `subjectType` (string): What it's about, e.g. compass_page.
- `suggestedResolution` (string): How to resolve it: 'ask the user', 'interview Dana', 'connect Drive'.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_gaps_resolve` (~259 tokens)

Resolve a Compass open question (gap)

Closes a gap once you've learned the answer (ANSWERED, with the resolution) or decided it doesn't matter (DISMISSED). Keep the registry honest — resolve gaps as their answers land (from an interview, a doc, or the user) so it always reflects what's still unknown. The resolution alone isn't the map: when the answer says something about a page (who does a step, a tool they use, how a decision gets made), write it there too in the same turn, on the page it's about or as the step, person or system it names. Gaps you raised close without a card; a question a person wrote needs their approval.

Input parameters:

- `approvalId` (string): Re-call with the approvalId from a needs_confirmation response after the user approves.
- `gapId` (string, required): Id of the gap (from compass_gaps_list).
- `resolution` (string): The answer / note, when marking ANSWERED.
- `status` (string, required): ANSWERED (you learned it) or DISMISSED (irrelevant).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_list` (~216 tokens)

List Compass opportunities

The workspace's changes — fixes, chores, new steps, experiments. Each carries `statusName` (the workspace's own word for where it is) and `statusCategory` (TRIAGE undecided, BACKLOG not started, ACTIVE in progress, DONE, CANCELED dropped), plus the older lane key in `status`. `experiment: true` marks a change measured against the Ledger: `ledgerEntryId` null means no expectation registered; `ledger.verdict` carries confirmed/missed after settlement. Scores (value/feasibility/risk) and a workflow anchor are optional. Filter by lane key in `status` or by workflowPageId; compass_statuses_list has the status names.

Input parameters:

- `status` (string): Filter to one lane.
- `workflowPageId` (string): Only opportunities anchored to this workflow page.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_propose` (~238 tokens)

Propose an AI opportunity

File an AI-PROPOSED opportunity into the workspace's review queue — the scouting verb (the opportunity-scout routine's main move). Unlike compass_opportunities_create this needs NO approval: the proposal itself is the human gate — it lands in the Compass Inbox and the cockpit's Needs-you for accept/dismiss. Check compass_opportunities_list first so you never duplicate an idea. Anchor to a workflow page when one fits; score value/feasibility/risk 1–5.

Input parameters:

- `description` (string, required): What it is and why it's worth trying, grounded in the map.
- `feasibilityScore` (integer)
- `label` (string, required): ≤200 chars, the opportunity in one line.
- `reasoning` (string): One or two sentences on why you're proposing this.
- `riskScore` (integer)
- `valueScore` (integer)
- `workflowPageId` (string): Workflow page to anchor to, when one fits.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_create` (~281 tokens)

Capture an opportunity

Record a change — a fix, a chore, a new step, or an experiment worth trying. Anchor it to a workflow page when one fits (compass_pages_list); leave unanchored otherwise. It lands in the board's first status unless you name another (compass_statuses_list). Set `experiment` only when the user wants it measured against the Ledger. May return `needs_confirmation` — summarize and wait for approval.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `description` (string): What the change is, and why it's worth doing.
- `experiment` (boolean): Measure it against the Ledger. Default false.
- `label` (string, required): ≤200 chars, the change in one line.
- `links` (array): Where the work also lives — issue, ticket, PR or doc URLs.
- `statusName` (string): Start in this status (a name from compass_statuses_list).
- `tags` (array): Tags to file it under.
- `workflowPageId` (string): Workflow page to anchor to, when one fits.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_register_expectation` (~352 tokens)

Pre-register an experiment's expectation

The honesty mechanism: write what the experiment is expected to change BEFORE evidence exists. Creates a Ledger decision entry and links it to the opportunity — never backfill an expectation to match an outcome. Bind a metric (ledger_metrics_list) + comparator + target when the expectation is measurable; readings then land on the entry as evidence automatically. One expectation per opportunity — revise by superseding in Ledger. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `comparator` (string)
- `deadline` (string): ISO date the expectation is due by.
- `expectation` (string, required): One sentence — what we expect this to change.
- `fromRollup` (object): Instead of metricId: measure it off the change's workflow roll-up — a step's (nodeId) or the whole workflow's hands-on time, waiting, labor, or hard cost, per run or per month. Creates a daily-fed me…
- `metricId` (string): Ledger metric to bind (requires target). From ledger_metrics_list.
- `opportunityId` (string, required): The change's key (e.g. ACME-12) or id, from compass_opportunities_list.
- `target` (number): Target value, in the metric's unit (hours for time).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_mark_implemented` (~268 tokens)

Record that the change landed

The measurement window's boundary: when the user says the experiment's change actually shipped / went live / rolled out, record the landing date. Readings before it are baseline; after it, evidence of effect. Recorded once — it cannot move afterward, so confirm the date. Attaches to the linked Ledger entry as evidence. May return `needs_confirmation`.

Input parameters:

- `applyToMap` (boolean): Also move the map from the landing date: who does the change's steps, and how long they take, change as the change's effects say (automate, reassign, assist, relax a check, remove). Confirm with the…
- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `at` (string): ISO date the change landed — omit for today.
- `note` (string): What shipped, if worth recording.
- `opportunityId` (string, required): The change's key (e.g. ACME-12) or id, from compass_opportunities_list.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_map_view` (~295 tokens)

View the Compass map (rendered image)

Renders the workspace's visual map to an image and returns it so you can SEE it the way the user does when they open Map: a transit-style map seen from above. Each workflow is a colored tile with a short code; people are round figures, systems are small squares with a drum, other pages are plain tiles, each named underneath. Lines along the grid join linked pages, solid between a workflow and what it touches, dashed between other pages; pages that link to each other more than to the rest gather into named regions on a pale ground plate, and pages connected to nothing sit together in a "Not connected" plate. zv1's drafts that nobody has accepted are drawn faint. Use this when the user asks about the shape of their map, where things cluster, what connects to what, or anything spatial. The text part counts the pages of each type, the links, and how many pages are unconnected, plus `mapUrl`. The image is for you to look at; do NOT put it in your reply as a markdown image (the chat can't show it). When the user should see the map, link `mapUrl` — e.g. `[Open your map](mapUrl)` — and describe what you saw.

Input parameters:

- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_pages_delete` (~182 tokens)

Delete a Compass page

Moves a page to the trash (soft delete — its connections and anchored opportunities go with it, and compass_pages_restore brings the whole set back). Use this to REMOVE a page you or an extraction created wrongly, or one the user says no longer belongs on the map; to fix a wrong title or body, use compass_pages_update instead. Page ids come from compass_pages_list / compass_pages_search. May return `needs_confirmation` — name the page and wait for approval.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `pageId` (string, required): Id of the page to delete.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_pages_restore` (~155 tokens)

Restore a deleted Compass page

Puts a trashed page back on the map, together with exactly the connections and opportunities its delete took. Use when the user wants a deleted page back (the pageId from the earlier compass_pages_delete, or from the Compass trash). Fails with not_found when the page is already live or never existed. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `pageId` (string, required): Id of the deleted page.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_links_update` (~315 tokens)

Change a connection's reading, note, or dates

Edits an existing edge between two pages: its `kind` (how the two relate), its `note`, and/or when it was true (`validFrom` / `validTo`). Use kind to CORRECT a connection typed wrongly — 'Dana doesn't own billing, she's involved in it'. Use validTo to END one that used to be true — 'Dana handed approvals to Sam in March' ends Dana's edge in March (then create Sam's from March); the old edge stays as history. Don't delete a relationship that ended; end it. Link ids come from compass_page_links_list. Fails with conflict when the new reading already exists between the same two pages (delete this one instead). May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `kind` (string): New edge type, in canonical direction.
- `linkId` (string, required): Id of the link (from compass_page_links_list).
- `note` (string): New qualifier note (≤500 chars); empty string clears it.
- `validFrom`: When it started being true (YYYY-MM-DD); null clears it.
- `validTo`: When it stopped being true (YYYY-MM-DD) — ends the relationship; null reopens it.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_links_delete` (~186 tokens)

Remove a connection between two pages

Deletes one edge from the graph (the pages stay). Use only when a connection was never true — the system isn't used by that workflow, it was recorded by mistake. When a relationship WAS true and has stopped (the person left the team, moved roles), end it with compass_links_update `validTo` instead, so the history stays. Link ids come from compass_page_links_list. Re-creating the same edge later revives it. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `linkId` (string, required): Id of the link (from compass_page_links_list).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_update` (~478 tokens)

Edit an opportunity

Corrects an opportunity's content: label, description, priority, what done means, the 1–5 value / feasibility / risk scores, the owner (a PERSON page), notes, tags, workflow anchor, external link, visibility. Fields you omit are untouched; the lane is NOT here — move it with compass_opportunities_set_status. Opportunity ids come from compass_opportunities_list. May return `needs_confirmation` — say what you're changing and wait.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `assignee`: The workspace member doing the work, by email or user id; null unassigns. They're notified.
- `description` (string): New description (≤5,000 chars).
- `doneWhen` (string): What's true when it's done, that someone else could check (≤1,000 chars).
- `experiment` (boolean): Measure it against the Ledger (expectation when it starts, verdict when it's done).
- `externalUrl`: Where the doing happens off-platform (URL); null clears.
- `feasibilityScore` (integer)
- `label` (string): New one-line label (2–200 chars).
- `opportunityId` (string, required): The change's key (e.g. ACME-12) or id, from compass_opportunities_list.
- `ownerPageId`: PERSON page id who owns the work; null clears.
- `priority`: How soon it matters; null clears it, and the map's suggestion shows again.
- `qualitativeNotes` (string): Free-form notes (≤20,000 chars) — replaces the current notes.
- `riskScore` (integer)
- `tags` (array): New tag set — replaces existing tags.
- `valueScore` (integer)
- `visibility` (string): Who can see it: PRIVATE (only the user), WORKSPACE (every member, the default), or SHARED (specific people, granted afterwards). Say 'make it private' → PRIVATE.
- `workflowPageId`: Workflow page to anchor to; null un-anchors.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_delete` (~182 tokens)

Delete an opportunity

Removes an opportunity from the pipeline (soft delete). For an AI proposal the user doesn't want, this is the dismiss verb; for a captured experiment that was a duplicate or a mistake, the remove verb. To conclude a real experiment without evidence, prefer compass_opportunities_set_status REJECTED — that keeps the record. Ids come from compass_opportunities_list. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `opportunityId` (string, required): The change's key (e.g. ACME-12) or id, from compass_opportunities_list.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_accept` (~233 tokens)

Accept an AI-proposed opportunity

The review verb for the Inbox: promotes an AI-PROPOSED opportunity (from compass_opportunities_propose or the opportunity scout) into the workspace's own pipeline. compass_opportunities_set_status does NOT do this — a proposal stays in the Inbox until accepted. Optional `status` decides its lane in the same step (BACKLOG to park it, EXPERIMENTING to start it); omitted, it lands in NEW. Fails with not_proposed when the row isn't an AI proposal. Ids come from compass_inbox_list / compass_opportunities_list. May return `needs_confirmation` — name the proposal and wait.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `opportunityId` (string, required): The AI-proposed opportunity's id.
- `status` (string): Lane to place it in on accept (default NEW).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_interviews_list` (~131 tokens)

List Compass interviews

Every stakeholder interview in the workspace, newest first: who was invited, status (INVITED / IN_PROGRESS / COMPLETED), focus, message count, whether the transcript was already reviewed (documentPageId set), and the invite URL while the link is still live. Check this before inviting someone again — interview fatigue is real — and to answer 'who have we already asked?'. Read one in full with compass_interviews_get.

Input parameters:

- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_interviews_get` (~128 tokens)

Read one Compass interview, transcript included

One interview in full — metadata plus the transcript of what the guest actually said. Read this before summarizing an interview or drafting pages from it: the transcript is the source you work from, and your compass skill has the rules for typing and splitting what's in it. Ids come from compass_interviews_list or compass_inbox_list.

Input parameters:

- `interviewId` (string, required): Interview id (from compass_interviews_list).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_interviews_revoke` (~153 tokens)

Revoke an interview invite link

Kills an interview's invite link — the guest's next visit sees that the link is no longer active. Use when an invite went to the wrong person, the user changed their mind, or the link leaked. Idempotent. Ids come from compass_interviews_list. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `interviewId` (string, required): Interview id (from compass_interviews_list).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_inbox_list` (~237 tokens)

What's waiting for a decision in Compass

The Compass Inbox in one read: finished interviews awaiting review (transcript in, not yet turned into pages), AI-proposed opportunities awaiting accept / dismiss, and the caller's pending approval cards for Compass writes. THE place to answer 'what needs me?' for the map. Also `fillIn`: what the map is missing to say who's responsible for what (priorities with no owner, business units with no lead, people and roles in no unit, priorities with no workflow behind them); not counted in `total`. Next moves: compass_interviews_get to read a transcript, then propose pages from it with compass_pages_create; compass_opportunities_accept or compass_opportunities_delete for a proposal. For fillIn, ask the user who owns or leads it, or which unit someone sits in, then compass_links_create with kind owns (person or role → priority or unit) or part_of (person, role or unit → unit); never guess an owner.

Input parameters:

- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_gaps_update` (~201 tokens)

Reword a Compass open question (gap)

Edits an open question's wording, rationale, or suggested resolution — for sharpening a vague question or fixing one you phrased badly. Closing a gap is compass_gaps_resolve, not this. Gap ids come from compass_gaps_list. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `gapId` (string, required): Id of the gap (from compass_gaps_list).
- `question` (string): New wording of the question.
- `rationale` (string): Why it matters / what answering it unblocks.
- `suggestedResolution` (string): How to resolve it: 'ask the user', 'interview Dana', 'connect Drive'.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_statuses_list` (~135 tokens)

List the workspace's change statuses

The statuses this workspace's changes move through, in board order — the names people use. Each sits in a group: Undecided (TRIAGE), Not started (BACKLOG), In progress (ACTIVE), Done (DONE), Dropped (CANCELED). Groups are stable across workspaces; names aren't, so use the names when talking to people and the groups when reasoning about progress. Move a change with compass_opportunities_set_status.

Input parameters:

- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_opportunities_set_status` (~268 tokens)

Move a change to another status

Move a change to one of the workspace's statuses, by name (compass_statuses_list has them — e.g. "In review"). The old lane keys (NEW / QUALIFYING / BACKLOG / EXPERIMENTING / SETTLED / REJECTED) still work and land on that lane's default status. Only changes marked as experiments follow the Ledger: when an experiment enters an In progress status with no registered expectation, offer compass_opportunities_register_expectation; when it enters Done with its Ledger entry still open, offer ledger_entries_settle. Other changes just move. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `opportunityId` (string, required): The change's key (e.g. ACME-12) or id, from compass_opportunities_list.
- `status` (string): A lane key. Use this or `statusName`.
- `statusName` (string): A status name from compass_statuses_list. Use this or `status`.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_workflow_steps` (~251 tokens)

List a workflow's steps and who does them

Every step in a WORKFLOW page's steps diagram, in diagram order, with its phase, whether it is itself a workflow (subWorkflowPageId), and who the map says owns, does, approves, is consulted on, or doesn't do it, and `uses`: the systems or documents it's done in. `unknown: true` means nothing that counts says who does the step or what it's done in — those are the questions worth asking in an interview. A step with `uses` and nobody on it is one a system runs; don't ask who does it. `disputed` lists roles or people with conflicting claims; ask about those rather than picking a side. `proposals` counts claims waiting for review. `variants` are named subsets of the steps ("rush job", "enterprise client"); each step lists the variants it belongs to. Returns no steps when the workflow has no diagram yet (compass_process_diagram_ensure makes one).

Input parameters:

- `pageId` (string, required): The WORKFLOW page id.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_step_claims_list` (~154 tokens)

List what's been said about a workflow's steps

Every claim about a WORKFLOW's steps, oldest first: the step (nodeId; null = the workflow as a whole), the role or person (subject), the relation, who says so (sourceKind + sourceLabel), when it was true (validFrom/validTo), and origin — AI_PROPOSED claims are waiting for a person to review. Claims that disagree coexist; each keeps its source.

Input parameters:

- `nodeId` (string): Narrow to one step.
- `pageId` (string, required): The WORKFLOW page id.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_step_claims_propose` (~508 tokens)

Propose who does a workflow's steps and what in

Propose claims about who does what in a WORKFLOW, and what each step is done in, from what someone said. Each claim names a step (nodeId from compass_workflow_steps), a page (subjectPageId: a ROLE or PERSON, or an AUDIENCE when a customer or partner does the step; for uses a SYSTEM or DOCUMENT; for impacts a PRIORITY; for holds_to a VALUE), and a relation: owns (accountable for it), does (does the work), approves (signs off), consulted (asked for input), does_not_do (says they don't do it — an answer, not a gap), uses (the step is done in this SYSTEM, or with this DOCUMENT; a step a system runs on its own gets uses and no doer), impacts (the step moves this PRIORITY: where the priority is won or lost; pass limits: true on the one step holding it back most), holds_to (the business lives this VALUE at the step). Propose who and what in together, in one call per workflow. Claims land as proposals for a person to accept in Compass; they don't count until then, except in a conversation about the map's questions, where what the person tells you (sourceKind 'user') is kept straight away. Always say who said it: sourceKind 'interview' + the interview id, 'email_thread' + the thread id, 'prism_report' + the desk-research report id, or 'page' + the DOCUMENT or PERSON page id. Prefer the ROLE when the person speaks for their role, the PERSON when it's specific to them. Record a disagreement as its own claim rather than skipping it. When someone says a step happens that isn't in the diagram, add the step with napkin_diagrams_update first. Re-proposing an existing claim from the same source returns it.

Input parameters:

- `claims` (array, required)
- `pageId` (string, required): The WORKFLOW page id.
- `sourceId` (string): The interview, email thread, Prism report or page id, for those kinds.
- `sourceKind` (string): Who says so: 'interview', 'email_thread', 'prism_report', 'page', or 'user' (the person you're talking with).
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_workflow_rollup` (~340 tokens)

Roll up what a workflow takes

Per run and per month: hands-on minutes, waiting minutes, labor cost (hands-on time priced through each role's hourly rate), and hard costs, each as a low–high range, with every step's share and its gates (approvals, handoffs, re-keying, rework). A step that is itself a workflow uses that workflow's roll-up unless it has its own estimate. `coverage` says how many steps are timed — always say how much of the total rests on estimates before quoting it, and never present a range as one number. `unpricedRoles` are roles doing timed work with no hourly rate; their time counts and its cost doesn't. Where the waiting dwarfs the hands-on time, or a gate rarely sends anything back, is usually where the improvement is. `at` reads the estimates as of a date; `variantId` rolls up one variant.

Input parameters:

- `at`: How things were on this date (YYYY-MM-DD). Default today.
- `changeIds` (array): Project the workflow as these changes would leave it (ids from compass_scenario_changes). Compare with a call without them: before vs after, what stays human, overlapping changes.
- `knownAt`: Count only what had been said by this date — the picture as we knew it then.
- `pageId` (string, required): The WORKFLOW page id.
- `variantId` (string): A variant id from compass_workflow_steps.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_workflow_learning` (~166 tokens)

What we've learned about a workflow

Newest first: steps added to or dropped from the diagram (and by whom), and claims about who does what or what a step takes — said, corrected (with what they replaced), withdrawn, or accepted from a proposal — each with its source. This is when we LEARNED things; when they were true is each claim's validFrom/validTo. Use it to brief someone on what changed in the picture, or to see what an interview added.

Input parameters:

- `pageId` (string, required): The WORKFLOW page id.
- `since`: Only what was learned on or after this date.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_step_measures_propose` (~353 tokens)

Propose what a workflow's steps take

Propose estimates from what someone said, as ranges — people know "20 minutes to an hour", not "37 minutes"; when they give one number, use it for both ends. Each item is either a `measure` or a `gate` on a step (nodeId from compass_workflow_steps):
\- measure.metric `working`: hands-on minutes per run (low/high).
\- measure.metric `waiting`: minutes the work sits idle before or inside the step — ask about this separately; it's usually most of the waste.
\- measure.metric `hardCost`: money that isn't anyone's time (amount, currency, per run or month).
\- measure.metric `frequency` with nodeId null: how often the workflow runs (low/high per day, week, month, or year); with variantId, how often that variant runs.
\- gate: approval, handoff, rekey (typing the same data into another system), or rework, with returnRate (0–1) when they know how often it sends work back.
Pass subjectPageId (a ROLE or PERSON) when the time is one person's or role's — it prices the time through that role's rate. Always say who said it. Proposals count once someone accepts them in Compass.

Input parameters:

- `items` (array, required)
- `pageId` (string, required): The WORKFLOW page id.
- `sourceId` (string): The interview, email thread, Prism report or page id, for those kinds.
- `sourceKind` (string)
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_scenario_changes` (~111 tokens)

List the changes that reach a workflow

Changes whose effects reach a WORKFLOW's steps — or any nested workflow's — plus changes anchored to it with no effects yet, each with what it does per step. Pass their ids to compass_workflow_rollup's changeIds to project the workflow after them.

Input parameters:

- `pageId` (string, required): The WORKFLOW page id.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_change_effects_set` (~248 tokens)

Say what a change does to steps

Replace a change's effects: for each step it reaches (workflowPageId + nodeId from compass_workflow_steps — a sub-workflow's steps included), one of eliminate, automate (reviewMinutes: what a person still spends checking), parallelize (its wait comes off the critical path), relax_gate (keepShare: share of the wait left, default 0.25), assist (keepShare: share of hands-on time left, default 0.5), reassign (toSubjectPageId). Eliminating or automating every step of a sub-workflow collapses the step that is that sub-workflow. Then project with compass_workflow_rollup changeIds. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
- `effects` (array, required)
- `opportunityId` (string, required): The change's key (e.g. ACME-12) or id.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_transformations_get` (~152 tokens)

Read a priority's transformations

What the workflows behind a PRIORITY could become, at five levels (Assist, Automate, Re-form, Invert, Dissolve): for each, whether it fits, is already reached, or what it needs; what changes; what it does to the priority; time freed; and the change made from it, if any. Also the recommended level, or `settled` when the work is good as it is. state 'running' means a read is under way; null means none has been read (compass_transformations_read starts one).

Input parameters:

- `priorityPageId` (string, required): The PRIORITY page id.
- `workspace` (string): Workspace slug. Ignored for workspace API keys.

### `compass_priority_steps_find` (~155 tokens)

Find the steps behind a priority or value

Reads every mapped workflow against one PRIORITY (or VALUE) and proposes the steps that move it (or where the business lives the value), one marked as what holds a priority back. Proposals wait for a person to keep them on the priority's page or in the Inbox, except in workflows someone tied to it (a serves link), where they're kept at once. Steps already tied or proposed aren't proposed again, so it's safe to run as the map grows. Use it after a priority is named and workflows are mapped, or when someone asks what moves a priority.

Input parameters:

- `pageId` (string, required): The PRIORITY or VALUE page id.
- `workspace` (string): Workspace slug. Ignored for workspace API keys.

### `compass_transformations_read` (~86 tokens)

Read a priority's transformations again

Starts reading the five levels for a PRIORITY in the background (a minute or two). Needs at least one kept step that impacts the priority. A read under way is left to finish. Check back with compass_transformations_get.

Input parameters:

- `priorityPageId` (string, required): The PRIORITY page id.
- `workspace` (string): Workspace slug. Ignored for workspace API keys.

### `compass_transformations_respond` (~212 tokens)

Record what's true about a transformation level

Records what someone told you about one level of a PRIORITY's current transformations, in their words or a faithful summary: that they already do it, what rules it out, a system that isn't ready, work still done on paper, and so on. Compass works out what it means in the background: a label for the level, facts kept on the steps they're about (every later reading of those workflows sees them), and open questions to confirm. Then it reads the priority again. Use it whenever a conversation settles something about a level, so it lands on the priority's page, not only in this chat.

Input parameters:

- `level` (integer, required): 1 Assist, 2 Automate, 3 Re-form, 4 Invert, 5 Dissolve.
- `priorityPageId` (string, required): The PRIORITY page id.
- `said` (string, required): What's true about the level, as the person said it.
- `workspace` (string): Workspace slug. Ignored for workspace API keys.

### `compass_transformations_make_change` (~154 tokens)

Make a change from a transformation level

Creates a Change from one level of a priority's transformations, with its step effects and the priority it serves, and starts drafting in Workbench up to three flows for what the level says to build (`builds`, each `drafting` until ready). Only a level that fits, once per level. May return `needs_confirmation`.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation envelope.
- `level` (integer, required): 1 Assist, 2 Automate, 3 Re-form, 4 Invert, 5 Dissolve.
- `priorityPageId` (string, required): The PRIORITY page id.
- `workspace` (string): Workspace slug. Ignored for workspace API keys.

### `compass_step_suggestions_list` (~224 tokens)

List which of a workflow's steps something could do

Your earlier read of a WORKFLOW's steps: for each suggestion, the steps it covers (nodeIds, labels), what could do them (proposal.doer: a flow and its mode, a shim, or a task), whether it does the step or helps (reach), why, and what it would take (checklist, each item met or not). state OPEN is waiting for a person; APPLIED made a change (opportunityId), and `built` is what was built for it in Workbench, if anything. Pass changeId instead of pageId to get the one suggestion a change came from. To build one, use compass_step_suggestions_build — not workbench_flows_scaffold.

Input parameters:

- `changeId` (string): A change (opportunity) id: the suggestion it came from.
- `pageId` (string): The WORKFLOW page id.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_step_suggestions_build` (~208 tokens)

Build what a step suggestion names

Builds a step suggestion the way Compass's Build button does: makes its change if it isn't one yet, then the thing in Workbench — a flow drafted from the step itself (who does it, its times, systems, write-up, attachments, interview notes) and its checklist; a shim named for the decision; or a task whose sentence is the steps. Use this, not workbench_flows_scaffold, whenever the work came from a step suggestion. Returns what was built and, for a flow, what the draft still needs. Fails if something's already built for it.

Input parameters:

- `approvalId` (string)
- `pageId` (string, required): The WORKFLOW page id the suggestion is on.
- `suggestionId` (string, required): The suggestion id, from compass_step_suggestions_list.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_changes_upsert` (~230 tokens)

Bring changes in from another tracker

Create or update up to 100 changes in one call, each matched by `url` — the GitHub issue, Linear or Jira ticket, PR or doc it mirrors. A url already linked to a change updates that change (label, description, status, tags, experiment, workflow — omitted fields are left alone); any other url creates a change with that link. Run it again with the same urls to keep Compass in step; nothing duplicates. Statuses are by name (compass_statuses_list). Returns one result per item — created / updated with the change's key, or failed with why; a failed item doesn't stop the rest. Summarize what you're about to bring in before calling. May return `needs_confirmation` — one approval covers the whole batch.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response, after the user has approved.
- `items` (array, required)
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_role_story` (~232 tokens)

Read how a role's job is changing

One ROLE page's story: hands-on hours a month by kind of work (rote, judgment, relationship, sign-off) before its first change or Task landed and now; what landed and when; new work it took on (checks inside Tasks, Tasks it looks after, work a change added), with whether each has settled; the role's size (people × hours each, `hoursAssumed` when the hours are a full-time default) and how much of its month is documented; and the latest analysis, when someone ran one: options for where saved hours could go, each with the stage of its change (proposed = looking into, agreed, done = in place, confirmed, dropped), and skills. Saved hours in a role with under half its month documented are unproven: say so. Talk about the role, never about a person.

Input parameters:

- `rolePageId` (string, required): The ROLE page's id.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `compass_roles_overview` (~146 tokens)

Read how work is moving across every role

Every role in the workspace in one row each, changed or not: hours documented against its working month, hours a month saved, saved hours by stage (looking into, agreed, in place, confirmed, not placed yet), judgment work before and now, new work, and why a role wants attention (unproven savings, saved hours nobody is placing, no documented steps, no headcount). Plus totals. Use compass_role_story for one role's detail. Talk about roles, never about people.

Input parameters:

- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `comments_list` (~105 tokens)

Read an entity's comment threads

Lists 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.

Input parameters:

- `entityId` (string, required)
- `entityKind` (string, required): What the thread hangs on.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `comments_create` (~184 tokens)

Comment on an entity

Posts 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.

Input parameters:

- `approvalId` (string)
- `body` (string, required)
- `entityId` (string, required)
- `entityKind` (string, required): What the thread hangs on.
- `mentionedUserIds` (array)
- `rootId` (string): Reply into this thread; omit to start a new one.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `comments_resolve` (~118 tokens)

Resolve or reopen a thread

Sets 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.

Input parameters:

- `approvalId` (string)
- `resolved` (boolean, required)
- `rootId` (string, required)
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `search_workspace` (~431 tokens)

Search the whole workspace

Finds 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.

Input parameters:

- `folderId` (string): Only search inside this folder and the folders under it (ids from workspace_folders_browse or a folder hit).
- `kinds` (array): Restrict to these kinds (file, folder, flow, page, doc, dataset, …). Omit to search everything.
- `limit` (integer)
- `q` (string, required): Words, any order, case-insensitive. Fewer words find more.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `entity_tags_get` (~130 tokens)

Read the tags on entities

Returns 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.

Input parameters:

- `entityKind` (string, required): Which kind the ids belong to.
- `ids` (array, required)
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `entity_tags_browse` (~149 tokens)

Browse the workspace's tags

Without 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.

Input parameters:

- `tag` (string): A tag to expand into its items. Omit to list tags.
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

### `entity_tags_set` (~173 tokens)

Set an entity's tags

Replaces 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.

Input parameters:

- `approvalId` (string): Approval id from a prior needs_confirmation response. Omit on the first call.
- `entityId` (string, required)
- `entityKind` (string, required)
- `tags` (array, required)
- `workspace` (string): Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/ai-zerowidth-compass/mcp-x-compass#diagnostics

## Score history

- 2026-10-24: 73
- 2026-10-23: 73
- 2026-10-22: 73
- 2026-10-21: 72
- 2026-10-20: 72
- 2026-10-19: 71
- 2026-10-18: 71
- 2026-10-17: 70
- 2026-10-16: 70
- 2026-10-15: 69
- 2026-10-14: 69
- 2026-10-13: 68
- 2026-10-12: 68
- 2026-10-10: 67
- 2026-10-08: 66

## Common questions

### What is the ZeroWidth Compass MCP server?

ZeroWidth Compass is an MCP server listed in the public MCP registry as ai.zerowidth/compass. Read and update your Compass map: pages, changes, opportunities and interviews. This page covers its hosted endpoint (https://api.zerowidth.ai/mcp/x/compass).

### Is the ZeroWidth Compass MCP server safe to use?

ZeroWidth Compass scores 73 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the ZeroWidth Compass MCP server expose?

ZeroWidth Compass exposes 62 tools: search_docs, get_doc, list_docs, compass_pages_list, compass_pages_search, and 57 more. Their descriptions and schemas cost roughly 13,788 tokens of context every time the server is loaded.

### Does the ZeroWidth Compass MCP server require authentication?

No. We connected to ZeroWidth Compass without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the ZeroWidth Compass MCP server still maintained?

ZeroWidth Compass is still listed as active in the MCP registry. We last reached this channel on 24 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://api.zerowidth.ai/mcp/x/compass
- Website: https://zerowidth.ai/docs/overview/mcp#connect-to-one-product
- Changelog RSS feed: https://verifymcp.io/servers/ai-zerowidth-compass/mcp-x-compass.xml
- Changelog JSON feed: https://verifymcp.io/servers/ai-zerowidth-compass/mcp-x-compass.json
- HTML version of this page: https://verifymcp.io/servers/ai-zerowidth-compass/mcp-x-compass
