Skip to main content
Glama

Run a Merchant Center report

merchant_report
Read-only

Run read-only Merchant Center MCQL queries on one account to retrieve product performance, status, pricing, and best-seller rows, returning up to a specified limit.

Instructions

Runs a read-only Merchant Center Query Language (MCQL) query on one account and returns up to limit rows. One view per query. product_performance_view: segments date, week, offer_id, title, brand, marketing_method (ADS or ORGANIC), customer_country_code, category_l1…l5, product_type_l1…l5, custom_label0…4; metrics clicks, impressions, click_through_rate (conversions, conversion_value and conversion_rate count free listings only). It needs a date range and at least one metric, e.g. SELECT offer_id, title, clicks, impressions FROM product_performance_view WHERE date DURING LAST_30_DAYS AND marketing_method = 'ADS' ORDER BY clicks DESC LIMIT 50. product_view (current status): id, offer_id, title, brand, price, availability, gtin, feed_label, aggregated_reporting_context_status (ELIGIBLE, ELIGIBLE_LIMITED, PENDING, NOT_ELIGIBLE_OR_DISAPPROVED), item_issues, click_potential (LOW, MEDIUM, HIGH); id must be selected. Also price_competitiveness_product_view, price_insights_product_view and best_sellers_product_cluster_view. WHERE joins conditions with AND only (no OR); dates as date BETWEEN 'YYYY-MM-DD' AND 'YYYY-MM-DD' or date DURING LAST_7_DAYS / LAST_30_DAYS. Reports work on standalone accounts and sub-accounts, not on an advanced account itself. Changes nothing.

Input Schema

NameRequiredDescriptionDefault
limitNoMost rows to return
queryYesAn MCQL SELECT statement
account_idYesMerchant Center account ID, digits only (from merchant_accounts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.25.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly, openWorld, and non-destructive behavior, and the description adds substantial context beyond that. It discloses 'Changes nothing,' the one-view-per-query rule, required query elements, conversion metric scope, account restrictions, and the row limit.

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?

The purpose and example are front-loaded, and most content is useful for correct MCQL construction. The description is long and dense, with several field lists that could be formatted more readably, but the details largely earn their place.

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

Completeness5/5

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

For a complex query-language tool with no output schema, the description covers return row behavior, view schemas, query constraints, supported date syntax, account exclusions, and an example. It is complete enough for an agent to invoke the tool correctly.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds significant meaning for the query parameter: MCQL SELECT syntax, available views and fields, date-range requirements, view constraints, and an example. It also clarifies account_id scope and limit behavior beyond the schema text.

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 uses a specific verb and resource: it runs an MCQL query on one Merchant Center account and returns rows. It does not explicitly route the agent away from close siblings such as merchant_ad_spend, merchant_product_issues, or run_gaql, so sibling differentiation relies on domain knowledge.

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

Usage Guidelines4/5

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

It gives clear usage context: one view per query, a required date range and metric, AND-only WHERE clauses, supported date formats, and the account-type exclusion. However, it does not explicitly say when to use this tool instead of sibling report tools.

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