Skip to main content
Glama

ZeroWidth

by ai.zerowidth
OverviewDiscussionsAdmin

Propose who does a workflow's steps and what in

compass_step_claims_propose

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 Schema

NameRequiredDescriptionDefault
claimsYes
pageIdYesThe WORKFLOW page id.
sourceIdNoThe interview, email thread, Prism report or page id, for those kinds.
workspaceNoWorkspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.
sourceKindNoWho says so: 'interview', 'email_thread', 'prism_report', 'page', or 'user' (the person you're talking with).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / sourceId / description
      Previous value: -"The interview or page id, for those kinds."New value: +"The interview, email thread, Prism report or page id, for those kinds."
    • changedInput schema / properties / sourceKind / description
      Previous value: -"Who says so: 'interview', 'page', or 'user' (the person you're talking with)."New value: +"Who says so: 'interview', 'email_thread', 'prism_report', 'page', or 'user' (the person you're talking with)."
    • changedInput schema / properties / sourceKind / enum
      Previous value: -[
-  "interview",
-  "page",
-  "user"
-]New value: +[
+  "interview",
+  "page",
+  "user",
+  "email_thread",
+  "prism_report"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / claims / items / properties / subjectPageId / description
      Previous value: -"The ROLE or PERSON page id; for uses, the SYSTEM or DOCUMENT page id; for impacts, the PRIORITY page id; for holds_to, the VALUE page id."New value: +"The ROLE, PERSON or AUDIENCE page id; for uses, the SYSTEM or DOCUMENT page id; for impacts, the PRIORITY page id; for holds_to, the VALUE page id."
  3. Changed5 schema fields changed
    • addedInput schema / properties / claims / items / properties / limits
      Added value: +{
+  "description": "For impacts: this step holds the priority back most right now.",
+  "type": "boolean"
+}
    • addedInput schema / properties / claims / items / properties / relation / anyOf
      Added value: +[
+  {
+    "enum": [
+      "owns",
+      "does",
+      "approves",
+      "consulted",
+      "does_not_do"
+    ],
+    "type": "string"
+  },
+  {
+    "enum": [
+      "uses",
+      "impacts",
+      "holds_to"
+    ],
+    "type": "string"
+  }
+]
    • removedInput schema / properties / claims / items / properties / relation / enum
      Removed value: -[
-  "owns",
-  "does",
-  "approves",
-  "consulted",
-  "does_not_do"
-]
    • removedInput schema / properties / claims / items / properties / relation / type
      Removed value: -"string"
    • changedInput schema / properties / claims / items / properties / subjectPageId / description
      Previous value: -"The ROLE or PERSON page id."New value: +"The ROLE or PERSON page id; for uses, the SYSTEM or DOCUMENT page id; for impacts, the PRIORITY page id; for holds_to, the VALUE page id."
  4. Added

TDQS

A4.7/5.0
Behavior4/5

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

Goes well beyond the annotations: claims land as proposals pending acceptance, except sourceKind 'user' in a map-questions conversation which is kept immediately, and re-proposing from the same source returns the existing claim (idempotency). This is strong behavioral detail, though it doesn't describe limits like maxItems=50 coupling to error behavior.

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?

Front-loaded with purpose and highly information-dense; nearly every clause earns its place. The nested parenthetical enumerating relation meanings is dense and slightly run-on, but not wasteful.

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 a complex, multi-parameter, no-output-schema mutation tool, the description covers attribution, idempotency, missing-step handling, and the 'user' exception, leaving nothing an agent needs in order to invoke it correctly.

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

Parameters5/5

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

Schema coverage is 80%, yet the description still adds real meaning: it decodes each relation, explains the subjectPageId type mapping per relation, and clarifies sourceKind/sourceId pairing and the 'user' special case. Substantially more than the schema alone conveys.

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?

States a specific verb (propose) and resource (step claims about who does what in a workflow), and the parenthetical detail about relations and subject page types makes it unmistakable against siblings like compass_step_claims_list or compass_step_measures_propose.

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

Usage Guidelines5/5

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

Explicit when-to-use rules: one call per workflow for who and what together, add the step via napkin_diagrams_update first when a step is missing, record disagreements as their own claim rather than skipping, and prefer ROLE vs PERSON depending on context. Alternatives and exclusions are named.

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

All ZeroWidth toolsInspect
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