grr

Overview Schema Source Related Servers Discussions Admin

analyticsadmin.properties.dataStreams.measurementProtocolSecrets.list

Lists MeasurementProtocolSecrets under a specified data stream so you can inspect existing secrets and paginate results.

Instructions

Returns child MeasurementProtocolSecrets under the specified parent Property [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
`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.
`parent`	Yes	[URL path segment] Required. The resource name of the parent stream. Format: properties/{property}/dataStreams/{dataStream}/measurementProtocolSecrets
`dry_run`	No	Return the request that would be sent, without sending it.
`pageSize`	No	[query parameter] Optional. The maximum number of resources to return. If unspecified, at most 10 resources will be returned. The maximum value is 10. Higher values will be coerc
`body_file`	No	Read the request body from this file ('-' for stdin) instead of building one from the parameters.
`pageToken`	No	[query parameter] Optional. A page token, received from a previous `ListMeasurementProtocolSecrets` call. Provide this to retrieve the subsequent page. When paginating, all other

Output Schema

Name	Required	Description	Default
`nextPageToken`	No
`measurementProtocolSecrets`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 26, 2026

changedInput schema / properties / pageSize / description

Previous value: -"Optional. The maximum number of resources to return. If unspecified, at most 10 resources will be returned. The maximum value is 10. Higher values will be coerc"New value: +"[query parameter] Optional. The maximum number of resources to return. If unspecified, at most 10 resources will be returned. The maximum value is 10. Higher values will be coerc"

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

changedInput schema / properties / pageToken / description

Previous value: -"Optional. A page token, received from a previous `ListMeasurementProtocolSecrets` call. Provide this to retrieve the subsequent page. When paginating, all other"New value: +"[query parameter] Optional. A page token, received from a previous `ListMeasurementProtocolSecrets` call. Provide this to retrieve the subsequent page. When paginating, all other"

changedInput schema / properties / parent / description

Previous value: -"Required. The resource name of the parent stream. Format: properties/{property}/dataStreams/{dataStream}/measurementProtocolSecrets"New value: +"[URL path segment] Required. The resource name of the parent stream. Format: properties/{property}/dataStreams/{dataStream}/measurementProtocolSecrets"

addedInput schema / properties / parent / pattern

Added value: +"^properties/[^/]+/dataStreams/[^/]+$"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "measurementProtocolSecrets": {
+      "items": {
+        "properties": {
+          "displayName": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "secretValue": {
+            "type": "string"
+          }
+        },
+        "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?

No annotations are provided, so the description carries the safety burden; 'HTTP GET' signals a read-only retrieval and it states the result is JSON. It does not discuss authorization, rate limits, or pagination behavior beyond what the schema already documents, and the mention of body_file is not relevant to a GET list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is appropriately front-loaded, but the second sentence's explanation of request-body construction from typed parameters or body_file is boilerplate that does not apply to a GET list operation. The sibling list is useful, but the body_file clause costs conciseness without adding value.

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?

Given the rich schema and an existing output schema, the description supplies the key missing orientation: resource, parent scope, verb, and sibling operations. It is sufficient to call correctly, although it omits explicit pagination guidance and auth/rate-limit notes that would matter more without annotations.

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 parent, pageSize, pageToken, dry_run, body_file, params, and query. The description only restates that typed flags override params and that body_file can supply a body, which adds no material meaning for this list call's parameters.

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?

The description states a specific list operation for MeasurementProtocolSecrets under a parent Property and identifies the HTTP verb (GET). It also names the sibling create/delete/get/patch operations, which helps orientation, though the generic body-building sentence is irrelevant to a GET and slightly blurs the purpose.

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?

Naming the sibling operations implies this tool is the list variant, but the description never states when to choose it over get or the other siblings, nor any prerequisites. The agent is left to infer the distinction.

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

Deploy Server