Obriym CRM

Get Google Merchant product performance

get_google_merchant_product_performance

Read-only

Clicks and impressions per product in Google Shopping for a date range, best first, read from Google's Merchant API Reports on demand — nothing is stored, so it is a question, not a sync. Each row has offerId, title, clicks, impressions and clickThroughRate. At most 92 days per call and 100 products; truncated is true when more products matched than limit, so narrow the dates or raise limit. Conversions are not included. Read-only: it changes nothing at Google and needs no arming, only a connected Google account. Use get_marketplace for what Google decided about the products (moderation), and list_ad_campaigns for spend and the sales the CRM recorded.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from": "<from>",
      "to": "<to>"
    },
    "name": "get_google_merchant_product_performance"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	Last day of the range, YYYY-MM-DD (inclusive). The range is at most 92 days.
`from`	Yes	First day of the range, YYYY-MM-DD (inclusive).
`limit`	No	How many products to return, best first. Default 25, at most 100.
`orderBy`	No	What decides 'best': clicks (default) or impressions.
`adapterId`	No	The Google Merchant connection id from list_marketplaces / get_marketplace. Omit it when the workspace has exactly one connection; with several, omitting it is refused and names them.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint=false, and the description reinforces that ('nothing is stored', 'changes nothing at Google', 'needs no arming'). It adds real operational constraints absent from the annotations — a 92-day ceiling, a 100-product cap, and the truncation flag semantics. It stops short of describing error behavior beyond the adapterId refusal case covered by the schema.

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?

One dense paragraph, front-loaded with what the tool returns and followed by constraints and alternatives; every sentence carries information. It is slightly run-on, with limits, exclusions and routing packed into clauses, but no sentence is filler.

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?

With no output schema, the description compensates by listing the row shape (offerId, title, clicks, impressions, clickThroughRate). Limits, truncation behavior, exclusions and siblings are all covered, so an agent can call it correctly on the first attempt.

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

Parameters4/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; the description still adds the relationship between the limits ('narrow the dates or raise limit') and clarifies that ordering determines what 'best' means. The adapterId selection rule is left to the schema, which handles it well, so nothing is lost.

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?

The opening sentence names the exact metric (clicks and impressions), the entity (per product in Google Shopping), the source (Merchant API Reports) and the ordering ('best first'). It also enumerates the returned row fields, so an agent knows precisely what it gets without opening any schema.

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

Usage Guidelines5/5

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

It explicitly excludes conversions and routes two adjacent questions to siblings: get_marketplace for moderation decisions and list_ad_campaigns for spend/CRM sales. It also frames the call as a question rather than a sync, which sets expectations about when this is the right tool.

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

All Obriym CRM tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?