grr

Overview Schema Source Related Servers Discussions Admin

chat.users.spaces.getSpaceReadState

Retrieves the calling user's read state in a Chat space, helping identify which messages are read or unread.

Instructions

Returns details about a user's read state within a space, used to identify read and unread messages. For an example, see Get details about a user's space read state. Requires user authentication with one of the following authorization scopes: - https://www.googleapis.com/auth/chat.users.readstate.readonly - https://www.googleapis.com/auth/chat.users.readstat [HTTP GET]. Returns the requested resource as JSON — request bodies are built from the typed parameters (typed flags win over the paramsmap), or read whole frombody_file` Siblings over the same resource: updateSpaceReadState.

Input Schema

Name	Required	Description
`name`	Yes	[URL path segment] Required. Resource name of the space read state to retrieve. Only supports getting read state for the calling user. To refer to the calling user, set one of the
`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
`lastReadTime`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / name / description

Previous value: -"Required. Resource name of the space read state to retrieve. Only supports getting read state for the calling user. To refer to the calling user, set one of the"New value: +"[URL path segment] Required. Resource name of the space read state to retrieve. Only supports getting read state for the calling user. To refer to the calling user, set one of the"

addedInput schema / properties / name / pattern

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

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "lastReadTime": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses the auth flow, specific authorization scopes, the read-only scope hint, the calling-user-only restriction, and the HTTP GET/JSON return shape. It falls short of describing error behavior or rate limits, but the safety and auth profile is well covered.

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?

Purpose is front-loaded well, but the text is cluttered by a truncated scope list and generic HTTP boilerplate about `body_file` and typed flags that is irrelevant for a GET. The truncation ('chat.users.readstat') and mixed-in transport notes dilute an otherwise tight core sentence.

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?

An output schema exists, so return values need not be described, and the description covers auth, scoping, and the resource pattern. Together with the schema this is enough for correct invocation; only minor gaps like pagination or error semantics remain, which are not especially relevant for a single-resource getter.

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 the schema already documents the name pattern and each parameter. The description reinforces the calling-user scoping on `name` but adds little else param-specific; the generic body-building note is boilerplate that does not clarify this tool's parameters. Baseline 3 is correct.

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 ('Returns details about a user's read state within a space') and ties it to a concrete outcome ('used to identify read and unread messages'). Sibling differentiation is explicit at the end: 'Siblings over the same resource: updateSpaceReadState', so an agent can route between get and update without opening either 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?

Auth requirements and scope list give clear prerequisites, and the resource name constraint ('Only supports getting read state for the calling user') frames when this tool applies. There is no explicit when-not guidance, but the sibling named at the end is a good enough redirect for the update case.

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

Deploy Server