Skip to main content
Glama
debanjanbasu

grr

by debanjanbasu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

analyticsadmin.accounts.get

Retrieve a single Google Analytics Admin account by its resource name and return its details as JSON for inspection or automation.

Instructions

Lookup for a single Account [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, getDataSharingSettings, list, patch, provisionAccountTicket, runAccessReport, searchChangeHistoryEvents.

Input Schema

NameRequiredDescriptionDefault
nameYes[URL path segment] Required. The name of the account to lookup. Format: accounts/{account} Example: "accounts/100"
queryNoExtra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
paramsNoParameter map merged into the request; typed parameters win.
dry_runNoReturn the request that would be sent, without sending it.
body_fileNoRead the request body from this file ('-' for stdin) instead of building one from the parameters.

Output Schema

NameRequiredDescriptionDefault
nameNo
deletedNo
createTimeNo
regionCodeNo
updateTimeNo
displayNameNo
gmpOrganizationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / name / description
      Previous value: -"Required. The name of the account to lookup. Format: accounts/{account} Example: \"accounts/100\""New value: +"[URL path segment] Required. The name of the account to lookup. Format: accounts/{account} Example: \"accounts/100\""
    • addedInput schema / properties / name / pattern
      Added value: +"^accounts/[^/]+$"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "createTime": {
+      "type": "string"
+    },
+    "deleted": {
+      "type": "boolean"
+    },
+    "displayName": {
+      "type": "string"
+    },
+    "gmpOrganization": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "regionCode": {
+      "type": "string"
+    },
+    "updateTime": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observed

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 disclosure burden and does establish this is a read (HTTP GET) returning JSON. However, it spends most of its behavioral content on request-body construction and `body_file`, which is irrelevant to a GET lookup, and says nothing about auth/scope requirements or error behavior.

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 clause is front-loaded correctly, but the middle sentence about building request bodies from typed parameters or `body_file` is boilerplate that does not apply to a read lookup and actively risks confusing the agent. Roughly half the text is inapplicable machinery rather than information about this call.

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?

All five parameters are documented at full coverage and an output schema exists, so return shape need not be explained. The read-only nature is conveyed via the HTTP GET tag; the only real gap is that the inapplicable body/`body_file` prose leaves ambiguity about what is actually required.

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%, so the baseline is 3 and the `name` format/example are already in the schema. The only added semantics is the precedence rule that typed flags beat the `params` map, which is genuinely useful given `params` is a free-form map, but nothing is said about `query` beyond the schema.

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 ("Lookup for a single Account") and tags it as [HTTP GET], so the agent knows exactly what it fetches. It also names the sibling set over the same resource, which helps disambiguate from list/delete/patch, though it does not spell out the distinctions itself.

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?

Alternatives are enumerated (delete, list, patch, runAccessReport, etc.), which implies when this one applies, but the description never states the condition that selects get over list or getDataSharingSettings. Usage is inferable from the name, not from guidance in the text.

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

Deploy Server

Other Tools