Skip to main content
Glama

Merchant.Accounts.Get

merchant.accounts.get

Fetch a Merchant Center account by merchant ID to inspect account details and support Google Shopping account management.

Instructions

Get a Merchant Center account.

Input Schema

NameRequiredDescriptionDefault
merchant_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about access requirements, whether this covers sub-accounts, or what happens on invalid IDs. "Get" implies read-only, but that is inference rather than disclosure. An output schema exists, which removes some obligation to describe return values, but the behavioral picture remains thin.

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?

One short sentence with zero waste and front-loaded, but the brevity reflects under-specification rather than economy. There is no filler to cut, yet nothing is added either.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema excuses explaining return values, but with no annotations, no parameter documentation, and an undocumented required ID field, the definition leaves an agent without enough to call this confidently. Something should describe where merchant_id comes from and what the call retrieves.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single parameter, and the description does not compensate at all — merchant_id is never mentioned, nor its format, source, or whether it is the top-level Merchant Center ID versus an account hierarchy node. The agent gets no more meaning than the bare schema property name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Get a Merchant Center account"), which is clearer than the dotted name alone. However, it adds no scoping detail — no statement of what identifying information is needed beyond merchant_id, and no differentiation from adjacent read tools like merchant.products.list or merchant.product.get. Minimum viable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus merchant.products.list or merchant.product.get, and no prerequisites such as which merchant account ID is valid or where to obtain it. The agent must infer usage entirely from the tool name.

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