Skip to main content
Glama

Google Merchant Center MCP by InsightfulPipe

Google Merchant Center Data Query

query_data
Read-only

Query Google Merchant Center data (Step 3 (FINAL) of workflow).

REQUIRED: Complete these steps first using query_contexts:

  1. request='accounts' - Get workspace_id, brand_id AND available_actions

  2. request='actions_details' with actions=['xxxxxx', 'xxxxxx', 'xxxxxx'] - Get detailed body structure for specific action(s) using actions from available_actions

IMPORTANT: Always call step 2 to see the exact body structure before querying.

Rely on info from steps 1-2 to construct the query body. Follow the schema exactly.

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": {
      "body": "<body>"
    },
    "name": "query_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

The readOnlyHint and openWorldHint annotations already establish the safety profile, and the description adds important behavioral context: query_data must be preceded by specific query_contexts calls and the body must be constructed from those results. It does not disclose pagination or rate limits, but output schema coverage reduces the need for return-value detail.

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 workflow are front-loaded, and the numbered prerequisite steps are easy to scan. There is some repetitive emphasis with REQUIRED and IMPORTANT, but the description is still appropriately sized for a workflow-dependent tool.

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?

Given that the tool has an output schema and an intentionally dynamic body object, the description supplies the essential prerequisites and points to actions_details for body construction. It could be more complete about allowed query operations, but the critical workflow dependency is covered.

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 0% and the single parameter is an opaque body object with additionalProperties true. The description partially compensates by directing the agent to query_contexts/actions_details to obtain the exact body structure, but it does not itself describe any body fields or constraints.

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 states a specific verb and resource: query Google Merchant Center data, and positions it as Step 3 of a workflow. It distinguishes itself from query_contexts by making the dependency and final-step role explicit, though it does not clarify how it differs from execute_action.

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?

The description gives clear required usage context: call query_contexts for 'accounts' and 'actions_details' first, and always call step 2 before querying. It does not state when to use this versus execute_action, but the workflow prerequisites are explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.