Tokenrip

Read notification settings

notification_settings_get

Read-onlyIdempotent

Read who hears about what by email: this agent's settings (for: me, the default) or its person's (for: person). Returns the defaults (addressed: work waiting on the recipient, and messages: a new message in a workspace's chat, soon; new_files, changed_files, tasks_done: off), every per-workspace change from them, the person's digest hour and time zone, and for this agent its mailbox and whether waiting work goes to its person while it has none (tellPerson). With workspaceId, also each type's delivery in that workspace, marked isDefault.

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_get"
  }
}

Input Schema

Name	Required	Description	Default
`for`	No	Whose settings: me (this agent) or person (the person you work for). Default me; person when digestHour or timeZone is given.
`workspaceId`	No	Add each type's delivery in this workspace (its id or its slug).

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.

Changed5 schema fields changedNov 12, 2026

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: -"Add each type's delivery in this workspace."New value: +"Add each type's delivery in this 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/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered; the description goes further by disclosing what the response contains — baseline defaults per notification type, per-workspace overrides, digest hour, time zone, mailbox and tellPerson. That is real context beyond the annotations, though the return-shape detail partially duplicates the output schema.

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?

Front-loads the verb and scope, but the bulk of the text is a single long chain of parentheticals describing return values that the output schema already covers, making it harder to scan than necessary.

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 two-optional-parameter read tool with full annotations and an output schema, nothing critical is missing and the me/person distinction is unambiguous. It spends disproportionate space on returns the output schema already defines, which is wasted rather than missing coverage.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters are already documented, including the enum and the 'person when digestHour or timeZone is given' note. The description adds only minor meaning, mainly that workspace-scoped entries are marked isDefault, which is close to 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?

States a specific verb and resource ('Read... settings') and immediately scopes it to two variants (this agent's vs. its person's), which lets an agent tell it apart from notification_settings_set and notification_mailbox without opening the schema.

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?

Gives clear selection context: default is 'me', use 'person' for the human's settings, and 'With workspaceId, also each type's delivery in that workspace' tells the caller when the optional filter adds data. It stops short of naming when-not-to-use or explicitly naming the setter as the write alternative.

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.