grr

Overview Schema Source Related Servers Discussions Admin

gmail.users.settings.cse.identities.list

List client-side encrypted Gmail identities for an authenticated user, with pagination, to review or manage CSE identities and keypairs.

Instructions

Lists the client-side encrypted identities for an authenticated user. For administrators managing identities and keypairs for users in their organization, requests require authorization with a service account that has domain-wide delegation authority to impersonate users with the https://www.googleapis.com/auth/gmail.settings.basic scope. For users managing their own identities and keypairs, requests require [hardware key encryp [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: create, delete, get, patch.

Input Schema

Name	Required	Description	Default
`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.
`userId`	Yes	[URL path segment] The requester's primary email address. To indicate the authenticated user, you can use the special value `me`.	me
`dry_run`	No	Return the request that would be sent, without sending it.
`pageSize`	No	[query parameter] The number of identities to return. If not provided, the page size will default to 20 entries.	20
`body_file`	No	Read the request body from this file ('-' for stdin) instead of building one from the parameters.
`pageToken`	No	[query parameter] Pagination token indicating which page of identities to return. If the token is not supplied, then the API will return the first page of results.

Output Schema

Name	Required	Description	Default
`cseIdentities`	No
`nextPageToken`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 26, 2026

addedInput schema / properties / pageSize / default
```
Added value: +"20"
```

changedInput schema / properties / pageSize / description

Previous value: -"The number of identities to return. If not provided, the page size will default to 20 entries."New value: +"[query parameter] The number of identities to return. If not provided, the page size will default to 20 entries."

addedInput schema / properties / pageSize / format
```
Added value: +"int32"
```

changedInput schema / properties / pageToken / description

Previous value: -"Pagination token indicating which page of identities to return. If the token is not supplied, then the API will return the first page of results."New value: +"[query parameter] Pagination token indicating which page of identities to return. If the token is not supplied, then the API will return the first page of results."

addedInput schema / properties / userId / default
```
Added value: +"me"
```

changedInput schema / properties / userId / description

Previous value: -"The requester's primary email address. To indicate the authenticated user, you can use the special value `me`."New value: +"[URL path segment] The requester's primary email address. To indicate the authenticated user, you can use the special value `me`."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "cseIdentities": {
+      "items": {
+        "properties": {
+          "emailAddress": {
+            "type": "string"
+          },
+          "primaryKeyPairId": {
+            "type": "string"
+          },
+          "signAndEncryptKeyPairs": {
+            "properties": {
+              "encryptionKeyPairId": {
+                "type": "string"
+              },
+              "signingKeyPairId": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "nextPageToken": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does disclose real behavioral detail: required service-account delegation and the gmail.settings.basic scope for admin flows, plus a hardware-key path for self-managed users. However, the sentence is cut off mid-word ('hardware key encryp'), and it says nothing about pagination behavior, result caps, or what an empty result means—gaps that matter for a collection endpoint.

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 statement is correctly front-loaded, but the body is padded with full documentation URLs and a generic tail—'Returns the requested resource as JSON — request bodies are built from the typed parameters...'—that is boilerplate irrelevant to a GET list. The text is also visibly truncated mid-sentence, which reads as unpolished.

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

Completeness3/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 shape needn't be explained, and the authorization story is covered. Still, for a paginated settings endpoint the description omits paging guidance and gets truncated exactly where the less-common auth path was being described, leaving a hole an agent may need to fill from the schema alone.

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 `userId`, `pageSize`, `pageToken`, `query`, `params`, `body_file`, and `dry_run` are all documented in the schema already. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the work.

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?

Opens with a specific verb and resource: 'Lists the client-side encrypted identities for an authenticated user.' The trailing 'Siblings over the same resource: create, delete, get, patch' signals that this returns a collection rather than a single identity, though it stops short of an explicit contrast with `get`.

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?

It gives substantial context on which authorization path applies (admin with domain-wide delegation vs. a user managing their own identities), which helps an agent decide if it can call this at all. But it never says when to use list versus the sibling `get`, or how to page through results, so the when-to-use guidance is implied rather than stated.

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

Deploy Server