grr

Overview Schema Source Related Servers Discussions Admin

analyticsadmin.accounts.getDataSharingSettings

Retrieve an account's data sharing settings to audit or verify how data is shared. Fetches the singleton settings resource for a given account and returns it as JSON.

Instructions

Get data sharing settings on an account. Data sharing settings are singletons [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: delete, get, list, patch, provisionAccountTicket, runAccessReport, searchChangeHistoryEvents.

Input Schema

Name	Required	Description
`name`	Yes	[URL path segment] Required. The name of the settings to lookup. Format: accounts/{account}/dataSharingSettings Example: `accounts/1000/dataSharingSettings`
`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
`sharingWithOthersEnabled`	No
`sharingWithGoogleSupportEnabled`	No
`sharingWithGoogleAnySalesEnabled`	No
`sharingWithGoogleProductsEnabled`	No
`sharingWithGoogleAssignedSalesEnabled`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / name / description

Previous value: -"Required. The name of the settings to lookup. Format: accounts/{account}/dataSharingSettings Example: `accounts/1000/dataSharingSettings`"New value: +"[URL path segment] Required. The name of the settings to lookup. Format: accounts/{account}/dataSharingSettings Example: `accounts/1000/dataSharingSettings`"

addedInput schema / properties / name / pattern

Added value: +"^accounts/[^/]+/dataSharingSettings$"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "name": {
+      "type": "string"
+    },
+    "sharingWithGoogleAnySalesEnabled": {
+      "type": "boolean"
+    },
+    "sharingWithGoogleAssignedSalesEnabled": {
+      "type": "boolean"
+    },
+    "sharingWithGoogleProductsEnabled": {
+      "type": "boolean"
+    },
+    "sharingWithGoogleSupportEnabled": {
+      "type": "boolean"
+    },
+    "sharingWithOthersEnabled": {
+      "type": "boolean"
+    }
+  },
+  "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 does carry some burden, and 'HTTP GET' plus 'singletons' usefully signals a safe read of a single per-account object. It says nothing about permissions required, whether the settings are created on first access, or error behavior when no settings exist.

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 purpose is front-loaded, but roughly half the text is boilerplate about request bodies, `params` maps and `body_file` — machinery irrelevant to a bodyless GET — plus a bare list of seven sibling names with no routing value. That padding dilutes an otherwise two-sentence definition.

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 needn't be explained, and the singleton + HTTP GET notes cover the essential shape of the call. What remains missing (auth scope, behavior when settings are absent) is minor for a simple read.

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% and the `name` pattern and format example are already fully documented in the schema. The description's only parameter-adjacent content is generic request-construction boilerplate (typed params vs `params` map, `body_file`) that adds no meaning for a GET.

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 and resource ('Get data sharing settings on an account') and adds a useful qualifier: these settings are singletons, which distinguishes the call from the list-shaped siblings. It does not explicitly contrast itself against the sibling get/list on the same resource beyond listing their names, so it stops short of a 5.

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 sibling list (delete, get, list, patch, provisionAccountTicket, runAccessReport, searchChangeHistoryEvents) gives context but never says when to choose this tool over them or what preconditions apply. Usage is only inferable from the verb 'Get'.

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

Deploy Server