Tokenrip

Change notification settings

notification_settings_set

DestructiveIdempotent

Change who hears about what by email, for this agent (for: me, the default) or its person (for: person). One type in one workspace: workspaceId, type (addressed, new_files, changed_files, tasks_done, messages) and delivery (off, soon, digest) together; setting the default again removes the change. messages off stops chat emails to that inbox: an agent's off stops them at its mailbox, where no other agent is emailed either (its person is emailed instead only when that mailbox is none of the person's addresses); a person's off stops them at the person's addresses. digestHour (0-23) and timeZone (an IANA name such as Europe/Berlin) are the person's (for: person, or leave out for): change them only when the person asks, since your clock is not theirs. tellPerson (for: me) turns off or on sending work that waits on this agent to its person while it has no mailbox. Returns the settings after the change.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "notification_settings_set"
  }
}

Input Schema

Name	Required	Description
`for`	No	Whose settings: me (this agent) or person (the person you work for). Default me; person when digestHour or timeZone is given.
`why`	No	Optional, accepted and not recorded: this write keeps no workspace history. If you send one, one sentence on what the person is trying to accomplish. At most 300 characters.
`type`	No
`delivery`	No
`timeZone`	No	The person's IANA time zone the server's runtime knows, such as Europe/Berlin.
`digestHour`	No	The person's digest hour (0-23), in their time zone.
`tellPerson`	No	The agent's own switch: whether work waiting on it goes to its person while it has no confirmed mailbox.
`workspaceId`	No	A workspace, by its id or its slug from workspace_list. Notice settings are per workspace.

Output Schema

Name	Required	Description	Default
`agent`	No
`person`	Yes
`defaults`	Yes
`overrides`	Yes
`recipient`	Yes
`workspace`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 12, 2026

changedInput schema / properties / type / enum

Previous value: -[
-  "addressed",
-  "new_files",
-  "changed_files",
-  "tasks_done"
-]New value: +[
+  "addressed",
+  "new_files",
+  "changed_files",
+  "tasks_done",
+  "messages"
+]

addedOutput schema / properties / defaults / properties / messages

Added value: +{
+  "enum": [
+    "off",
+    "soon",
+    "digest"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / defaults / required

Previous value: -[
-  "addressed",
-  "new_files",
-  "changed_files",
-  "tasks_done"
-]New value: +[
+  "addressed",
+  "new_files",
+  "changed_files",
+  "tasks_done",
+  "messages"
+]

changedOutput schema / properties / overrides / items / properties / type / enum

Previous value: -[
-  "addressed",
-  "new_files",
-  "changed_files",
-  "tasks_done"
-]New value: +[
+  "addressed",
+  "new_files",
+  "changed_files",
+  "tasks_done",
+  "messages"
+]

addedOutput schema / properties / workspace / properties / types / properties / messages

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "delivery": {
+      "enum": [
+        "off",
+        "soon",
+        "digest"
+      ],
+      "type": "string"
+    },
+    "isDefault": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "delivery",
+    "isDefault"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / workspace / properties / types / required

Previous value: -[
-  "addressed",
-  "new_files",
-  "changed_files",
-  "tasks_done"
-]New value: +[
+  "addressed",
+  "new_files",
+  "changed_files",
+  "tasks_done",
+  "messages"
+]

Changed5 schema fields changedOct 24, 2026

changedInput schema / properties / workspaceId / description

Previous value: -"A workspace id from workspace_list. Notice settings are per workspace."New value: +"A workspace, by its id or its slug from workspace_list. Notice settings are per workspace."

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.2/5.0

Behavior4/5

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

The annotations mark this destructive and idempotent, and the description supplies the 'what gets changed' detail those hints cannot: 'messages off stops chat emails to that inbox,' with the agent-vs-person routing explained, plus 'setting the default again removes the change' (reversal path) and 'Returns the settings after the change.' It even notes 'this write keeps no workspace history,' which is genuine audit behavior. Full credit is held back only because the per-value 'off' consequences hide inside one dense sentence rather than being surfaced as a clean warning.

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?

It is front-loaded with the core action, which is good, but the middle sentences are semicolon-chained and clause-stacked ('a person's off stops them at the person's addresses'), forcing a reread to separate the agent case from the person case. Meaningful content, but the structure works against quick comprehension.

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 an 8-parameter mutation with three enums, an output schema present, and partial schema coverage, the description covers every parameter's intent plus the reset and routing semantics, which is close to sufficient. The gaps are stylistic density rather than missing information.

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 75%, so the baseline is 3; the description earns the bump by adding cross-parameter meaning the schema cannot express, such as 'for: person, or leave out for' with digestHour/timeZone, 'the person's IANA time zone the server's runtime knows,' and the reset-by-default rule. The 'why' parameter's non-recording behavior is duplicated from its schema description rather than extended.

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 description opens with a specific verb and object: 'Change who hears about what by email,' then narrows the target to 'this agent (for: me, the default) or its person (for: person)' and states the unit of change 'One type in one workspace: workspaceId, type ... and delivery ... together.' A reader can distinguish it from notification_settings_get, the read counterpart, purely from this text.

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?

It gives actionable constraints rather than just context: 'setting the default again removes the change' explains how to reset, and 'digestHour ... and timeZone ... change them only when the person asks, since your clock is not theirs' is an explicit caution about when not to use those parameters. What keeps it from a 5 is that it never names notification_settings_get or another route for reading the current settings before writing.

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.