Tokenrip

Read workspace changes

workspace_changes

Read-onlyIdempotent

Read bounded workspace changes, oldest first: every member reads the same history. Each change names its type, the actor (with alias), the subject (an artifact by its public id) and its title, the stated why, your agent name on your own events, the agent's handle (agentId), viaBrowser (made in a signed-in browser: no why by design; agent then names the agent whose sign-in link signed it in), and mine (your own account). A delivered page must be explicitly acknowledged or replayed with deliveryToken before advancing. WORKSPACE_BUSY usually means another call by your key kept changing your position; nothing was changed, so retry the same call after a short wait.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspaceId": "<workspaceId>"
    },
    "name": "workspace_changes"
  }
}

Input Schema

Name	Required	Description
`limit`	No	At most 100; 50 when omitted.
`workspaceId`	Yes	The workspace: its id or its slug.
`deliveryToken`	No	Replay a delivered page instead of reading a new one.

Output Schema

Name	Required	Description	Default
`items`	Yes
`hasMore`	Yes
`refresh`	Yes
`historyGap`	Yes
`deliveryToken`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

addedOutput schema / properties / items / items / properties / agentId

Added value: +{
+  "anyOf": [
+    {
+      "format": "uuid",
+      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / properties / items / items / required

Previous value: -[
-  "id",
-  "type",
-  "actor",
-  "subject",
-  "payload",
-  "why",
-  "agent",
-  "viaBrowser",
-  "createdAt",
-  "mine"
-]New value: +[
+  "id",
+  "type",
+  "actor",
+  "subject",
+  "payload",
+  "why",
+  "agent",
+  "agentId",
+  "viaBrowser",
+  "createdAt",
+  "mine"
+]

Changed1 schema field changedNov 2, 2026
- addedOutput schema / properties / items / items / properties / actor / properties / former
```
Added value: +{
+  "const": true,
+  "type": "boolean"
+}
```

Changed5 schema fields changedOct 24, 2026

changedInput schema / properties / workspaceId / description

Previous value: -"The workspace id (UUID)."New value: +"The workspace: its id or its slug."

removedInput schema / properties / workspaceId / format
```
Removed value: -"uuid"
```
addedInput schema / properties / workspaceId / maxLength
```
Added value: +64
```
addedInput schema / properties / workspaceId / minLength
```
Added value: +1
```

removedInput schema / properties / workspaceId / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, yet the description adds substantial behavior the annotations cannot express: the field-level shape of each change, that viaBrowser events deliberately carry no "why" and instead name the agent whose sign-in link signed them in, the delivery-advance gate, and the exact meaning and remedy for WORKSPACE_BUSY. The cursor-mutating nature of reads is disclosed rather than hidden, which is the key risk an agent needs to know.

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

Conciseness3/5

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

The purpose and the ack/error rules are correctly front-loaded, but the middle is one very long run-on sentence with nested parentheticals ("viaBrowser (made in a signed-in browser: no why by design; agent then names ...)") that is hard to parse on first read. Much of that field-by-field enumeration duplicates the existing output schema rather than earning its place in the description.

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

Completeness4/5

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

For a cursor-based delivery tool with acknowledgement, replay and a specific busy error, the description covers the hard parts an agent would otherwise get wrong. It is only slightly short of complete because it never points at the acknowledgement sibling, leaving the agent to infer the next call from the sibling list.

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 beyond the schema for deliveryToken: the schema only says "replay a delivered page", while the description explains it is the mechanism that prevents a page from advancing without acknowledgement. limit and workspaceId are left entirely to the schema, which is acceptable given full coverage.

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?

"Read bounded workspace changes, oldest first" gives a specific verb, resource, ordering and scope, and "every member reads the same history" pins down the shared-history semantics that separate this from per-user views. An agent knows immediately this is a cursor-style change feed rather than a listing or a session tool.

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 tells the agent how to consume results (a delivered page must be acknowledged or replayed with deliveryToken before advancing) and how to react to WORKSPACE_BUSY (nothing changed, retry the same call after a short wait). What it never states is when to prefer this over the sibling workspace_changes_ack or workspace_sessions — the ack obligation is described but the tool that performs it is never named.

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

All Tokenrip 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.