ZeroWidth Compass

Connect two Compass pages

compass_links_create

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 Schema

Name	Required	Description
`kind`	Yes	Edge type, in canonical direction.
`note`	No	≤500-char qualifier when the kind alone undersells it.
`source`	No	Provenance label. Defaults AI_ACCEPTED (agent writing under live human direction); pass USER for human-driven scripts.
`validTo`	No	When it stopped being true (YYYY-MM-DD). Only for a relationship that has already ended — recording history.
`sourceId`	No	Id of the interview, email thread, Prism report or page named by sourceKind.
`toPageId`	Yes	Edge target page id.
`validFrom`	No	When the relationship started being true (YYYY-MM-DD). Omit when unknown.
`workspace`	No	Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.
`approvalId`	No	Approval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
`fromPageId`	Yes	Edge source page id.
`sourceKind`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 16, 2026

changedInput schema / properties / sourceId / description

Previous value: -"Id of the interview or page named by sourceKind."New value: +"Id of the interview, email thread, Prism report or page named by sourceKind."

changedInput schema / properties / sourceKind / description

Previous value: -"Who says this is true: an interview, a page (a DOCUMENT, or the PERSON who told you), or the user."New value: +"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."

changedInput schema / properties / sourceKind / enum

Previous value: -[
-  "interview",
-  "page",
-  "user"
-]New value: +[
+  "interview",
+  "page",
+  "user",
+  "email_thread",
+  "prism_report"
+]

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / kind / enum

Previous value: -[
-  "owns",
-  "involved_in",
-  "holds",
-  "uses",
-  "serves",
-  "delivers",
-  "affects",
-  "documents",
-  "relates_to"
-]New value: +[
+  "owns",
+  "involved_in",
+  "holds",
+  "uses",
+  "serves",
+  "delivers",
+  "affects",
+  "documents",
+  "relates_to",
+  "contributes_to",
+  "part_of"
+]

Changed5 schema fields changedOct 11, 2026

changedInput schema / properties / kind / enum

Previous value: -[
-  "owns",
-  "involved_in",
-  "uses",
-  "serves",
-  "delivers",
-  "affects",
-  "documents",
-  "relates_to"
-]New value: +[
+  "owns",
+  "involved_in",
+  "holds",
+  "uses",
+  "serves",
+  "delivers",
+  "affects",
+  "documents",
+  "relates_to"
+]

addedInput schema / properties / sourceId

Added value: +{
+  "description": "Id of the interview or page named by sourceKind.",
+  "type": "string"
+}

addedInput schema / properties / sourceKind

Added value: +{
+  "description": "Who says this is true: an interview, a page (a DOCUMENT, or the PERSON who told you), or the user.",
+  "enum": [
+    "interview",
+    "page",
+    "user"
+  ],
+  "type": "string"
+}

addedInput schema / properties / validFrom

Added value: +{
+  "anyOf": [
+    {
+      "format": "date",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+      "type": "string"
+    },
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+      "type": "string"
+    }
+  ],
+  "description": "When the relationship started being true (YYYY-MM-DD). Omit when unknown."
+}

addedInput schema / properties / validTo

Added value: +{
+  "anyOf": [
+    {
+      "format": "date",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+      "type": "string"
+    },
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+      "type": "string"
+    }
+  ],
+  "description": "When it stopped being true (YYYY-MM-DD). Only for a relationship that has already ended — recording history."
+}

First observedOct 7, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) by disclosing idempotency on an open (from, to, kind) edge and the needs_confirmation/approvalId round-trip that requires pausing for human approval. These are non-obvious behavioral traits that directly affect how the agent calls the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and nearly every sentence carries domain knowledge that earns its place. However, it is a single dense paragraph mixing kind semantics, temporal guidance, provenance, and the confirmation flow, which makes it harder to scan than a structured layout would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with no output schema, the description covers the domain rules (canonical directions, one-parent constraints on PRIORITY and UNIT, idempotency) and the return-side confirmation behavior, leaving no material gap an agent needs before calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: it explains the semantic direction of each `kind` enum value (e.g. PERSON owns WORKFLOW, PAIN_POINT affects WORKFLOW), the purpose of validFrom/validTo, and the sourceKind/sourceId pairing. This lifts it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource — 'Creates a typed, directed edge between two pages' — and frames it as the graph's connective tissue. This is immediately distinguishable from the sibling mutation/read tools (compass_links_update, compass_links_delete, compass_page_links_list).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description is unusually rich on when-to-use: it enumerates canonical directions per kind and gives a clear preference rule ('Prefer attaching responsibilities to the ROLE... the role outlasts whoever is in it'). It also tells the agent when to pass validFrom/validTo and sourceKind/sourceId. It does not explicitly name when to reach for compass_links_update instead, so it stops short of full alternatives coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ZeroWidth Compass tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?