grr

Overview Schema Source Related Servers Discussions Admin

analyticsadmin.properties.googleAdsLinks.create

Creates a Google Ads link for an Analytics property, associating a Google Ads customer ID and configuring ads personalization and management settings.

Instructions

Creates a GoogleAdsLink [HTTP POST] — creates or triggers a change; refused under --readonly safety profiles. Returns the API's response resource as JSON — request body is a JSON GoogleAnalyticsAdminV1betaGoogleAdsLink object accepting adsPersonalizationEnabled, canManageClients, createTime, creatorEmailAddress, customerId, name, updateTime; pass it via params or whole via body_file Siblings over the same resource: delete, list, 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. Example format: properties/1234
`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. The body is a JSON GoogleAnalyticsAdminV1betaGoogleAdsLink object.
`request_body`	No	Request body of type GoogleAnalyticsAdminV1betaGoogleAdsLink: pass it via `params` (merged into the built body) or whole via `body_file`.

Output Schema

Name	Required	Description	Default
`name`	No
`createTime`	No
`customerId`	No
`updateTime`	No
`canManageClients`	No
`creatorEmailAddress`	No
`adsPersonalizationEnabled`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / body_file / description

Previous value: -"Read the request body from this file ('-' for stdin) instead of building one from the parameters."New value: +"Read the request body from this file ('-' for stdin) instead of building one from the parameters. The body is a JSON GoogleAnalyticsAdminV1betaGoogleAdsLink object."

addedInput schema / properties / request_body

Added value: +{
+  "description": "Request body of type GoogleAnalyticsAdminV1betaGoogleAdsLink: pass it via `params` (merged into the built body) or whole via `body_file`.",
+  "properties": {
+    "adsPersonalizationEnabled": {
+      "type": "boolean"
+    },
+    "canManageClients": {
+      "type": "boolean"
+    },
+    "createTime": {
+      "type": "string"
+    },
+    "creatorEmailAddress": {
+      "type": "string"
+    },
+    "customerId": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "updateTime": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / parent / description

Previous value: -"Required. Example format: properties/1234"New value: +"[URL path segment] Required. Example format: properties/1234"

addedInput schema / properties / parent / pattern
```
Added value: +"^properties/[^/]+$"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "adsPersonalizationEnabled": {
+      "type": "boolean"
+    },
+    "canManageClients": {
+      "type": "boolean"
+    },
+    "createTime": {
+      "type": "string"
+    },
+    "creatorEmailAddress": {
+      "type": "string"
+    },
+    "customerId": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "updateTime": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

A3.9/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 does useful work: it discloses HTTP POST, that it 'creates or triggers a change', that it is refused under --readonly safety profiles, and that it returns the API response resource as JSON. The only omission is any permission/auth requirement beyond the readonly note.

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

Conciseness4/5

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

Front-loads the verb+resource, then packs behavior and body guidance into dense dash-separated clauses. Slightly run-on, but each clause (POST, readonly refusal, return type, body routing, siblings) carries information.

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?

For a create tool with an output schema present and full param coverage, the definition covers mutation semantics, the readonly-profile guard, and return shape. It lacks an explicit precondition/permission statement, which is the one remaining gap.

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, params, body_file, request_body and its fields. The description restates the body fields and the params/body_file routing but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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 (Creates) and resource (GoogleAdsLink) immediately, and explicitly enumerates the sibling operations over the same resource (delete, list, patch), letting an agent place it precisely among the googleAdsLinks family.

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 siblings (delete, list, patch) implies the create-vs-manage distinction, but the description never says when to choose this over those or what precondition (an existing property) is needed. Usage is inferable 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