grr

Overview Schema Source Related Servers Discussions Admin

chat.users.spaces.spaceNotificationSetting.get

Retrieve a user's notification setting for a Google Chat space to check how that space alerts them. Use it with the required user authentication scope.

Instructions

Gets the space notification setting. For an example, see Get the caller's space notification setting. Requires user authentication with the authorization scope: - https://www.googleapis.com/auth/chat.users.spacesettings [HTTP GET]. Returns the requested resource as JSON — request bodies are built from the typed parameters (typed flags win over the params map), or read whole from body_file Siblings over the same resource: patch.

Input Schema

Name	Required	Description
`name`	Yes	[URL path segment] Required. Format: users/{user}/spaces/{space}/spaceNotificationSetting - `users/me/spaces/{space}/spaceNotificationSetting`, OR - `users/user@example.com/spaces
`query`	No	Extra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
`params`	No	Parameter map merged into the request; typed parameters win.
`dry_run`	No	Return the request that would be sent, without sending it.
`body_file`	No	Read the request body from this file ('-' for stdin) instead of building one from the parameters.

Output Schema

Name	Required	Description	Default
`name`	No
`muteSetting`	No
`notificationSetting`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / name / description

Previous value: -"Required. Format: users/{user}/spaces/{space}/spaceNotificationSetting - `users/me/spaces/{space}/spaceNotificationSetting`, OR - `users/user@example.com/spaces"New value: +"[URL path segment] Required. Format: users/{user}/spaces/{space}/spaceNotificationSetting - `users/me/spaces/{space}/spaceNotificationSetting`, OR - `users/user@example.com/spaces"

addedInput schema / properties / name / pattern

Added value: +"^users/[^/]+/spaces/[^/]+/spaceNotificationSetting$"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "muteSetting": {
+      "enum": [
+        "MUTE_SETTING_UNSPECIFIED",
+        "UNMUTED",
+        "MUTED"
+      ],
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "notificationSetting": {
+      "enum": [
+        "NOTIFICATION_SETTING_UNSPECIFIED",
+        "ALL",
+        "MAIN_CONVERSATIONS",
+        "FOR_YOU",
+        "OFF"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

A3.6/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden, and it discloses the HTTP GET method, that user authentication with a specific OAuth scope is required, and links to an example. It does not discuss rate limits or idempotency, but for a read operation the auth/scope disclosure is solid added value.

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 sibling note are front-loaded, but the trailing sentence about body_file / params map and 'Returns the requested resource as JSON' is boilerplate that is largely irrelevant to a GET request, diluting the useful content.

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?

With an output schema present and 100% schema coverage, the description need not explain return values. It covers the essential context an agent needs (auth scope, GET method, sibling mutation tool), though the request-body boilerplate is noise for this read-only endpoint.

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 description coverage is 100%, so all five parameters including the required 'name' pattern are documented in the schema. The description adds almost nothing param-specific beyond the generic boilerplate about typed parameters winning over the params map; baseline 3 is appropriate.

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

Purpose4/5

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

States a specific verb (Gets) and resource (the space notification setting) and explicitly distinguishes from its sibling 'patch' over the same resource. The scope (the caller's setting, per the resourcename users/{user}/spaces/{space}/...NotificationSetting) is inferable but not spelled out in prose.

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

Usage Guidelines3/5

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

The line 'Siblings over the same resource: patch' implies this is the read counterpart to the write operation, giving implicit when-to-use guidance. However, there is no explicit statement of when to use this versus alternatives, no prerequisites beyond auth, and no exclusions.

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

Deploy Server